Multiple switches one trunk port

[dan.letkeman]

Hello,

We have 7 3560's in 7 different locations connected to our providor for wan access.  Our provider has given us a copper cable at each point and we have connected it directly to our 3560 switch at each location.  Each port is configured the same way at each location.  Each switch is running eigrp.

All of the switch ports on each switch are configured as a trunk and vlan 299 had the ip address for the eigrp connection:

interface GigabitEthernet0/14

switchport trunk encapsulation dot1q

switchport trunk native vlan 299

switchport trunk allowed vlan 299,205,245,757

switchport mode trunk

This setup is working as each switch see's all of the other switches as an eigrp neighbor.  We have also made sure that the switch at our head office has spanning tree priority for vlan 299.

So the problem is, if there is a change in the topology at one of the locations it usually causes one or more of the other connections to go down for some reason.  We just cannot pinpoint what is causing this change.  There are no log's or anything that helps other than an eigrp hold time expired message.

Is there a different way we should be configuring this?  Should our provider be configuring something differently?

Thanks,

Dan.

[Peter Paluch · Accepted solution]

Hello Dan,

You seem to be using a kind of Layer2 VPN (VPLS, Q-in-Q or MAC-in-MAC) in which your tagged frames are transparently tunneled across provider's network. It is possible that the STP is tunneled, too, and that is precisely what I am aiming at: perhaps the topology change occuring on one site causes STP to recalculate the active topology, and it may take 50 seconds in the worst case, and 30 seconds in the slightly better case. That could explain the reason why your EIGRP adjacencies are flapping, as the Hold time in EIGRP is 15 seconds.

Are there any physical loops in the network between your sites? Theoretically, if there was no STP running between the sites, would there be a chance of a switching loop? So far, it seems that your topology is basically a star topology - the provider being the central "node" while your sites form the spokes, with no direct spoke-to-spoke links. Deactivating the STP on the trunks towards the provider could perhaps help in this case. If you are willing to try this out, add the following two lines to the trunk interfaces towards the provider:

spanning-tree portfast trunk

spanning-tree bpdufilter enable

The first command allows the trunk port to become forwarding rapidly (RSTP/MSTP should take care of that but it is not certain if your service provider speaks STP to you). The second command prevents STP BPDUs from being sent or processed on the interface. As I said, this might help but please be careful as deactivating STP in switched topologies must be done very, very cautiously.

Best regards,

Peter

[dan.letkeman]

Wow, fast reply. 

There are no loops in the topology.  Our topology is a star like you mentioned and the providor would be the hub.  I had thought of of turning of spanning tree, but was leaning on the more cautious side and had not tried that yet.... I think that might be the only option to fix this problem.

Thanks,

Dan.

[Peter Paluch]

Dan,

What STP version are you running on your sites, anyway? Is it PVST, RPVST or MSTP? Can you also confirm that your provider is tunneling the STP across his network?

Best regards,

Peter

[dan.letkeman]

I am running RPVST on all of the switches.  Yes, I can confirm that the provider is tunneling stp.

[Peter Paluch]

Dan,

Thank you for the information. I wonder - is the EIGRP directly running on these switches, or are the EIGRP routers separate? I am basically trying to find out if the EIGRP routers are standalone devices possibly connected to these switches. If the ports towards the standalone EIGRP routers (if there are any) are not configured as PortFast ports then a topology change that creates a wave of RSTP Proposals/Agreements will put these ports to Discarding state and they will need 30s to recover.

Of course, ports between switches should never be configured as PortFast ports.

Best regards,

Peter

[dan.letkeman]

Eigrp is running on the 3560's.

Dan.

[Peter Paluch]

Hello Dan,

Thanks for the reply. Hmmm, the RSTP (or RPVST) should not cause such outages...

Anyway - I suggest proceeding with the commands to disable STP on the appropriate ports towards your SP, and let's see if that helps. If it does, we should probably investigate why is the RPVST failing to react rapidly.

Best regards,

Peter

[dan.letkeman]

I will also be investigaing potential problems with our provider's network as well.

Thanks,
Dan.

[singhaam007]

hello dan,

Explain bit more about what u changing in the topology ??

As you said you got “eigrp hold time expired message “

It could be

If no hellos are not received within the hold time, which is 15 seconds by default on most links, the router informs the neighbor that the neighbor relationship has been torn down and logs a syslog message

Check the routing table entries after the changes to verify the next-hop address is correct for the neighbor.

Other possibilities that can bring the neighbor relationship down are unidirectional links, uncommon subnet mismatches, mismatched masks, layer 2 problems, ACL deny statement, etc. may be after change these is an ACL with causing other links to go down.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml

I am still a learner but hopefully this will help.

Please rate if this helps.

thanks