Packetloss in Juniper SRX with gigether-options loopback enabled

juniperloopbackpacketlosssrx

I have run into an interesting problem with a Juniper SRX 240 box. The box is running BGP as a border router, and is announcing a /24. To ensure that the vlan with the network stayed "up" I set the gigether-options loopback option on one of the interfaces which is part of an ethernet-switching bridge. This forced the vlan up, just as I wanted, and ensured the box did not withdraw the announcement in BGP when all servers behind the box were removed.

Sadly, the same option seems to wreck havoc on the ARP tables in the SRX. It causes 5-30 seconds long bursts of packet loss (around 5% over long periods of time) and I get duplicate answers to ARP queries.

  1. Is this behavior documented somewhere?
  2. Is there a better way to keep the vlan up?

Best Answer

Is your goal to only keep the BGP announcement alive regardless of the interface status? On my Foundry devices I would create a static rule for the BGP network to null with a very high distance (so the interface route always took precedence). Juniper might support something similar (usually BGP just wants the route to exist in the table in some form).

I don't have a way to actually test this. But maybe something like:

set routing-options static route 5.5.5.0/24 retain discard preference 250

According to the docs there is a retain, discard, and preference arguments to static route. Assuming your subnet was 5.5.5.0/24, this might keep the route in the table, regardless of the routing protocol state, send all traffic to /dev/null, and give it a higher preference so that default BGP or static route distance should take precedence.

I have no way to test this though. Try at your own risk of course.

Related Topic