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.

A) Why not just plug the network that you are announcing into the interface, forcing the VLAN up? B) Why would you want to keep announcing a network if it wasn't reachable?
–
David MackintoshSep 26 '12 at 14:10

@David Mackintosh: I deployed the router without any other HW on site, and the HW needs to be maintained now and then. I do not wish BGP to withdraw the route during maintenance windows if I can avoid it, as I have had problems with route-dampening causing outages before.
–
pehrsOct 18 '12 at 13:18

1 Answer
1

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).

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.