Description

After the routing engine protect filter gets applied on the loopback interface, existing BGP session may go down due to hold time timeout.

The configuration of the filter looks similar to the one in the output below.

Some time after applying this filter to the loopback interface in input direction, one or more of the existing BGP sessions on the router might go down (or flap), due to event HoldTime.

 

USER@ROUTER> edit 
Apr 10 00:53:00
Entering configuration mode

[edit]

USER@ROUTER# show firewall family inet filter PROTECT-RE 
Apr 10 00:53:16
term SSH {
  from {
    protocol tcp;
    destination-port ssh;
  }
  then accept;
}
term BGP {
  from {
    protocol tcp;
    destination-port bgp;
  }
  then accept;
}
term ALL-ELSE {
  then {
    reject;
  }
}

[edit]

USER@ROUTER# set interfaces lo0.0 family inet filter input PROTECT-RE 
Apr 10 00:53:34

[edit]

USER@ROUTER# show | compare 
Apr 10 00:53:38
[edit interfaces lo0 unit 0 family inet]
+    filter {
+      input PROTECT-RE;
+    }

[edit]

USER@ROUTER# commit and-quit 
Apr 10 00:53:47
commit complete
Exiting configuration mode

USER@ROUTER> 

Apr 10 00:55:04 ROUTER rpd[19816]: BGP_IO_ERROR_CLOSE_SESSION: BGP peer 3.3.3.3 (Internal AS 65000): Error event Operation timed out(60) for I/O session - closing it (instance master)
Apr 10 00:55:04 ROUTER rpd[19816]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 3.3.3.3 (Internal AS 65000) changed state from Established to Idle (event HoldTime) (instance master)
Apr 10 00:55:04 ROUTER rpd[19816]: bgp_io_mgmt_cb:3032: NOTIFICATION sent to 3.3.3.3 (Internal AS 65000): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 3.3.3.3 (Internal AS 65000), socket buffer sndacc: 57 rcvacc: 0 , socket buffer sndccc: 57 rcvccc: 0 TCP state: 4, snd_una: 1799061200 snd_nxt: 1799061238 snd_wnd: 16384 rcv_nxt: 2852227072 rcv_adv: 2852243572, hold timer 90s, hold timer remain 0s, last sent 1s, TCP port (local 55663, remote 179)

Apr 10 00:55:10

USER@ROUTER> 

 

 

 

Solution

This occurs when the local BGP peer is not the server in the BGP session.

The incoming BGP packets do not have destination port 179, so they do not match the BGP term in the filter.

They get rejected by the last term ALL-ELSE.

 

This can be corrected by adding another term (before ALL-ELSE) that matches on "source-port bgp"

This modified filter might look like this:

 

USER@ROUTER# show firewall family inet filter PROTECT-RE 
Apr 10 01:07:21

term SSH {
  from {
    protocol tcp;
    destination-port ssh;
  }
  then accept;
}
term BGP {
  from {
    protocol tcp;
    destination-port bgp;
  }
  then accept;
}
term BGP-SOURCE {
  from {
    protocol tcp;
    source-port bgp;
  }
  then accept;
}
term ALL-ELSE {
  then {
    reject;
  }
}

 

Alternatively, these 2 BGP terms in the filter can be removed and replaced by a single term that matches on both source and destination port (this might not work on all platforms) 

Such as:

set firewall family inet filter PROTECT-RE term BGP from protocol tcp
set firewall family inet filter PROTECT-RE term BGP from port bgp
set firewall family inet filter PROTECT-RE term BGP then accept

 

 

Modification History

2024-04-10 : Article Created