IP/VLAN planning for Routed Access Design

[mohankumarm]

Hello,

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.

[Jon Marshall · Accepted solution]

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 access-layer 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

[mohankumarm]

Hi Jon,

Thanks very much indeed and that was great explanation indeed as this has been puzzling me for the last few days.

Yes, we have 3 sets of individual distro switches connected to the core and there are no interconnections between them.

For the p2p, then i can use /31's from the summarisable range from the respective subnets allocated on the access and distro layers, instead of using

Also for interconnection between the core switches, can we use Layer 3 Port channel and also advertise the summaries to one another?

Thanks and Regards,

[Jon Marshall]

For the p2p, then i can use /31's from the summarisable range from the respective subnets allocated on the access and distro layers, instead of using

Yes you use /31s or /30s from your summarised ranges which keeps the routing table entries to a minimum.

You can use a L3 port-channel if you want.

Is it correct to assume that each access-layer switch is connected to both core switches via a L3 uplink ?

Jon

[mohankumarm]

Yes, thats absolutely right...the access layer as well as the distribution layer is connected to both core switches via Layer 3 uplinks and EIGRP stub will be implemented on both the access and distro layers advertising their respective connected routes. Also as per your advise, routes will be manually summarised  1) from the core to the distro layers (for the access layer routes) and 2) from the distro layer to the core ( for the wirless/DC).

Thanks again.

[Jon Marshall]

The only thing i would add is that the distro switches don't need to advertise connected routes to the core (if this is what you meant). This is because everything "behind" the distro switches will be included in the summarised range eg. the DC distro switches will be advertising a summary route to the core which includes -

i) all the access-layer DC subnets for servers etc.

ii) the P2Ps /30s or /31s that are used for the DC access-layer uplinks to the DC distro switches. ***

the P2P connections between the distro and core don't need advertising to the core as the core knows about them. As mentioned previously, just make sure that these P2Ps ie. core to distros are not out of any of the summarised address ranges used elsewhere.

*** are you using routed access-layer in the DC as well ? I only ask as using L3 access in the DC is not necessarily the best choice so was just wondering.

Jon

[mohankumarm]

Ok Got it! Sorry i was writing my reply quickly,so sorry for the confusion.

In the DC, i think this is a Layer 2 Design (including firewalls that will be run in tranparent mode in different contexts)

For all the distro switches, will not advertise connected routes, but then again the configs will be similar to this

router eigrp 100

network 10.0.0.0

no auto

eigrp router-id x.x.x.x

eigrp stub

I believe just configuring eigrp stub will advertise the connected routes by default, so will this be overriden by the manual summary configs on the interface from the distro the core(p2p /31 interface) i thought...?

ip summary-add eigrp 100 x.x.x.x x.x.x.x

[Jon Marshall]

To be honest i wasn't thinking of configuring the distro as eigrp stub, only the access-layer switches. I seem to remember from the design docs i read at the time only the access-layer had eigrp stub configured but that may have been in a collapsed core/distro design setup.

I was thinking of just configuring the distro switches as normal and then as you suggest using the "ip summary-address eigrp ... " command on the P2P links between the core and distro switches.  Usually the stub router doesn't have any other network devices behind it.

However i'm not saying you can't use eigrp stub on the distro switches though, just hadn't thought of it. I can't see any obvious problem with it at the moment. If you did i think you would need to use "eigrp stub summary" and not just "eigrp stub". I'm assuimg that would mean only the summary would be advertised to the core but i can't remember and can't test at the moment so it would need testing.

Jon

[mohankumarm]

Hi Jon,

