09-11-2012 07:24 AM - edited 03-07-2019 08:49 AM
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.
Solved! Go to Solution.
09-11-2012 03: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 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
09-12-2012 06: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
09-12-2012 06: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
09-11-2012 03: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 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
09-11-2012 04:09 PM
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,
09-11-2012 04:16 PM
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
09-11-2012 04:28 PM
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.
09-11-2012 04:37 PM
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
09-11-2012 04:51 PM
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
09-11-2012 05:23 PM
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
09-12-2012 12:42 AM
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
09-12-2012 06: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 c