Router – Switch in front of router – multiple public IPs

datacenternetworkingrouterswitch

Network Gurus,

This seems logical and doable but want to have an advice from experts. We have /26 on single drop in our datacenter.

Some of our application servers (A) need public IP addresses and hence the need for these many addresses. Those servers in old setup [ Router -> Managed Switch (vlans)-> individual lan switches/vlans] were on separate vlan and we had dedidcated /24 drop by datacenter provider connected to the managed switch just for that. Also main applications (B) were behind FW that had separate drop of /27 and lan port was serving off our needs (lan port was also switched through same managed switch on private vlan).

We are moving datacenter and this time, rather than going for two drop solution, I was thinking of either having basic dumb switch/hub in front of router or managed switch in front of router. Router / FW would serve our main applications (B), where as other application servers that need to be on public facing IP feed from the same switch. What solution would be better ?

Also another alternative is that our router has dmz port as well and multi 1:1 NAT capability. I could create virtual interface on WAN port with sub range of IPs natted 1:1 to the dmz local IP range. In that situation, will I have to create policy route (SNAT) for those servers to go out ?

Thanks

Purvesh

Best Answer

Whether to use a router or a switch at a service provider's edge is typically dictated by the manner in which the IP range will be delivered to you.

An address range which the provider gives you with an "upstream gateway", and no routing configuration at your end has to have a layer two connection to the gateway (or simulated as such; cf Proxy ARP) in order for the packets to flow. When a packet gets to the upstream router, it assumes that the destination address is on the local L2 segment, and will just ARP away for it. That means you need to have a switch (or other L2 network) for all of the consumers of the address space. That doesn't mean everything has to be directly connected, though -- if you place a router at your end and run Proxy ARP on it, you can still do L3 filtering (firewalling) on the traffic before it gets to the destination; you just have a more complicated and hard to debug network environment.

Since that can be quite an undertaking for a larger netblock, it only tends to happen for smaller blocks, or providers who don't know what they're doing. At the big end of town, you'll typically get a very small range (or even a point-to-point link) between the service provider's router and yours, and all additional netblocks will be routed to your router via that address.

For instance, if you've been assigned 192.0.2.0/25 as your big-chunk-of-IP-addresses, you'd also be given a smaller allocation (say 192.0.2.192/29) and be told, "the upstream gateway is 192.0.2.193. You then configure your routers (HA pair, natch) to have IP addresses 192.0.2.194 and 192.0.2.195, and configure 192.0.2.196 as the HA IP that one router of the pair will have "control" of at any given moment. You then tell the service provider, "please route my big-block-of-IPs to 192.0.2.196, and then either router can handle the traffic, depending on which one has the speaking stick at the time.

An additional useful benefit of this approach is that multiple blocks can be routed to the same IP, reducing the hassle factor of lots of fiddly network configs over the same L2 segment. You also don't have to waste the first and last addresses of the block on network and broadcast addresses, because you're not actually "subnetting" in that sense, merely routing chunks of address space.