EEM Script for Primary and backup Layer2 Links

[darren.frowen]

Hi,

Sorry but I am new to EEM and would like a sanity check on my two EEM applets. We are trying to isolate our two DC's at layer2 from Spanning tree topology, filter BPDU's on all EoMPLS uplinks to create two active DC's. To prevent loops we have the backuplink shut and Primary active. If the primary was to fail then the back should be brought up and also taken down once the Primary comes back up. This is per Cisco recomendations for L2 DC to DC inteconnects and redundant links. The two applets are as follows;

event manager session cli username "XXXXXX"

event manager applet Enable_Backup_Link

event syslog pattern "Interface GigabitEthernet1/0/39, changed state to down"

action 1.0 cli command "enable"

action 1.1 cli command "configure terminal"

action 1.2 cli command "interface gig2/0/45"

action 1.3 cli command "no shut"

action 1.4 syslog msg "Primary link went down, backup activated via EEM"

event manager session cli username "XXXXXX"

event manager applet Disable_Backup_Link

event syslog pattern "Interface GigabitEthernet1/0/39, changed state to up"

action 1.0 cli command "enable"

action 1.1 cli command "configure terminal"

action 1.2 cli command "interface gig2/0/45"

action 1.3 cli command "shut"

action 1.4 syslog msg "Primary link back up, backup deactivated via EEM"

Would the above two applets work as expected in my brief?

Thanks in advance

Regards

Darren

[avayner]

Darren,

On which device are you running these scripts? It seems like this is a single device that terminates both primary and backup links, so it is actually a single point of failure...

There is a more advanced solution where the EEM scripts are deployed between 2 redundant nodes, and we use a semaphore concept to maintain a distributed state machine across both nodes.

Take a look here:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_493718.html#wp9000295

The solution is described in detail in this book:

http://www.ciscopress.com/store/interconnecting-data-centers-using-vpls-ensure-business-9781587059933

HTH

Arie

[darren.frowen]

Dear Arie,

Thank you for your response. Yes I had read that document hence my question as we wish to limit the spanning tree between DCs. We have a dual 3750x stack with diverse WAN connections on each stack member, the idea being to filter the BPDUs at the WAN egress ports. I have now realised also that we require ip services image also to support the EEM applets. Our provider has ME3400 would that support the semaphore communication to activate deactivate the pseudo wire? In the short term do you feel the scripts are correct and would work as expected?

Thanks for your support

Regards

Darren

[avayner]

Darren,

If you are using a stack of 3750's (or any other solution where you have a single logical device with physical multi-chassis design), you can run Multichassis Etherchannel across the MPLS domain.

Imagine your 3750 stack connected with 2 links to the remote stack. These 2 links can be bundled, and you would have a redundant port-channel.

You should disable STP on this port-channel to create the STP seperation between the DCs

Your 3750 could be part of the STP topology in the local DC, removing the L2 loop.

If your DC distribution (where the 3750's are connected to in the DC) is something like Nexus 7000 or 6500/VSS, you can use vPC (or MEC for 6500), getting the benefit of loop-free active/active links.

This design does not require the EEM scripts, but would work only for a pair of DCs.

Arie

[darren.frowen]

Hi Arie,

Yes sorry I forgot to mention also that we do not have symmetrical redundant links they are 1gig and 100m respectively. Also different providers, this was the reasoning behind the EEM applets. We are looking to completely redesign the DC hardware and certainly Nexus vPC and the 6500s VSS is something we are looking at as we have three DCs to interconnect resiliently and limit the spanning tree to each DC.

Regards

darren

[avayner]

You can still try and use LACP to bundle the 2 links, but run them in Active/Standby.

In LACP you can use link priority and the "lacp max-bundle 1" command to make only one port active at a given time.

The "max-bundle 1" would make sure that only 1 port is used, and you just set the port priorities so that the 1GE port is preffered.

I am trying to use "features" and not scripts where possible... Also, the script shuts down the alternate path, so if you have a failure, it may not actually be ready to take traffic in a convergence event.

Another common issue with EoMPLS is that the link state does not go down in some cases. LACP would run keepalives over the link, and would detect the failure.

Arie

[darren.frowen]

Dear Arie, 

That is great stuff there that you have recommended, never knew you could do that. Great advice thank you it is greatly appreciated.

Regards

Darren

[darren.frowen]

Dear Arie,

I have been unable to find any documentation to support your last update regarding the LACP support for being able to bundle links with different link speeds. To confirm one link is at Gig and the other is at 100M. Any chance you can provide me with a link that would satify your recommendations? The intention is for the LACP ethercnahhel to form across two stack members, i know PaGP is not supported for this method on the 3750X's.

If we cannot perform in this manner the my second alternative is to use the flex link technology to achive the same outcome? You thoughts greatly appreciated.

Regards

Darren

[avayner]

Actually, you are right - you need the same physical port speed to form a port-channel.

Saying that, your ports are 1GE, and even though the SP is delivering 100Mbps, are they handing it off as a 100Mbps link, or a 1G link? (often it would be a 1GE link)

In your case I would say that Flex-Links could be a valid approach, and may actually be easier to configure.

[darren.frowen]

Hi Arie,

Yes you are correct they are both Gig physicals however we have for some reason at one end (historical) forced down to 100M Full. We have to investigate that for a start. We are now trying to figure out if the line protocol will go down if anything in the EoMPLS network blocks the layer2 encapsulated traffic and make sure we do not have a black hole situation whee the interface never goes down locally at each end. Our provider has been kind enough today as they couldn't answer the same question to build a second pseudo wire to test the theory. So we are still possibly looking at the LACP Etherchannel and the Flex link both requiring further investigations. Will update you when I have some further information for you. Once again I really appreciate your time on this.

Regards

Darren

[avayner]

You can also look at implementing UDLD as an end to end keepalive