Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Failover takes long time across different Metro ethernet link

We have 2 metro ethernet link from different service providers (Reliance & TATA). When the Reliance metro links goes down we noticed 25 time out packets before the service back online. We tried the following features but no luck. Please note metro link interfaces are configured as DOT1Q/TRUNK port. The biggest challenge is that switch at end "A" cannot recoginize the remote end port down. (As its metro link).

1) Etherchannel

2) UDLD.

3) FLEXLINK

Any good soultion is highly appreciated.

Many thanks in advance.

9 REPLIES
Silver

Re: Failover takes long time across different Metro ethernet lin

What kind of Services are you running over the Metro ? Your Layer 2 Convergence would depend on the convergence of the SP N/W. If u can tell more abt the n/w connectivity, there can be a solution. For eg if you are using OSPF, you could use Fast Hellos etc.

New Member

Re: Failover takes long time across different Metro ethernet lin

Its pure layer 2. (No routing protocol just pure layer 2 convergence).

Silver

Re: Failover takes long time across different Metro ethernet lin

Then the number of drops on the link would clearly depend on your SP's STP/RSTP/MPLS Convergence. The ideal thing is for you to take it up with the provider and see if he can tweak the values for you. Are you tunneling STP Packets through this metro ethernet ? If yes are you using RSTP ?

New Member

Re: Failover takes long time across different Metro ethernet lin

I am planning to configure RAPID PVST and apply one switch as PRIMARY FOR VLAN 1 ,This test is likely to be carried out be early next week.,

Will keep posted on the results for the benefit of everyone.

Silver

Re: Failover takes long time across different Metro ethernet lin

Hi,

Did u tried Spanning tree port fast command. One of the link gone down, the other port will become active immediately.(from blocked state to forwarding state).

New Member

Re: Failover takes long time across different Metro ethernet lin

Balaji,

Did.,no luck.??

New Member

Re: Failover takes long time across different Metro ethernet lin

Hi Thiru,

As I can understand by your explanation you have a Layer 2 VPN between 2 sites, dual homing on RIC and Tata, and there are issues with convergence in the Service Provider network.

So it's assumed that you are using two different ports on your CE to connect to RIC and Tata separately, also it is quite evident that your SLA with RIC does not talk about backup within RIC, having seen a few Metro deployments, almost all the Providers give a backup path within their networks, with a sub 50 msec convergence.

I would request you to give more details with respect to the current configuration you have on your CEs, also simultaneously verify the backup options with RIC.

Cheers,

~sultan

New Member

Re: Failover takes long time across different Metro ethernet lin

Yep., We are in process of getting this done through RIC as TATA has clearly mentioned that they are in transparent mode.

If I get any improvement will post for everybody interest.

New Member

Re: Failover takes long time across different Metro ethernet lin

Hi Thiru,

well first of all i would like to make a point here that you cannot achieve failover/convergence between Reliance and TATA at SP level due to the fact they being strategically different telcos.

Secondly i agree with Sultan for chasing the SP to tune their parameters for better convergence within their network.

From your side you can you can use commands like backbone fast on trunk interfaces connecting SP

However in context to the Converstation topic - Metro: Failover takes long time across different Metro ethernet link , if you want to achieve failver between two providers or ethernet links i would suggest following :-

What service provider would provide u would be either ERS ( opaque to customer BPDUs ) or EWS ( transperent to customer BPDUs ) in their L2 vpn offerings. These are basically psuedowires over mpls networks.

In such setups , typically a customer is connected to U-PE which is backhauled to PE which is connected to MPLS network of SP. The link between U-PE and PE would be ideally a trunk and link between customer and U-PE port on which customer is connected would be either access-port in case of ERS or trunk-port in case of EWS or depending on number l2 ckts of ERS or customer is buying from the SP.

In this solution there is an inherent problem of O&AM where a port connected to user DOESNT GO DOWN even if there is problem in L2 ckts or vc/vlan being used in l2 ckt over the MPLS network and hence you dont get any trigger of port/protocol going down as seen traditionally in serial or atm or fr links.

You need to achieve failover at your level i.e on ur CE connected on both end of L2 vpns from these two providers on the basis of service ( ERS or EWS ) taken from the provider

For ERS ( suggested using router )

=======

assumming that you have routers connected behind ur l2 vpns

CE-A-P1-|PE------ l2 Rel ------PE|-CE-B-P1

CE-A-P2-|PE------ l2 Tata ------PE|-CE-B-P2

You can look forward for following things to achieve quick failover and redundancy over your l2 links using :

1) dynamic routing protocol

2) rtr / track function of cisco ios to track the next hop and switch between routes to destination

3) GRE tunnel over ethernet links and use of floating routes by tracking the state of GRE tunnel using keep-alives

For EWS ( suggested using l2 switch )

=======

SW-A-P1-|PE------ l2 Rel ------PE|-SW-B-P1

SW-A-P2-|PE------ l2 Tata ------PE|-SW-B-P2

As mentioned above EWS is transperent to customer bpdu and

hence I would propose that you can try running your own STP which is tunneled into the EWS over MPLS. Hence you achieve failover at l2 level too.

I have never tried this soln , I would suggest you try the same and check the success !!! , but i can suggest that theoritcally the operation would be like.:

1) When both the links are UP

- Either of the switches would be a root and one of the link would be in forwarding and other shall be in blocking as per STP calculations

2) When one of the link goes down due to a) physical port connecting the SP goes down b) VC/Vlan over SP MPLS network going down

- In case (a) the second port connecting the other end of your switch will take over from blocking to forwarding mode

- In case (b) the port which ( SW-A-P1 ) was in forwarding mode shall not recieve bpdu over that link and after some time it will force the re-calculation of STP and the second port ( SW-A-P2 ) shall become forwarding and link is switched over. In this case though the initial port will still remain in forwarding mode but as there is no BPDU being recieved over that port there will be no transfer of data . Please avoid using spanning tree bpdufilter on these ports.

3) When the broken link as per pt no 2 comes UP again

- SW-A-P1 again starts recieving the BPDU and due to spanning tree active the second port ( SW-A-P2 ) goes into blocking mode.

I would still suggest to use router as CPE in both scenarios ( EWS /ERS )

RAJ

343
Views
0
Helpful
9
Replies