Junos OS

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about Junos OS.
  • 1.  QFX Qualified next hop behaviour

    Posted 05-24-2021 04:33

    Hi,

    I made an attempt to introduce a failover link in lab last week. We wanted to keep it simple and just use static routes (no bfd or tracking if not needed?).

    Configuration used:

    set routing-instances TRANSIT routing-options static route 192.168.52.0/22 next-hop 10.0.0.9
    set routing-instances TRANSIT routing-options static route 10.0.0.72/29 next-hop 10.0.0.9   
    set routing-instances TRANSIT routing-options static route 10.11.128.0/17 next-hop 10.0.0.9 
    
    set routing-instances TRANSIT routing-options static route 192.168.52.0/22 qualified-next-hop 10.0.0.17 preference 50
    set routing-instances TRANSIT routing-options static route 10.0.0.72/29 qualified-next-hop 10.0.0.17 preference 50
    set routing-instances TRANSIT routing-options static route 10.11.128.0/17 qualified-next-hop 10.0.0.17 preference 50
    
    
    
    TRANSIT.inet.0: 30 destinations, 33 routes (30 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    192.168.52.0/22    *[Static/5] 00:38:16
                        >  to 10.0.0.9 via irb.3001
                        [Static/50] 00:38:16
                        >  to 10.0.0.17 via irb.3002


    Both routes gets inserted into the routing table and both next hops are ping:able within the routing instance, all good so far.

    What is the requirement/trigger for the static route with distance 5 to be removed from the table? My assumption was that if the next hop became unresponsive this route would be removed automatically. However when we remove an intermediate link (not the cable connected to this router) the route stays even if it's not useable anymore. Am I wrong here? Does irb.3001 also need to go down before the primary static route is removed?



  • 2.  RE: QFX Qualified next hop behaviour

    Posted 05-24-2021 05:28
    For the route to remove the subnet where the next hop exists must be no longer available, the link to the router itself would need to go down.

    To have failover with the link still up you need some kind of probe mechanism like RPM enabled.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------



  • 3.  RE: QFX Qualified next hop behaviour

    Posted 05-24-2021 06:48
    Thanks,
    I really don't like the complexity of rpm and that it actually changes the config commands of the device.

    I will try to get bfd running toward a Palo Alto NGFW to start off with... plan b is probably dynamic routing and c RPM.


  • 4.  RE: QFX Qualified next hop behaviour

    Posted 05-25-2021 06:34
    I agree that dynamic routing with BFD is the simple solution here.

    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
    http://puluka.com/home
    ------------------------------