Junos OS

Hello everybody,

I hope you are safe wherever you are.

I am configuring BFD over rsvp-based LSP but it is not coming up, I have spent a lot of time checking, can anybody spot where the problem is?

Here is the configuration:

pe1:

path te_tunnel_path1 {
    172.17.30.129;
    172.17.50.201;
    17.39.53.50;
    172.17.50.237;
label-switched-path te_tunnel {
    no-install-to-address;
    to 17.39.53.20;
    install 172.28.173.35/32;
    primary te_tunnel_path1 {
        oam {
            bfd-liveness-detection {
                minimum-interval 100;
                minimum-receive-interval 120;
                multiplier 3;
                failure-action teardown;
            }
        }
    }
    secondary te_tunnel_path2 {
        standby;


pe2:

label-switched-path te_tunnel_path1 {
    no-install-to-address;
    to 17.39.53.5;
    install 172.28.173.220/32;
    primary te_tunnel_path1;
    secondary te_tunnel_path2 {
        standby;
    }
}
path te_tunnel_path1 {
    172.17.50.238;
    172.17.51.109;
    172.17.50.202;
    172.17.30.130;
}
path te_tunnel_path2 {
    17.39.53.5 loose;
}

BFD sessions status at both sides:

                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
127.0.0.1                Down      ge-0/1/0.1   0.000     1.000        0
 Client RSVP-OAM, TX interval 0.000, RX interval 0.000
 Local diagnostic None, remote diagnostic None
 Remote not heard, doesn't hear us, version 0
 Replicated 
 Min async interval 0.000, min slow interval 1.000
 Adaptive async TX interval 0.000, RX interval 0.000
 Local min TX interval 1.000, minimum RX interval 0.000, multiplier 0
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 114, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh, update-adj
 LSP-Name te_tunnel1
 Path-Name te_tunnel_path1
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
127.0.0.1                Down      ge-1/1/0.1   0.000     1.000        3
 Client RSVP-OAM, TX interval 0.100, RX interval 0.120
 Local diagnostic None, remote diagnostic None
 Remote state AdminDown, version 1
 Replicated 
 Min async interval 0.100, min slow interval 1.000
 Adaptive async TX interval 0.100, RX interval 0.120
 Local min TX interval 1.000, minimum RX interval 0.120, multiplier 3
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 13, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh, update-adj
 LSP-Name te_tunnel1
 Path-Name te_tunnel_path1

Hello,

Have You allowed UDP port 3784 in Your loopback filter?

https://tools.ietf.org/html/rfc5884#section-7

HTH

Thx

Alex

Hello,

Ok, in this case You might need to assign 127.0.0.1/32 to Your lo0.0, please try it.

Some JUNOS versions do not require it but some do.

Alternatively, You can use "receive" route:

set routing-options static route 127.0.0.1/32 receive

HTH

Thx

Alex

Thank you Alex, I did both -secondary IP address on lo0.0 and receive route- and none of them is working, I can't even see BFD packets coming out of the interface when I do "monitor traffic", however the log shows the bfd session bouncing, going up and down in the same second:

Apr  2 09:39:16  pe1 bfdd[1362]: BFD Session 127.0.0.1 (IFL 348) state Up -> Down LD/RD(218/217) Up time:00:00:03 Local diag: AdminDown Remote diag: None Reason: Received Upstream Destroy Session.
Apr  2 09:39:16  pe1 bfdd[1362]: BFDD_TRAP_STATE_DOWN: local discriminator: 218, new state: down

I feel that it's simple, something is blocking the BFD local on the router, any more ideas?

BR,

MP

Worth mentioning that one of the two router is an m10i runninig JUNOS 10.3R1.9, I though that this might be legacy so it deserve an upgrade, any recommndations?

If finally worked after allowing the LSP ping port number 3503, quoting from RFC 5884 "BFD for MPLS label switched paths": 

   If there are multiple alternate paths from an ingress LSR to an
   egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to
   determine each of these alternate paths.  A BFD session SHOULD be
   established for each alternate path that is discovered.

   Periodic LSP Ping Echo request messages SHOULD be sent by the ingress
   LSR to the egress LSR along the same data path as the LSP.  This is
   to periodically verify the control plane against the data plane by
   ensuring that the LSP is mapped to the same FEC, at the egress, as
   the ingress.  The rate of generation of these LSP Ping Echo request
   messages SHOULD be significantly less than the rate of generation of
   the BFD Control packets.  An implementation MAY provide configuration
   options to control the rate of generation of the periodic LSP Ping
   Echo request messages.

this document shows the LSP ping port number that was allowed on the loopback filter: https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-pinging-lsps.html

term lsp_ping {
    from {
        protocol udp;
        port 3503;
    }
    then accept;

the session then worked.

Thanks Alex for your time and help.

MP