[c-nsp] Sharing router uplinks?

Mark Tinka mark.tinka at seacom.mu
Mon Oct 1 09:30:04 EDT 2012


On Wednesday, August 01, 2012 05:23:05 PM Erik Nelson wrote:

> I have always thought it is a best practice to not put
> servers or PCs on links/subnets that connect routers
> together. I also have always thought that router to
> router links should be 1:1. For example, the link from a
> top-of-rack or end-of-row router to the data center core
> should be a dedicated link. 
> 
> I have run into a situation where there is insistence
> that both of these practices not be observed. I am being
> asked to put many router uplinks on a single subnet
> connected to a single port on the core router. I am also
> being asked to put a web server on this same subnet. 
> 
> What do others think of this?  I have been unable to find
> anything on the web that says anything for or against.
> If anyone knows of authoritative guidelines on the web
> about this I would be very interested.

Within a PoP, I've normally had 2x core switches. All edge 
and peering routers will share the same VLAN on each core 
switch, but different VLAN's between the switches (the 
switches are interlinked, but this is superfluous, as 
traffic never follows that path anyway due to all routers 
multihoming to both switches).

The core routers also connect to the core switches, into the 
appropriate VLAN on each core switch in order to be on the 
same subnet as the edge and peering routers on that 
particular switch.

The reason we use VLAN's on the core switches is because in 
some PoP's, there are border routers too. Those will live in 
a separate VLAN from the edge and peering network, along 
with the core router interfaces to match (in the past, a PoP 
would have 4x core switches to support this, but routers 
have now gotten more powerful and major upstream providers 
all support 10Gbps hand-offs now).

So yes, I agree that sharing a subnet between your 
infrastructure makes sense, i.e., between your core routers, 
border routers, edge routers, peering routers, e.t.c., 
particularly if you find that you're massively 
underutilizing port bandwidth in a point-to-point topology.

However, I also wouldn't recommend placing your services on 
the same subnet as your core infrastructure, particularly if 
you can afford not to.

What I have done at previous employers is to have a so-
called "Production" router, which hooks into the core switch 
also. This router is responsible for aggregating downstream 
traffic from services-oriented infrastructure, e.g., DNS, 
RADIUS, FTP, HTTP/HTTPS, SMTP, POP3, DHCP, e.t.c. This way, 
you keep your services separate from your transport network, 
in case it makes sense for you to do so.

In smaller networks with little cash to spend, everything is 
collapsed into a single router, including transit and 
peering traffic, customer edge termination, services 
aggregation, e.t.c. It will work, but presents challenges 
that only you will discover down the line.

Hope this helps.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20121001/9e254352/attachment-0001.sig>


More information about the cisco-nsp mailing list