Junos OS

Hello,

 

I have an odd issue with BFD on a MX960, We have it enabled on iBGP sessions. BFD dropped between 2 BGP speaks for a single session and BGP re-established however BFD has stayed in an admin down state, This is the same for both ends.

 

I have tried to remove BFD and re-add it to the BGP session but that's not changed it from the admin down state.

 

Has anyone comes across this issue before?

 

 

show bfd session address 2001:xxx:x:xx2:: extensive    
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
2001:xxx:x:xx2::         Down                     0.000     1.000        3   
 Client BGP, TX interval 0.300, RX interval 0.300
 Local diagnostic None, remote diagnostic None
 Remote state AdminDown, version 1
 Replicated 
 Min async interval 0.300, min slow interval 1.000
 Adaptive async TX interval 0.300, RX interval 0.300
 Local min TX interval 1.000, minimum RX interval 0.300, multiplier 3
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 946, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh
 Multi-hop route table 0, local-address 2001:xxx:x:xx4::
  Session ID: 0x3e801

1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 0.0 pps

 

show protocols bgp group ibgp-ipv6-peers neighbor 2001:xxx:x:xx2:: 

bfd-liveness-detection {
    minimum-interval 300;
    multiplier 3;
}

 

 

Thanks

#BFD

Hi Epaphus:

 

Did you ever try to create another VR to bind this interface to test?

I occur same situation before, but mine is under protocol ospf and bfd status is down, too.

 

I create another VR routing-instance to test and the ospf and bfd is OK. It's not hardware issue.

Create case let JTAC analysis and engineer say it's a PR(PR879904)

 

Workaround need deactivate/activate routing-instances or re-name routing-instance name.

 

But I think your config is not under VR. it is not the same as I encounter situation. You can refer to the PR.

 

 

You are using iBGP, so we can assume multi-hop BFD from your output.

 

Is it hitting a firewall filter on lo0.0?

 

You need to allow UDP sourced from the loopback address on the A router to port 3785 on the B router and vice-versa.  Allow port 3784 if you are doing any single-hop BFD as well.

 

Hope this helps

Hi Ben,

 

It is allowed via the firewall, the sessions were working fine and we have others which are still working. It only seems to be a few of them which went down and stayed down.

 

We have BFD setup on all OSPF links and IBGP links.

 

Regards

Hi,

It looks like the router on which capture was taken is initiating BFD session, but other side has indicated the status as admin down. Can you please provide the same "show BFD session" output from other side router? BTW just wanted to highlight that udp-port 3784 is for single hop BFD packets while 4784 is for multi hop BFD packets. With micro-BFD, it uses udp-port 6784.

Regards
Surya

Hi Surya,

 

Both sides look the same.

 

> show bfd session address 2001:xxx:x:xx4:: extensive 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
2001:xxx:x:xx4::         Down                     0.000     1.000        3   
 Client BGP, TX interval 0.300, RX interval 0.300
 Local diagnostic None, remote diagnostic None
 Remote state AdminDown, version 1
 Replicated 
 Min async interval 0.300, min slow interval 1.000
 Adaptive async TX interval 0.300, RX interval 0.300
 Local min TX interval 1.000, minimum RX interval 0.300, multiplier 3
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 297, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh
 Multi-hop route table 0, local-address 2001:xxx:x:xx2::
  Session ID: 0x47761

1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 0.0 pps

 

> show bfd session address 2001:xxx:x:xx2:: extensive 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
2001:xxx:x:xx2::         Down                     0.000     1.000        3   
 Client BGP, TX interval 0.300, RX interval 0.300
 Local diagnostic None, remote diagnostic None
 Remote state AdminDown, version 1
 Replicated 
 Min async interval 0.300, min slow interval 1.000
 Adaptive async TX interval 0.300, RX interval 0.300
 Local min TX interval 1.000, minimum RX interval 0.300, multiplier 3
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 946, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh
 Multi-hop route table 0, local-address 2001:xxx:x:xx4::
  Session ID: 0x3e801

1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 0.0 pps

 

The firewall filter does allow both 3784 and 4784

 

term allowed-bfd-for-bgp-sources-ipv6 {
    from {
        source-prefix-list {
            ospf-ipv6-linknets;
        }
        next-header udp;
        destination-port [ 3784 4784 ];
    }
    then accept;
}

 

They did come up once had been up for a while before they went down and stayed down.

Hi,

 

Thanks. Since both sides are showing up as "Local state Down" and "Remote state AdminDown" it indicates that they are indeed initiating BFD packets but it is not making up to the other side. And since BGP session is up, I believe there is no issues in the forwarding path. Then it comes to point if outgoing BFD packets are allowed on these nodes. I am sure you already checked on the inbound filter, but would be possible to check the outbound filter as well?

 

In my lab, I was able get into this state by blocking multihop BFD packets using OUTBOUND filter.

 

Now only reasoning I could give for it being working earlier is that the outbound firewall filter could have been applied after BFD session was up and once BFD session is up, the process is delegated to FPC.

 

Regards

Surya

You'll need to allow both 3784 AND 3785 for BFD.

 

6784 is for BFD over LAGs, so you can probably leave that in there too.

 

Also, does your prefix-list ospf-ipv6-linknets include the loopback address?  Being that this is iBGP, your mh-bfd sessions may actually being sourced from the loopback address instead of the interface/linknet address.