IP/VLAN PLANNING FOR ROUTED ACCESS DESIGN We are currently designing a complete Layer 3 to the edge solution for

our customers. The network design is a combination of a collapsed core (Core to access) as well as a three layer model (Core/Distro/Access) for connectivity to the Data Centre, Internet and Wireless Blocks.

The core of the network contains two 6509E switches interconnected on a Layer 3 Port channel (no VSS). Access Layer switches (3750 Stacks) connect to the core switches over p2p routed links (Collapsed core part of the design). Distribution layer switches provide connectivity to the Data centre, Internet and Wireless Blocks. (three layer model.

All IP addressing is being planned for assignment from the private RFC 1918 address block(10.0.0.0/8) for both Infrastructure and Access layer VLANs for users.

Clarifications required for the following:

1) There are about 15 VLANs to be configured in about 20 access switches and configuring unique VLAN's on all the access switches in the respective subnets will make the design very complex and difficult to manage. Therefore, the same VLAN ids will be used on all the access switches but the IP subnets on each of these VLAN's will be different across the Layer 3 access edge domain.

For eg. Switch 1 containing VLAN 10 will be assigned 10.X.0.0/26 Switch 2 containing VLAN 10 will be assigned 10.X.4.0/26 X in the second octect refers to the location of the switch and the third octet is chosen so that it does not clash with the other IP addresses in similar VLANs. Similar IP addressing design for the other VLAN's as well.

Is this is a correct address assignment for the Layer 3 access design? or is it better to have another level of hierarchy in the third octet, to have say the IDF number the

switch belongs to. What is the best practise for IP/VLAN assignment on the access switches?

2) All the access switches and the distribution switches will be implemented with EIGRP stub and advertising only the connected routes with the EIGRP summary disabled( no auto-summary), so that all specific connected LAN routes are advertised to the core. In this case, is it required to manually summarise routes advertised from the distribution to the core for the distribution block only as we have been advised not to summarise any of the routes that is advertised from both the access as well as distribution layers.

3) Can the point-to-point Layer 3 links (/31) between the core and access/distribution layer be addressed on one large /21 subnet(10.x.0.0/21) in the private IP block or can this be addressed using individual /31 subnets allocated from the IP address from the respective blocks(10.10.0.0/31, 10.20.0/31 etc)

Thanks in advance. Best Regards. Correct Answer by jon.marshall on Sep 11, 2012 4:44 PM

1) Entirely up to you. You can certainly reuse vlan IDs in a fully routed environment. The key thing is to make it is as simple as possible so when you are under pressure trying to fix a problem you don't have to spend 5 mins trying to remember just how the naming convention works.

2) the way i would see this working -

i) for the access-layer switches directly connected to the core they would advertise specific connected routes only to core. Whether you want to advertise these on to the distro switches is up to you but as they are only reachable via the core switch you could simply summarise them to the distro switches. This has the added advantage in that if some of these subnets were lost ie. a link flapping then there is no need to then advertise the changes to the distro switches.

ii) The distro to core advertisements could again be summarised to the core. Again it's up to you as you could advertise all the wireless/DC subnets but as they are only reachable via the distro switches you could summarise again.

So the core 6500s would have all specific subnets for directly connected accesslayer switches, summarised routes for the wireless and DC subnets and presumably a default route for the internet.

The distro switches would have their specific connected routes ie. wireless/DC and also one summarisable route from the core and presumably a default-route pointing off to a firewall.

It's not clear whether you have one set of distro switches for DC, one for wireless and one for internet or one pair for all 3 functions. If you have 3 sets are they only connected to the core ? ie. they do not have interconnections between them. If they do this could change how you advertise the routing.

3) Don't use a /21 for all P2Ps because this can mess up the summarising.

Remember that the core is advertising a summary address to the distro for all subnets on the access-layer switches that are directly connected to it. So ideally you want the P2Ps to be from the same summarisable range. And the same argument would apply to the subnets advertised from the distro to the core.

Jon See the answer in context Correct Answer by jon.marshall on Sep 12, 2012 7:04 AM

Mohan

It really depends on what times you consider acceptable. To be honest in a fully routed L3 setup using EIGRP and equal cost paths it will be, as you say, very fast failover. When we did our testing in a fully routed setup we lost at most one packet.

Note also that you are not relying on EIGRP convergence because you have equal cost paths so they are both in use anyway ie. EIGRP does not need to find a successor. So you may not gain that much from having extra sups in both chassis.

Jon See the answer in context Correct Answer by jon.marshall on Sep 12, 2012 7:22 AM

Mohan

Thanks for that. Yes i assumed that you still needed to manually configure a summary.

One last point. If any of the distro switches are interconnected via a L3 port-channel then don't forget to summarise between the distro switches. I'm guessing that the distro switches are interconnected via L2 trunks so you wouldn't need to worry but just wanted to make sure.

Jon See the answer in context Average Rating: 5 (3 Votes)

Outline View

Tags: design, 3, access, layer, routed, layer_3, layer_3_design, access_layer, routed_access

jon.marshall

16,224 posts since Sep 23, 2003 Sep 11, 2012 4:44 PM (in response to mohankumarm)