L2VPN Xconnect redundancy design question

msyazdancc13 · ‎12-11-2016

Hi All

Need a bit of advice on whether the following design to add redundancy will work:

Current setup:

Access Layer switch Interface Gi1/0/1 (trunk) ---> Datacentre 1 Core switch Gi1/0/1 L2VPN XCONNECT VC 1210 ----> Datacentre 2 Core switch Gi1/0/1 L2VPN XCONNECT VC 1210 ---> Access layer switch interface gi1/0/1 (trunk)

Essentially a trunk link between the access layer switches in the different DC's via a xconnect VC pseudo wire.

Current config:

DC 1 Access layer switch:

interface GigabitEthernet1/0/1

switchport trunk native vlan 999

switchport trunk allowed vlan 100,200,300

switchport mode trunk

speed 1000

duplex full

DC 1 Core switch:

interface GigabitEthernet1/0/1

no switchport

mtu 1600

no ip address

no keepalive

speed 1000

duplex full

xconnect 109.54.32.10 1210 pw-class l2vpn

DC 2 Core switch:

interface GigabitEthernet1/0/1

no switchport

mtu 1600

no ip address

no keepalive

speed 1000

duplex full

xconnect 109.54.32.11 1210 pw-class l2vpn

DC 2 Access layer switch:

interface GigabitEthernet1/0/1

switchport trunk native vlan 999

switchport trunk allowed vlan 100,200,300

switchport mode trunk

speed 1000

duplex full

I need to add redundancy between the different DC's access layer switches with a new link, I can not change to Layer 3 as the current setup is stretched vlans between both DC's and there are servers in both DC's on the same IP range / VLAN, thus without a re-ip'ng the devices the L3 option is not going to be feasible.

The access layer switches in both DC's are in a stack of 2, what am aiming to do is provision a second link for redundancy.

So a port-channel on both access layer switches, a 2nd interface (trunk) same as the current.

Whats confusing me is the core interface config, currently the core interface is configured with the xconnect VC, will it be possible to create a portchannel on the CORE so the new interface uses the same config and xconnect VC (1210) as the current interface?

Could you guys advise whether the setup proposed will work, if not please could you suggest a viable solution.

Many thanks in advance

Giuseppe Larosa · ‎12-11-2016

Hello msyaz,

EoMPLS is point to point in nature:

to carry a port channel of two member links between DC1 and DC2 you need to configure two parallel pseudowires on two different edge interfaces.

The MPLS backbone is not involved at all in this service.

>>

The access layer switches in both DC's are in a stack of 2, what am aiming to do is provision a second link for redundancy.

So a port-channel on both access layer switches, a 2nd interface (trunk) same as the current.

The solution as I have written are two parallel EoMPLS pseudowires one for each port channel member.

Hope to help

Giuseppe

msyazdancc13 · ‎12-11-2016

Hi Guiseppe

Thanks for your reply.

With regards to

"you need to configure two parallel pseudowires on two different edge interfaces"

Can I use the same PW VC (1210) on the new interface or have to provision a new VC?

Is it possible to use use the same VC on more than 1 interface? if I could associate the current VC to a port channel on the CORE and then add the member interfaces which will be the 2 uplinks that would work, is this possible?

My concern with provisioning another pseudowire is, each uplink from the access layer switches will uplink to a different port on the core and each interface is using its own pseudowire VC.

If one member interface in the portchannel on DC1 stack for example goes down, switch stack in DC2 will be unaware of that link going down, so if it sends traffic out the link / VC that connects back to the interface that has gone down on the other end, traffic wont be delivered.

Is there a way around this?

Thanks again for your advice

Adam Vitkovsky · ‎12-12-2016

Hi,

Depending on what model of the core switch/router you are using, configuring port-channel as PW interface on the core switch is possible (so Core SW talking LACP with access SW).

And you can then connect DC1-Core and DC2-Core switches with multiple core links, however you might need to tweak the hashing to force one PW on one core link and other PW on other core link (cause it might happen that by default both PWs will be hashed to the same core link).

interface port-channel 123

no switch-port

mtu 1600

xconnect 1.1.1.1 123 pw-class l2vpn

If the above is not possible on your core-switch platform then I think the only other option is what Giuseppe has proposed.

The parallel p2p PW and just relying LACP between access-switches is the simplest of solutions but I’m concerned with the convergence speed.

If the link between the access-SW and core-SW goes down on one end the problem might get unnoticed by the access-sw on the other end until LACP reacts.

And LACP might notice that there’s a problem with the link after 3 seconds (that’s when fast LACP hellos are configured).

I’m not sure whether when the local interface goes down, then LACP will notify partner at the other end (via the working bundle member link) that there’s a problem with a particular member link, allowing partner to take out the affected member link from the LACP bundle right away –if yes then this should be much quicker than 3 seconds.

The PW VC ID has to be unique per LDP session (pair of boxes).

adam

msyazdancc13 · ‎12-12-2016

change of setup, since the EoMPLS is just point to point, essentially Layer 2 between the switches in each DC. I will let Spanning tree just block one link at either end.

Question is, are BPDU's sent over the pseudo wire between the switch stacks??

Giuseppe Larosa · ‎12-12-2016

Hello,

the answer is positive STP BPDUs can travel over the two parallel pseudowires and one end will end in blocking state.

You will need to use port based EoMPLS OR L2 protocol tunneling over EVC based EoMPLS.

Hope to help

Giuseppe

msyazdancc13 · ‎12-12-2016

Hi

This sounds the best way to go, please could you describe what config changes are needed to the current interface config below, to "to use port based EoMPLS OR L2 protocol tunneling over EVC based EoMPLS."

DC 1 Core switch:

interface GigabitEthernet1/0/1

no switchport

mtu 1600

no ip address

no keepalive

speed 1000

duplex full

xconnect 109.54.32.10 1210 pw-class l2vpn

DC 2 Core switch:

interface GigabitEthernet1/0/1

no switchport

mtu 1600

no ip address

no keepalive

speed 1000

duplex full

xconnect 109.54.32.11 1210 pw-class l2vpn

msyazdancc13 · ‎12-12-2016

Having researched, I found another option:

- Create a new VC to run parallel to the current VC on both ends, then specify the new VC as a backup peer of the current VC.

This means only the 2nd link / VC will become active if the current VC fails.

My only question / concern with this is, if the interface on the current VC goes down on DC1 core, it will send traffic over the backup VC...

Will the core in DC2 also bring down the primary VC that went down on the far end and resume service on the backup VC?

Adam Vitkovsky · ‎12-13-2016

That’s not how it works

The backup peer is for scenarios like this:

https://www.google.sk/search?q=pw+redundancy&client=firefox-b-ab&biw=1525&bih=752&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjYg5m92PDQAhUDtBoKHWe2DhcQ_AUIBigB&dpr=0.9#imgrc=ZbADPy-aE5xbiM%3A

-the backup peer is the backup PW at the bottom that will be activated only when the primary PW goes down.

I think that extending any L2 protocol between the DCs is a bad idea but choosing between relying on STP and relying on LACP I’d rather chose LACP.

https://www.google.sk/search?q=pw+redundancy&client=firefox-b-ab&biw=1525&bih=752&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjYg5m92PDQAhUDtBoKHWe2DhcQ_AUIBigB&dpr=0.9#tbm=isch&q=lacp+over+pw&imgrc=Z2QuxNeP_qNhjM%3A

adam