[c-nsp] Sharing router uplinks?

[JP Senior]

Putting a web server (or any other) host device on the same subnet causes reachability issues to other subnets -- hacks/workarounds include ICMP redirects, static routing tables, and proxy arp on the subnet.  A server won't know which 'router' to take to get to which subnet.  This is an administrative disaster as you have to either permit ICMP redirects explicitly (Operating systems shouldn't/don't support this by default anymore), turn on evil proxy arp, have a full mesh IGP, or enable static routes on the hosts.

Hosts should only have a single exit point out of a subnet, through a router(or two, using FHRP).

As far as shared 'router' vlans or subnets, this is completely normal and common for distribution/core networks.

-JP Senior

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Erik Nelson
Sent: 01 August 2012 9:23 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Sharing router uplinks?

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. 


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.