BGP open message receives a TCP RST

On this micro post, I would like to show one reason why a BGP open message receives a TCP RST. For this test, I set up a BGP neighborship between two peers: PeerA(10.82.1.9) and PeerB(10.82.1.10)

PeerA initiates the connection and look what happens in the packet capture.

According to the sequence, TCP seems to have established properly. 3WAY handshake is done and PeerA thinks it can send its capabilities in its OPEN message and it actually sends it but something weird happens. Remote side PeerB first closes the connection [FIN,ACK] and then sends a RST segment to our OPEN message but why does he do that?

The thing is that OPEN message is some sort of sync call towards the other peer. We try to understand what each peer supports and on this particular example, we sent e.g Graceful restart, Route Refresh capabilities etc. PeerB might not have liked them? If it did, then we should have received an application level error instead of a RST.

The real issue here is that PeerB’s BGP configuration is disabled 🙂

root@J29# show protocols bgp 
inactive: group ISPD {
    type external;
    import AS8500-IN;
    export AS8500-OUT;
    peer-as 600;
    neighbor 10.82.1.9;
}

BGP daemon is actually running because of which we established the 3 way handshake but application(BGP) has to understand by sending OPEN message to see if the other side is willing to co-operate and if we look at PeerA’s BGP state, we can see that it actively tries to establish BGP.

Peer: 10.82.1.10 AS 8500       Local: 10.82.1.9 AS 600  
  Type: External    State: Active         Flags:    <--State active
  Last State: Idle          Last Event: Start
  Last Error: None
  Export: [ ISPD ] 
  Options: 
  Holdtime: 90 Preference: 170
  Number of flaps: 0

In order to distinguish an application level error and transport level response, I enable BGP but put an incorrect AS number.

group ISPD {
    type external;
    import AS8500-IN;
    export AS8500-OUT;
    peer-as 1000;  <---This must be 600 instead
    neighbor 10.82.1.9;
}

and see how the packet capture looks like this time.

hmm, now it is a different one. Now initiator is PeerB(10.82.1.10). It sends in its OPEN message that its AS number is 8500 and PeerA sends its own AS number as 600 but we put in the configuration that we expect 1000 not 600. This is causing BGP to send the NOTIFICATION in which you see the message "Bad Peer AS"

and if we check the neighbor status on the side that sent the NOTIFICATION, we can clearly see the OPEN Message Error.

root@J29> show bgp neighbor
Peer: 10.82.1.9 AS 1000        Local: 10.82.1.10 AS 8500 
  Type: External    State: Active         Flags: <>
  Last State: Idle          Last Event: Start
  Last Error: Open Message Error
  Export: [ AS8500-OUT ] Import: [ AS8500-IN ]
  Options: 
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Error: 'Open Message Error' Sent: 3 Recv: 0  <---

From this, we can conclude that if we receive an OPEN response, we don't have a problem with the neighbor IP address but some BGP parameter.