Local Switching and Internet Access redundancy

Unanswered Question
Apr 8th, 2010

Hi fellow experts,

I have some queries regarding some redundancy design, as we're in the midst of swapping 7600 boxes with ASR9K. First of all, is it possible to configure the same vlan encapsulation on two different sub-interfaces belonging to two different physical interfaces (i.e. g0/7/0/0 & g0/7/0/1) of a same linecard (i.e 40x1GE LC)?

Now referring to the attached diagram that i've sketched out, there are 2 possible scenarios for link redundancy at a local access site.

The 1st scenario deals with a ptp circuit for a customer btw Site#1 and Site#3 across the MPLS. Since with 7600 we could just use int vlan as a conduit to link both physical interface before tunneling across the l2vpn circuit. So in the event of the active link fails (top UPE), the backup link (bottom UPE) takes over (Spanning-tree will take care of that). When we swap with the ASR9K, there is no notion of SVI and it uses sub-if with encapsulation dot1q. So here's what I came up with for the ASR9K (pls refer to the attached configlet). Would this be a good approach? Can this work?

The 2nd scenario is a bit tricky, as with 7600, the SVI is sort of disassociated from the physical interfaces (dot1Q trunks) that connect to the UPE. So in the event of active link failure (top UPE), the backup link (bottom UPE) takes over (again STP does the work!) - SVI remains up, IP address (gateway for CE1) is still reachable. Now with ASR9K, since the sub-if is tied with Physical interface how would I be able to approach this? I don't think its even possible to configure same IP address on two different sub-ifs (IP address is global IP, no VRFs is used), let alone trying to find if there's an equivalent to IOS interface "backup" cmd.

Thanks and very much appreciated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Laurent Aubert Fri, 04/09/2010 - 07:43

Hi,

In ASR9k, VLAN is port significant so yes you can match the same VLAN on different port.

For your untagged traffic, both UPE fo site 1 will think they are directly connected via two links so yes STP should take care about the loop

For your VPLS domain, if you are not using VLAN 100 on site 3, you need to pop the tag on both ASR9k. Also do you extend STP to site 3 ?

SVI is not supported in ASR9k today so you have to use unumbered interfaces instead:

interface Loopback1

ipv4 address a.b.c.d 255.255.255.255

!

interface g0/7/0/0.200

encapsulation dot1q 200

ipv4 point-to-point

ipv4 unnumbered Loopback1

proxy-arp

!

interface g0/7/0/1.200

encapsulation dot1q 200

ipv4 point-to-point

ipv4 unnumbered Loopback1

proxy-arp

!

I never tested it in this situation but from STP perspective those links should be seen as host connection.

Let me know if it works

HTH

Laurent.

frenzeus Fri, 04/09/2010 - 09:53

Hi Laurent,

Thanks for the confirmation on Scenario #1. Yup exactly what i was looking for. So I believe even if i run MST on the UPEs, the control traffic (STP BPDUs) are carried in Vlan 1 and since Vlan 1 defaults to untagged, i was hoping that matching "untagged" traffic and bridge btw those 2 ports with local connect on the asr9K to do the trick. No, STP will not be extended to site 3, the idea is to keep all STP stuff local contained within its Ethernet access domain.

As for the 2nd Scenario, that is indeed a bit tricky. With the configs that u proposed, however would I be able to run BGP over it with the CPE? Also, to the ASR9K, it would seem both interfaces are active but the 2nd interface should NOT be able to fwd/receive any packets over it since on the 2nd UPE STP should have blocked the port leading to the NPE, rite?

Thanks, once again.

Laurent Aubert Fri, 04/09/2010 - 10:51

Hi,

Scenario 1: It should work because both UPE are connected to the same NPE. The limitation of this approach is in case of a topology change it will not trigger any LDP MAC-Withdrawal. So it means in case of two NPE's, you need to wait for mac addresses to timeout on the remote NPE before convergence is complete.

The solution is to make the NPE MSTP aware just enough to make believe it's the root. You configure a static BPDU which will be sent to the access layer but the NPE will not process any received BPDU.

http://www.cisco.com/en/US/partner/docs/routers/asr9000/applications/ethernet/services/application/guide/esasr9kcnfl2.html#wp1331520

It's called MSTP-AG (MSTP Access Gateway)

Scenario 2: I can't tell as I never tested it. The ASR9k will not do any L2 switching between its ports. It considers each of its interface as a L3 interface so you need to test how the box react if the primary link failed (should work if the interface get down). If after the failure the interface stays UP, I'm not sure you can converge as it's still have a MAC entry for the CE pointing to this interface...

So test it and let me know ;-)

Laurent.

Actions

This Discussion