Thanks again for your recommendations and much appreciated. I have got another question in regards to the Sup-2T modules provided in the 6509 core switches. There is only a single Sup module on both the switches and therefore we cannot use NSF/SSO for fast switchover in case of failure of Supervisor withiin a chassis. But then, if a sup fails in  a chassis, the routing from the access and distro layers will fail over to the other chassis,(as there are dual links from the access/distro to the core) and as the EIGRP convergence time is 200 msec, this should be real quick and there should be no outage ( or very minimal So , the question is, is it better of having an extra redundant supervisor in a chassis to yield better failover time than the current use of EIGRP failover times using Routed access? Please note that both the core switches are standalone(i mean interconnected by a Layer 3 Port channel) and no VSS feature exists between them.

Thanks again.

Mohan

[Jon Marshall · Accepted solution]

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

[mohankumarm]

Fantastic!! Thanks again and i have downloaded a cisco document on redundancy from one of your previous postings which details the hardware as well as routed access redundancy.

Best Regards,

Mohan

[Jon Marshall]

Quick follow up point.

It's not clear how the distro switches are interconnected ie. via L2 or L3. For the DC presumably L2 but what about wireless and internet ?

I ask as using EIGRP stub on these switches could have an affect on how the distro switches exchange routes between themselves.

Jon

[mohankumarm]

Hi Jon,

Just did a quick check on EIGRP, which displays summary routes for EIGRP but will have to confirm if this  does not advertise connected routes by default and if this is true, then there is no need to manually summarise from the distro to the core ..correct?

Lab(config-router)#eigrp stub summary

Lab(config-router)#do sh run | be router

router eigrp 10

no auto-summary

eigrp stub summary

network 10.0.0.2 0.0.0.0

network 50.0.0.0

!

SevenHills-Lab(config-router)#eigrp stub summary ?

  connected      Do advertise connected routes

  redistributed  Do advertise redistributed routes

  static         Do advertise static routes

SevenHills-Lab(config-router)#do sh ip protocols

*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 10"

Address Family Protocol EIGRP-IPv4:(10)

  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

  EIGRP maximum hopcount 100

  EIGRP maximum metric variance 1

  EIGRP NSF-aware route hold timer is 240

  EIGRP stub, summary

  Topologies : 0(base)

2) There is no interconnection between distro switches for wireless or Internet ( each of these blocks have a primary and secondary site interconnections, but no physical block to block connectivity( i mean Wireless to DC and others). The design within DC is Layer2.

Thanks again for all your help and advise.

[Jon Marshall]

1) You still need to check for summary routes on the core switches.. I think you will need to manually summarise because i'm not sure EIGRP will work out which address to advertise ie. you are not using auto-summary so EIGRP doesn't really know what summarised range you want to advertise.

2) Yes, i assumed that was the setup you had.

Jon

[mohankumarm]

Hi Jon,

Okay, will check for the summary on the core switches.

I did a test on the "eigrp stub summary" and "eigrp stub connected" features. and here is the result:

1) eigrp stub connected  - With this feature enabled on the downstream(access) router, all the connected routes are visible in the upstream (core) router.

Lab(config-router)#do sh run | be router eigrp

router eigrp 10

no auto-summary

eigrp stub connected

network 10.0.0.0

network 192.168.1.0

network 192.168.2.0

network 192.168.3.0

!

interface FastEthernet0/1

no switchport

ip address 10.0.0.2 255.255.255.0

ip summary-address eigrp 10 192.168.0.0 255.255.252.0 5

carrier-delay msec 0

Upstream router

CUCM-ROUTER#sh ip ro ei

     99.0.0.0/32 is subnetted, 1 subnets

D       99.99.99.99 [90/156160] via 10.0.0.2, 00:08:54, FastEthernet0/0

     192.168.1.0/32 is subnetted, 1 subnets

D       192.168.1.1 [90/156160] via 10.0.0.2, 00:36:51, FastEthernet0/0

     192.168.2.0/32 is subnetted, 1 subnets

D       192.168.2.1 [90/156160] via 10.0.0.2, 00:36:51, FastEthernet0/0

     192.168.3.0/32 is subnetted, 1 subnets

D       192.168.3.1 [90/156160] via 10.0.0.2, 00:36:51, FastEthernet0/0

2) Change to "eigrp stub summary" and the result changes as follows:

SevenHills-Lab(config-router)#eigrp stub summ

SevenHills-Lab(config-router)#

*Mar  1 12:32:22.168: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(10) 10: Neighbor 10.0.0.1 (FastEthernet0/1) is down: peer info changed

*Mar  1 12:32:22.232: %DUAL-5-NBRCHANGE: EIGRP-IPv4:(10) 10: Neighbor 10.0.0.1 (FastEthernet0/1) is up: new adjacency

SevenHills-Lab(config-router)#do telnet 10.0.0.1

Trying 10.0.0.1 ... Open

CUCM-ROUTER#sh ip rout ei

D    192.168.0.0/22 [90/156160] via 10.0.0.2, 00:00:23, FastEthernet0/0

Note that for this to work, the summary has to be manually configured on the interface with the stub summary configured.

Once again thanks very much indeed.

Best Regards,

Mohan