0

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?
pehrs
  • 8,749
  • 29
  • 46
  • 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 Mackintosh Sep 26 '12 at 14:10
  • What version of JunOS? – SpacemanSpiff Sep 26 '12 at 20:26
  • @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. – pehrs Oct 18 '12 at 13:18
  • @SpacemanSpiff: JunOS 10.4R4.5 – pehrs Oct 18 '12 at 13:19

1 Answers1

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

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.

Andy Shinn
  • 4,131
  • 8
  • 38
  • 55