Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

Redundant Metro-E Connections

Working with a client that has a 3750 connected to a Metro-E to link up to their remote branches.  The 3750 has a L3 port interface connecting to the Metro-E.  Their provider is pulling a 2nd fiber (from a separate CO, different fiber path) to give them additional WAN redundancy.  I see that they have two options to connect:

1) Pull into another port on the same 3750 stack (this is their Core).  Move the L3 ip address to an SVI, put both ports in the same VLAN and let Spanning tree block one of them.  Simple, fairly quick failover ...

2) Pull the 2nd link into another stack, add L3 SVI interfaces to the 2nd stack for all the internal VLANs and a L3 switchport for the Metro-E.  Then use HSRP.  Less simple (have to create a second core, add HSRP, ...) but keeps STP out of the picture.

Any thoughts, suggestions appreciated.

Nagaraja Thanthry
Cisco Employee


Both options are viable and have their own advantages/disadvantages. If you

go for the first solution i.e. create SVI and put both ports on the same

VLAN, you are depending upon the ISP switches to participate in

spanning-tree calculations and blocking a port. If the ISP switches do

participate in spanning-tree, then you can configure uplink-fast/backbone

fast features to reduce the failover time. However, if there is any

spanning-tree events in the ISP network, that would trigger a spanning-tree

recalculation in your network as well. You need to be aware of this and have

adequate precautionary measures implemented to avert any network issues.

The second solution based on HSRP is comparatively better in that an ISP

event will not trigger an event in your network as well. But again, the WAN

redundancy will depend upon the track timers you have configured.

One another option you could consider is EtherChannel (if the ISP supports

it). In this case, the redundancy can be instantaneous and if one link goes

down, the switch will use the second link automatically. Also, it will give

you load balancing capabilities. But you need to check with the ISP to see

if it is supported in your environment.

Hope this helps.



Thanks for your thoughts ...

My experience with Metro-E is that the whole Metro -E cloud behaves like one big L2 device that just passes along anything you feed it, their devices would not participate in my spannng tree calcs, my BPDUs are contained within my EVC and it is up to me to manage that.

The etherchannel would be great but 1) the last provider I worked with didn't support aggregated links and 2) in this case the carrier's links will terminate at two geographicaly separate locations on their cloud so my guess is that it wouldn't be an option.

I may just use L3 and a routing protocol to use both links.

Thanks for your input ...