Symptoms It's been a long standing ask for XR to support conditional route advertisements in BGP. The expected option of using the             if rib-has-route option in RPL currently can only be used at the default-information originate attachpoint to conditionally advertise a default route out.   The actual request is documented under  CSCue04899     Allow 'rib-has-route' for outbound rpl there are some reasonable technical limitations as to why it has not happened yet, but there is a neat workaround that I would like to share that provides the exact same behavior! Components involved The logic of the workaround solution is as follows: In BGP one defines a network statement for the route that needs to be conditionally advertised. (One could possible instead of a network statement also use redistribute static with a route-policy using a  prefix-set) This network statement's prefix is defined as a static route under router static The static route references the outgoing interface Null0 and a object track definition The object track definition references something that you want to track.   The tracking options include:   bfdrtr         track type bfd rtr   line-protocol   track type line-protocol; the line protocol of an interface, this interface can be l2transport or an l3 interface of any kind   list           track type list; this allows you to track other track definitions in an  AND or OR manner   route           track type ipv4 route ; the presence of a route   rtr             track type ipsla; an IPSLA probe to verify an end to end connectivity or port or anything that IPSLA can monitor! Detailed Solution This example talks you through a solution of using the BGP network statement, a conditional static route and the dependency  on an interface line state   Config pieces: Static route that is conditional with a tracker called MYIF router static address-family ipv4 unicast   192.168.123.0/24 Null0 track MYIF   Tracker MYIF that checks a lineprotocol state: track MYIF type line-protocol state   interface TenGigE0/2/0/3   BGP configuration that advertises a prefix (that is now conditional) router bgp 64524 address-family ipv4 unicast   network 192.168.123.0/24   Sample operation: Tracking interface is DOWN: LC/0/2/CPU0:Jun 12 09:41:33 : ifmgr[210]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/2/0/3, changed state to Down  LC/0/2/CPU0:Jun 12 09:41:33 : ifmgr[210]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface TenGigE0/2/0/3, changed state to Dn    Verify the static route is not there:   RP/0/RSP0/CPU0:A9K-BNG(config-if)#do sh route static | i 192.168.123 Wed Jun 12 09:41:18.977 EDT RP/0/RSP0/CPU0:A9K-BNG(config-if)#   Now bring up the interface, in this case it is not connected so i force it up with a loopback RP/0/RSP0/CPU0:A9K-BNG(config-if)#loop int RP/0/RSP0/CPU0:A9K-BNG(config-if)#commit Wed Jun 12 09:41:33.044 EDT LC/0/2/CPU0:Jun 12 09:41:33 : ifmgr[210]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/2/0/3, changed state to Up  LC/0/2/CPU0:Jun 12 09:41:33 : ifmgr[210]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface TenGigE0/2/0/3, changed state to Up    Notice the tracker detects it and ups the object! RP/0/RSP0/CPU0:Jun 12 09:41:33 : object_tracking[359]: %SERVICES-OT-6-TRACK_INFO : track MYIF state Track_Up    Verify the static route again: RP/0/RSP0/CPU0:A9K-BNG(config-if)#do sh route static | i 192.168.123 Wed Jun 12 09:41:58.463 EDT S    192.168.123.0/24 is directly connected, 00:00:24, Null0   Interface that is tracked configuration. Note that you can also track l2transport interfaces!! interface TenGigE0/2/0/3  description InternalLoop-trackertest   loopback internal  l2transport  !   cheers! xander     =====  Xander Thuijs, CCIE #6775 Distinguished Engineer ASR9000/NCS5500/IOS-XR       ... View more

hey all, a recent publication from cisco PSIRT went out regarding a vulnerability in the ASR9000 that was taken over by various news sites. since our team was directly involved with the detection of this item I wanted to share a few more details as I feel that the announcements and publications make it seem more severe then it really needs to be.   the issue surrounds the ability to crash the management plane through the secondary mgmt interface of the asr9000. The asr9000 RSP has 2 mgmt interfaces, 0 and 1. in classic XR they are both bound to the XR control plane. in evolved XR (64 bit) port 0 is bound to the XR control plane, the second interface "1" is bound to the admin plane.   It is very important to call out that this situation is confined to 64bit eXR only for the ASR9000, it doesnt apply to classic 32bit XR nor any other platform for that matter. Also it is not very common to have the secondary mgmt ethernet configured or in use. In addition to that, if it is configured and in use, it is not likely to be exposed to the internet. Finally the mgmt interfaces are not routed, that is, fabric doesnt have access to these interfaces, nor do the mgmt interfaces have an ability to inject packets into the fabric.   I just wanted to give a bit more context to the item described and published that yes we do acknowledge it is an issue, but realistically the exposure to it is limited based on the criterias mentioned above.   hopefully it helps putting some context around the "scare" that may have been raised!! reach out if you need more clarification!   cheers!! xander         ---- Xander Thuijs CCIE6775 Distinguished Engineer Cisco SP Routing ... View more