Multilayer Campus Design
Layer 2 Access with Layer 3 Distribution
im trying to set up a network with a l3 in the distribution and a l2 in the access
L3 L3 (3845)
But im getting in to troubles when i deploy it
The core is 3845 routers the distribution is 3750 switches talking in between them EIGRP the cross link is a L3 ether channel,
The L2 switch is also a 3750 switch with a MGT VLAN
The vlans are configured on the two distribution switches as (SVI's) and are know in the whole network, no issues there
The problems staring when i test the failover (HSRP) , i disconnect a trunk on the l2 switch and all the network is falling,
EIGRP neighbors go down
HSRP takes a long time to fail over
All Vlan disconnect
but when i make the crosslink a L2 Trunk... then all is good
Who can advise?
I would suggest you have a L2 etherchannel between the core switches and routed ports that connect to the 3845. If the etherchannel is L3, then the HSRP hellos actually flow down your trunks and hence a trunk disconnect would lead to HSRP missing hellos
Since you do not have a cross connection i.e each 3845 has only one connection to the core, you can define a /30 SVI (vlan should be allowed on the L2 etherchannel trunk) and run eigrp over it. This will ensure the required redundancy in terms of failover to the other 3845 if you lose the connection to one 3845.
Other possibility would be to stack the 3750's into one logical switch rather than etherchannels and still maintaining the redundant connections to the physical boxes
Thanks for your fast reply
Regarding the sentence you can define a /30 SVI (vlan should be allowed on the L2 ether channel trunk) and run EIGRP over it.
This is exactly my issue trunk is a layer 2, SVI is layer 3 ,I can choose only one either a trunk or an L3 p2p for EIGRP,
If I choose L2 then I lose my secondary 3750 (distribution) switch EIGRP wise (no L3 communication)
Do you see what I mean?
No you don't lose your L3 communication. if you have a L2 trunk between your 2 3750's with a vlan 2 SVI on each then they will see each other as EIGRP neighbours and will form an adjacency.
A L2 trunk does not mean Layer 3 cannot communicate over it.
I would like to also suggest further consideration of Narayan's note for the possibility of stacking.
It would allow equal cost outbound WAN routing (although EIGRP can support the unequal cost, if you configure it).
It would allow the dual uplinks to be used in a channel configuration.
It simplifies the topology, both L2 and L3.
It increases the bandwidth between the two 3750s.
I agree wholeheartedly with what Narayan has said. Just to add one thing. If you run a L3 link between your 2 distribution 3750's then HSRP will have to travel via the access layer.
It's difficult to say without seeing all your topology but if you disconnect a trunk then it may well be that STP needs to reconverge before any packets can be passed through the access layer.
As Narayan recommends a better solution is to connect your 3750 switches with a L2 link and ensure that the link between the 2 3750's is not getting blocked by STP.
I would have to disagree with Narayan's recommendation to connect the core "switches", routers, really, with an L2 etherchannel.
There is no reason to extend the L2 switch domain up to the core and thereby expand the failure domain in the event of an L2 loop. The core -- when deployed in an expanded tolopology, not a collapsed core -- should be a 100% routed (L3 switched) layer. In fact, for the last 2 years, Cisco has been pushing its routed access layer design, which will get rid of the L2 trunks between access and distro altogether and have them replaced with L3 routed uplinks. The purpose is to minimize the switched domain and mitigate the occurence of an L2 loop.
The reason why your failover test failed was that HSRP requires that both the active and standby nodes be placed in a common subnet. That's why it worked when you turned the inter-switch link between the distro layer switches into an L2 trunk. You had effectively extended the vlan across the layer, which is what you're supposed to do.
It's true that you're running a lopped triangle toplogy, so as Jon pointed out, once STP converges, traffic will once again begin to flow from the access layer.
From Narayan's post
"I would suggest you have a L2 etherchannel between the core switches and routed ports that connect to the 3845"
So I'm not sure Narayan is suggesting running Layer 2 in the core. The way i read the post was to run L2 between the distribution switches and run routed links to the 3845's which form the core of the network. I think Narayan just referred to he 3750's as the core switches.
Mind you i could be wrong.
You may be right and I did think of that. But I did want to clear that point up because it's important.
So easy to misread something, when reading these posts. (Not that that ever happens to me; cough.)
Ishai refers to the 3845s as the "core" while Narayan refers to the 3750s as the core. (As an aside, looking at the topology diagram, I too would think of the 3750s as core and the 3845s as WAN edge.)
However, given a layer 2 access edge to the 3750s, Narayan's suggestion would be the normal recommendation. (I suspect we all agree.)
Victor's recommendation, would be preferred with routed paths, such as his description of using L3 at the edge. (Here too I suspect we all agree.)
Ishai, please be aware that these posts often address just the issue asked, with additional information sometimes thrown in, but there might be much more unsaid. For instance, we haven't discussed with Narayan's suggestion which port or ports should normally block within the spanning tree loop.
We haven't discussed how you allocate VLANs. If you have any that span edge switches, your topology opens itself up to the possible issue of unicast flooding (also negated if you stack the 3750s).
Cisco's web site provides some excellent design guides; worth reading.
I suspect you're complicating and confusing things even more by doing a play-by-play of what he/she said...
It's simple and doesnt require Perry Mason and being verbose. ;-)
If it's a collapsed core design, then you will have to have an L2 trunk at "the core" to satisfy HSRP's common subnet requirement, which I stated in my post. If that's what Narayan thought, which is what I suspect, too, as I told Jon, then all is clear.
If it's an expanded core (where you have separate core and distro layers) then I recommend you keep the L2 link at the distribution layer.
Perhaps, you're correct about "complicating and confusing things even more", more on this in moment, but I also had an alternative motive. I wanted to work in the possible issue of unicast flooding which I had forgotten to mention in my original post.
As to "complicating and confusing things even more", I thought your first two paragraphs could mislead, especially the first "I would have to disagree with Narayan's recommendation to connect the core "switches", routers, really, with an L2 etherchannel.". In fact, I was going to write an I disagree with your disagree, but Jon's post arrived, and your follow up.
Even your follow up "You may be right and I did think of that. But I did want to clear that point up because it's important.", I too thought this might mislead, since it's not totally clear, I think, whether you now fully agree with Narayan's suggestion and what point you were trying to emphasis.
For myself, from reading your posts on this thread, and reading other of your posts (i.e. additional understanding of your knowledge), you didn't make any errors beyond perhaps possibly confusing the OP on mixing core vs. edge issues, when the question started with HSRP. Again, your information was correct, but presentation of additional issues might have confused a less knowledgeable reader, especially their application.
So, I had hoped to try to make clear, by way of he/she said, the points both you and Jon were making, for other readers and the OP. Apologies to all, and especially to you Victor, if I did make things even more complicated and/or confusing.
Speaking for myself no apologies necessary. I have always found your posts particularly insightful and appreciate the time you take with them.
Victor, totally agree with what you were saying re. the topology, just thought we may have confused the OP.
Thanks to you all guys,
I'm glad I'm not alone with this issue and all are really trying to help, thank you
Let's summarize (see drawing),
I've a two 3845 routers (WAN routers) and two 3750 as the core/distribution switches
All there 4 network components I would like to have speaking EIGERP
I have also a L3 cross link (ether channel) in between the 3750's,
So far all is good and the network is working, But When I disconnect one of the trunks to the access switches (L2) the problems starts
The SVI's (my Vlans) that I configured on the 3750's go down, I see that HSRP takes very long to switch, And all my EIGRP neighbors are going down as well
Is this a Spanning tree issue, Convergence (PVST)?
Now when I configure the cross link from a L3 to a L2 trunk all seems to work fine
So the questions I have now are as follow
Is this the right logic? Is this the way it should be (EIGRP with a L2 trunk ?)
And Spanning tree ive chosen for Rapid spanning tree protocol (802.1W, was PVST before) any tips?
Thank you all
Ill do some new test with a L3 cross link and Rapidspanning tree
So the questions I have now are as follow
Is this the right logic? Is this the way it should be (EIGRP with a L2 trunk)?
And Spanning tree I've chosen for Rapid spanning tree protocol (802.1W, was PVST before) any tips?
Thank you all
I know that Cisco is promoting to implement L3 all the way to the Access layer, but it is not possible for me with this design because I have more then one vlan per access switch and this VLAN is being used on other access switches too,
I'm assuming that on each 3750 distro switch you have the same vlans running HSRP eg
int vlan 10
ip address 192.168.5.2 255.255.255.0
standby 10 ip 192.168.5.1
int vlan 10
ip address 192.168.5.3 255.255.255.0
standby 10 ip 192.168.5.1
With a L3 etherchannel between your 2 distro switches the HSRP packets have to traverse the access-layer switches ie. they cannot go directly across the L3 etherchannel.
So, and again it is difficult to be precise without configs etc, when you disconnect a trunk from the access-layer to the distro layer an STP calculation will in all probability start. While STP reconverges no traffic is passed over the access-layer so that means no HSRP traffic can go between the 2 distro switches.
So bearing in mind you cannot do L3 at the access-layer as you say i would recommend
1) Migrate to RSTP - this should significantly speed up your convergence times.
2) Optionally you can change the L3 etherchannel between your distro switches to a layer 2 trunk and then ensure that any blocked ports are to the access-layer switches and not between the 2 distro switches.
Oh yes and
3) Stop disconnecting trunks :-)
Let us know how you get on with your tests
The convergence should be faster even with PVST if you make sure the core switches are the root for the vlans and you have uplinkfast enabled on the access switches.
Never thought that there would be so much discussion on this topic :-)
It's a tough topic but confusing im glad a lot of people are looking at it,
Thank you Narayan for getting me in the right direction
Ill do some test today and let you know
Thank you for your Feed back
I think the RSTP will change the speed /convergence big time but I also think that it is not possible without the L2 Trunk,
Ill do the to test
Test 1 L3 ether channel with RSTP
Test 2 L2 trunk with RSTP
Ill let you know later what I found out
Thanks for now
No problem, although having just reread the post i've made a bit of a basic error. So before someone a lot smarter than me ie. all the others on this post, jumps in
It isn't an STP issue as you do not have any loops in your network. Because you are running a L3 etherchannel between your distro switches and L3 uplinks to your 3845 routers all your trunks from the access-layer should be forwarding.
Apologies for misleading you.
re: STP loops
From one of OP's later posts:
I know that Cisco is promoting to implement L3 all the way to the Access layer, but it is not possible for me with this design because I have more then one vlan per access switch and this VLAN is being used on other access switches too,"?
re: uplink fast
Automatic feature of RSTP?
Hi to all,
The good news is that's it working
The bad news is that im back to L2 between the Distribution switches.
This is the short version of the tests
I have tested with two access switches and two distribution/core switches
I had 2 laptops on two different Vlans, pinging each other from two different switches,
During the many trunks disconnects and I've tried many variations (with and with out cross connect, one with the two primary trunks disconnected, and so on â¦
It was working but not fast and some pings were failing (timeouts)
I connected a third access switch during these test and I've notice that all was working good suddenly, (the third switch became a transit switch all traffic was going through it),
Is tough to explain / show with out the config. Files
But the moment I reconfigured to L2 trunk (etherchannel) all test were good with out any ping timeouts
So now you know what I chose for,
Thank you all for the great tips and different views