Main Nav

Hello Friends,
I don't want to hijack the 'VRF for service networks' thread so am starting a new one.  First, thanks Jeff for your presentation.  I've been watching the video (http://educause.mediasite.com/Mediasite/Play/fcd724e3ebe1496c8d03dbd4a7424d7e1d?playFrom=136768&autoStart=true&popout=true
and find it real informative.

I share the concerns around service networks trunked to many buildings, however in addition to the VRF design decisions, around minute 28 Jeff begins talking about another design decision that really stuck out for me.  He describes the idea that they used trunked SVIs as point-to-point connections from building to core.  So far, so good, we are doing that also.  He then describes why they chose to use a single /24 for each routing instance as the point to point instead of a separate /30 for each connection!  So that for, say 25 buildings one would have a single vlan interface/SVI in the core and trunk that single vlan to each building giving an ip address in that vlan to each building's head-end router.  I had never before thought of this as a possibility or read/heard about it either.  This seems to brilliantly  simplify things, and I am wondering if others have tried this implementation.  As I am writing this, I am thinking that it does slightly increase the chances for a broadcast storm, but not by so very much, since there would be one uplink per building and very limited arps and no devices other than routers on this vlan.

Any other thoughts??  
 
Dennis Bohn
Manager of Network and Systems
Adelphi University
bohn@adelphi.edu
5168773327
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Message from rrichman@nd.edu

Isn’t one of the reasons a /30 is used is that it limits the routing protocol exposure to only the few possible endpoints? I realize authentication for ospf, etc can be used for this, but doing it this way has seemed to be a ‘best practice’.

 

Recommend