Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?
share|improve this question
    
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
add comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.