View Only
last person joined: yesterday 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Static Route with Two Next-Hops (Same Address)

    Posted 07-25-2023 19:33

    hi all,

    I'm trying to work out a way to set a route that will failover based on the same next-hop, and fail back. I may be over thinking it, but wanted to see if anyone was interested or curious about the same concept?

    Topology is a SRX, with an EX beneath. Two circuits connect in to the EX on independant VLANs are trunked to the SRX on different interfaces.

    EX ge-0/0/1_vlan1 > SRX reth0.1

    EX ge-0/0/2_vlan2 > SRX reth0.2

    Both circuits are VDSL, so basic from a carrier perspective. I have no control over their IP schema. They're just expecting something to plug in and DHCP for each circuit, we're statically assigning.



    Carrier devices are both within each VLAN.

    I see this creates an ARP problem, although it should be able to ARP within each VLAN? The second one (reth0.2) seems to lose its ARP and not be reachable.

    I have a static route pointing to

    set routing-options static route 0/0 next-hop

    Now, I worry about the following:
    1. reth0.2 doesn't ARP, will it failover clean?

    2. Being on the SRX the interfaces will always be up, so the route will always be valid

    3. If it does failover will it fail back? Will it get stuck on reth0.2 when failing over from current circuit reth0.1?

    4. Is this actually what will work? It just will mean whichever is active is luck, but it'll route as long as the device can find a path to either of the via reth0.1 or reth0.2? ... My educated guess says this is a nightmare waiting to happen in production.

    I've looked at qualified next-hop but can't quite find the right way to set a preference on reth0.2 of something higher even when using a tiebreaker of mac or interface. Interface routes used to exist on SSG but on SRX, which makes some sense, they're quite tricky to set under these terms.

    Any thoughts?


  • 2.  RE: Static Route with Two Next-Hops (Same Address)

    Posted 07-26-2023 06:15

    here my thoughts

    1.It will not fail-over cleanly,SRX will continue to try to ping the next hop but  ping will fail.

    2.Being on the SRX the interfaces will always be up, that does not mean that the route will always be valid.

    3.If reth0.2 goes down, the SRX will fail-over to reth0.1. If reth0.1 is also down, the SRX will not be able to fail back to reth0.2. Because, route to will still be marked as unreachable.
    4. Its possible, SRX will route traffic through whichever interface is active. And ur thoughts also right , because  there is no guarantee that traffic will always be routed through the most reliable path.

    Md.Kamruzzaman Khan
    Sr .Core Engineer at Planning and Implementation

  • 3.  RE: Static Route with Two Next-Hops (Same Address)

    Posted 07-26-2023 15:14
    Edited by Jodi Meier 08-03-2023 10:24


    It seems like you find yourself in a challenging situation. Just to clarify, I'm not an expert in these devices, but from a networking perspective, the current setup may not provide full control over outgoing packets.

    Based on the information provided, it appears that the packets will go out from the interface where there is an ARP record for Let's consider a scenario where provider 1 is currently active, and if you were to renew your IP address from provider 2, incoming packets from provider 2 would have a source IP address of but a different MAC address compared to the current one in your ARP table. Consequently, the MAC address would be updated, and outgoing traffic would start to be forwarded to provider 2.

    One potential approach to consider is segregating the providers into two different routing tables while keeping the LAN in the default routing table. By doing so, you can utilize IP monitoring to apply groups based on the monitoring results and modify the default routes next hop to be to a different routing table. This way, you can achieve better control over the routing of outgoing traffic.