Testing notes: simulating link failure by filtering BFD packets

28 12 2018

In some testing I am doing, I need to prove that BFD can be used with iBGP to tell the BGP protocol when there is an interruption.  This will enable BGP to be brought down much faster than if regular BGP timers are used.

To make this easier to do, I used a firewall filter on one of the two routers to filter out BFD but accept all other packets:
Single-hop BFD (i.e. across a link) uses UDP 3784, while multi-hop BFD uses 4784.  Since my BFD sessions are configured between loopbacks, it is this latter type I need to filter.

In the example below, CORE1 is a BGP client of CORE2, which is the route-reflector.

The following was configured on the routers to bring up the BFD session (I am only showing one side – you can figure out the mirror of this yourself I think):

[edit protocols bgp group CORE neighbor]
      bfd-liveness-detection {
          minimum-receive-interval 300;
          multiplier 3;
          transmit-interval {
              minimum-interval 100;

When the remote side was done, the session came up:

axians@CORE1> show bfd session
Dec 28 17:17:10
                               Detect Transmit
Address       State Interface  Time   Interval  Multiplier      Up              0.900     0.300        3

To bring down the BFD session, apply the following filter outbound on the core-facing interface(s):

axians@CORE1# show | compare rollback 2
Dec 28 17:23:33
[edit interfaces ae1 unit 0 family inet]
  filter {
    output BLOCK-BFD;
[edit firewall family inet]
  filter BLOCK-BFD {
    term T1 {
      from {
        protocol udp;
        port 4784;
      then {
    term T2 {
      then accept;

As soon as the filter is applied, BFD times-out and brings down the BGP session:

Dec 28 17:39:13 CORE2 bfdd[1935]: %DAEMON-4: BFD Session (IFL 0) state Up -> Down LD/RD(16/23) Up time:00:06:07 Local diag: CtlExpire Remote diag: None Reason: Detect Timer Expiry.

Dec 28 17:39:13 CORE2 bfdd[1935]: %DAEMON-4-BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 16, new state: down, peer addr:

Freeradius setup on Ubuntu 14.04

22 01 2016

Frustrated with a dilapidated installation of Freeradius 1.x in our lab, and conscious that it is unsupported any more, I decided to install a new Freeradius server.

Ubuntu 14.04.3 LTS is the platform I am installing it on, and this is a relatively fresh installation of Ubuntu server.   It needs to serve access-requests from a Redback and a Juniper router in our lab for both PPP and DHCP clients.

Read the rest of this entry »

Managing Junos Commit Time

17 09 2015

I’ve been working with an ISP that is going to be using a large amount of configuration in the ‘groups’ section.  The statements there will be inherited into the main configuration using the ‘apply-groups’ statement.

This is a clever way of writing commands once and having them apply to multiple parts of the configuration.  At a basic level you could match on interfaces beginning with ‘ge-‘ or ‘xe-‘ and set an MTU on them all using one group statement. This MTU setting would not appear in the main configuration unless the configuration was displayed using “show | display inheritance”. There’s a nice explanation of how groups work over at this Packetpushers blog.

The downside is that if large amounts of configuration work is done in groups, applying the config can become slow during the ‘commit’ process.   Read the rest of this entry »

First steps with Python and Junos

27 04 2015

I’m just spending the day trying to get my head around some very basic automation, so I thought I would install Python 2.7 and work through some of the tutorials on the Techwiki to see how I get on.

Read the rest of this entry »

MX with enhanced SCB2 – cards not coming online

25 03 2015

We just installed an MX in the lab for a customer type-approval test (TAT) and none of the cards came online.  Read the rest of this entry »

Remote port-mirroring in Junos

20 03 2015

Information on remote port mirroring on Junos routers doesn’t seem to be very easy to come by for some reason – there is quite a lot of information about doing this on EX switches (a bit like RSPAN in Cisco’s IOS), which wasn’t what I needed.  Various other sources of information (such as Cluepon) say this can be done using a GRE tunnel, but that the capturing device needs to be a server that terminates the GRE tunnel – which all seemed a bit complicated.

I needed to remotely mirror a port on an MX to a second MX where a windows-based Wireshark was connected, so getting GRE working to a Windows host sounded like a non starter.

So I had to work it out myself – and hopefully this write-up will prove useful to someone else in the future. Read the rest of this entry »

Node and Link Protection

6 11 2014

Node and link protection is a mechanism for protecting LSPs from (you guessed it) the failure of nodes and links.   It differs from fast re-route in that you have to specify node and link protection on the interfaces of all the downstream routers as well as on the LSP at its source.

My network looks like this at the moment, with an LSP running from R5 to R1 using the shortest path determined by the IGP:

Path of LSP R5-to-R1

Path of LSP R5-to-R1

Read the rest of this entry »