I currently have my transit providers plugged directly into my router. I really like this arrangement because when the ISP goes down this typically downs the interfaces which results in BGP peering being dropped immediately. This results in very little loss while everything re-routes to the secondary provider (vs waiting for a timer to expire).

Due to restrictions on the number of ports I'm opting to place a Cisco N9K in between the router and the transit providers (ISP links plug into switch, routers plug into switch). Is it possible to replicate the original behavior such that if a given interface on the N9K goes down I can automatically down other interfaces of my choice?

The switch is an N9K-C93180YC-EX. The router is a Juniper MX204.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 16, 2020 at 23:33

5 Answers 5


IP SLA Tracking. Cisco's ISP Failover with Default Routes using IP SLA Tracking document details:

This document describes how to configure WAN (or ISP) redundancies, wherein multiple WAN links terminate on the same end router. This document also explains how to configure Network Address Translation (NAT) when there are multiple ISP's for internet connectivity and you want seamless failover i.e. when Primary ISP goes down then Secondary takes over with correct NAT with the use of the secondary ISP's public IP address.

enter image description here

Another Cisco document Configure IP SLA Tracking for IPv4 Static Routes on an SG550XG Switch through the CLI explains:

When using static routing, you may experience a situation where a static route is active, but the destination network is not reachable via the specified next hop. For example, if the static route in question has the lowest metric to the destination network and the status of the outgoing interface to the next hop is Up, however the connectivity is broken somewhere along the path to the destination network. In this case, the device can use the static route although it does not actually provide connectivity to the destination network. The Internet Protocol Service Level Agreement (IP SLA) Object tracking for static routes provides a mechanism to track the connectivity to the destination network via the next hop specified in the static route. If connectivity to the destination network is lost, the route state is set to Down, and if available, a different static route (which is in state Up) can be selected for routing traffic.

Similar to IP SLAs tracking for Virtual Router Redundancy Protocol (VRRP), IP SLAs object tracking for static routes also relies on IP SLAs operations to detect connectivity to destination networks. IP SLAs operation sends Internet Control Message Protocol (ICMP) packets to the address defined by the user (a host on the required destination network), and also defines the next hop to use for the ping operation. IP SLAs operation then monitors success or failure of replies from the host. A track object is used to track operation results and set the status to Up or Down, based on the success or failure of the ICMP destination. The track operation is assigned to a static route. If the track status is down, the static route state is set to Down. If track status is Up, the static route state remains Up.


If your transit providers are willing to configure BFD with you, yes. That's its intended use.

  • Thanks. Let's say I have an odd provider who won't configure BFD is there a way I can accomplish the above with the switch. Oct 5, 2020 at 16:53
  • 3
    No practical way. You could rig something up with Real-time Performance Monitoring (see juniper.net/documentation/en_US/junos/topics/concept/… ) and an event-script, but it's a bad idea. You could use an outboard script to detect link failure on your switch and push config changes to your MX204, but that's also a bad idea. All these things are fragile. That's why BFD was invented. Oct 5, 2020 at 18:23

Take a look at EEM, otherwise known as embedded event manager. You can configure an applet that takes a specific action (...including downing an interface) when a given even occurs (such as your upstream interface going down). There are examples in the link provided, but the basic idea is that you'll configure an interface tracking group that will watch the ISP and then execute a CLI to down the interface(s) facing your router. There will be a corresponding CLI to restore normal connectivity.

  • This also won't help him. He doesn't want the MX204 port to go down when the transit port goes down, because he needs that MX204 port to be carrying other traffic as well. Oct 6, 2020 at 16:07
  • Where does he ever say that? He wants to replicate the original behavior of 1:1 CPE:ISP links. If the ISP link fails, the MX knows it immediately because the link goes down. When you put a switch in the middle, the link between switch and ISP will drop, but the CPE will not know about it. Yes, BFD would be the best solution, but that requires the ISP(s) to play along - most won't. (I could personally set it up, but it's not something management would ever approve. As management, I wouldn't approve it either.)
    – Ricky
    Oct 6, 2020 at 18:16
  • Due to restrictions on the number of ports he writes, explaining why he's using the N9K. Oct 6, 2020 at 18:55
  • It also says: Is it possible to replicate the original behavior such that if a given interface on the N9K goes down I can automatically down other interfaces of my choice? - my answer does exactly that. If the upstream interface goes down, take down the corresponding downstream. I can’t comment on the wisdom of the overall design, of course, but the requirements are pretty specific.
    – rnxrx
    Oct 6, 2020 at 19:00
  • He doesn't say where that limitation is -- MX ports or ISP ports? In my case, it's the ISP that only gives me one link -- 'tho there's a $$$$ multiport switch NIM in their router. In order to attach more than one thing, it has to go through my switch. I don't need immediate detection, so SAA/RTR works for my needs. (I'm not dual homed, just dual ISP, so exiting connections are going to fail, but new connection can form through alternate link(s))
    – Ricky
    Oct 6, 2020 at 23:32

I assume you care about BGP state following that of interface. Since BFD can't be used you are out of options for sub-second liveliness detection, which brings you to BGP keepalives. Both platforms support 1 sec intervals (on Junos you'd configure hold-time of 3 which is 3x1sec), with 3x multiplier, you are down to 3 sec. Not necessarily a great idea, and might make BGP unstable (flapping) (on QFX it does), so test well.

  • I won't vote this down, but messing with BGP timers often just makes more of a mess. The defaults are what they are for a reason.
    – Ricky
    Oct 6, 2020 at 23:27

"Link State Tracking" is the feature you seek. I'm not sure it's supported on NX-OS, or that switch.

1. configure terminal
2. link state track [ number ]
3. interface [ interface-id ]
4. link state group [ number ] {upstream | downstream}
5. end

Configuring Link State Tracking (1)
Configuring Link State Tracking (2)

  • This won't work for the OP's intended application. Oct 5, 2020 at 21:34
  • And why not? OP appears to want to down an interface when another goes down. i.e. if interface X is down, make interface A go down as well. This can be configured in either direction -- CPE causes ISP interface to drop, or v.v. ISP interface causes CPE to drop. (BFD, LST, EEM, SAA/RTR... there's lots of ways to get there.)
    – Ricky
    Oct 6, 2020 at 4:12
  • Because he doesn't have a 1:1 relationship between N9K-to-MX204 ports and fan-out ports to transit or other parts of his network, any solution using link state tracking won't help him. He doesn't want the MX204 interface to go down when the transit goes down; that same MX204 interface would be carrying other traffic (perhaps VLANs to two transit providers.) Oct 6, 2020 at 16:06
  • "Transit providers" and "interfaces"... so it would appear OP is using a 1:1 relationship. And directly: if a given interface on the N9K goes down I can automatically down other interfaces of my choice? That's exactly what LST does... if one interface is down, take other interfaces down. (as long as they're all on the switch)
    – Ricky
    Oct 6, 2020 at 18:07
  • 1
    @JeffWheeler Well there are two things. My transit providers are getting greedy with their ports so I'm opting to ride both routers on a /29 for CE\PE (I get redundancy through other providers). Also in some cases I am legitimately running out of ports. So if transit X goes down I want to down transit X's port on R1\R2. IN other cases Transit Y may deliver me a bond of 10G links but I still give transit Y a 100G port on the 204. I'd like to down this if hte entire bundle drops. Oct 7, 2020 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.