Feb
06

Guys,

I ran into a task in a lab to configure an ACL to allow BGP and the book has it configured like this:

Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4
Permit tcp host 150.1.5.5 host 150.1.4.4 eq bgp

Is there a reason why it is configured like that instead of ‘Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4 eq bgp’ ?

The only reason I could think of was to allow source/destination traffic from tcp 179 to a different port.

Ted

Hi Ted,

Your reasoning is correct; it is because BGP uses different source and destination ports other than 179 depending on who originates the session. BGP is essentially a standard TCP based protocol, which means that it is client and server based.

When a TCP client attempts to establish a connection to a TCP server it first sends a TCP SYN packet to the server with the destination port as the well known port. This first SYN essentially is a request to open a session. If the server permits the session it will respond with a TCP SYN ACK saying that it acknowledges the request to open the session, and that it also wants to open the session. In this SYN ACK response the server uses the well known port as the source port, and a randomly negotiated destination port. The last step of the three way handshake is the client responding to the server with a TCP ACK, which acknowledges the server’s response and completes the connection establishment.

Now from the perspective of BGP specifically the TCP clients and servers are routers. When the “client” router initiates the BGP session is sends a request to the server with a destination port of 179 and a random source port X. The server then responds with a source port of 179 and a destination port of X. Therefore all client to server traffic uses destination 179, while all server to client traffic uses source 179. We can also verify this from the debug output in IOS.

In the below topology R1 and R2 are directly connected BGP peers on an Ethernet segment with configurations as follows:

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router bgp 1
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.0.0.2 remote-as 1

R2:
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router bgp 1
 network 2.2.2.2 mask 255.255.255.255
 neighbor 10.0.0.1 remote-as 1

From the “debug ip packet detail” output we can see the initial TCP session establishment for BGP between these neighbors as follows:

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 44, rcvd 3
    TCP src=11000, dst=179, seq=3564860120, ack=0, win=16384 SYN

R2:
IP: tableid=0, s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), routed via RIB
IP: s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), len 44, rcvd 3
    TCP src=179, dst=11000, seq=1977460611, ack=3564860121, win=16384 ACK SYN

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 40, rcvd 3
    TCP src=11000, dst=179, seq=3564860121, ack=1977460612, win=16384 ACK

In the first code snippet we can see that R1 has received a TCP packet from R2. This packet was sourced from 10.0.0.2 (R2), destined to 10.0.0.1 (R1), has a TCP source port of 11000 (the random port), a destination TCP port of 179 (the well known port), and is a SYN packet (1st step of three way handshake).

Next R2 receives the response from R1 that is a TCP SYN ACK, but in this case we can see that the port numbers are swapped. R1, the TCP server, now uses TCP port 179 as the source port, and the randomly negotiated port 11000 as the destination.

Further debugging of the BGP flow between these neighbors will show R1 using destination 179 (as the TCP client) and R2 using source 179 (as the TCP server).

The implication of this operation is that if BGP needs to be matched for some reason, i.e. to filter it out in an access-list, to match it in a QoS policy, we must account for traffic that is both going to TCP port 179 and coming from TCP port 179.

About Brian McGahan, CCIE #8593, CCDE #2013::13:

Brian McGahan was one of the youngest engineers in the world to obtain the CCIE, having achieved his first CCIE in Routing & Switching at the age of 20 in 2002. Brian has been teaching and developing CCIE training courses for over 10 years, and has assisted thousands of engineers in obtaining their CCIE certification. When not teaching or developing new products Brian consults with large ISPs and enterprise customers in the midwest region of the United States.

Find all posts by Brian McGahan, CCIE #8593, CCDE #2013::13 | Visit Website


You can leave a response, or trackback from your own site.

18 Responses to “Understanding BGP Port Numbers”

 
  1. Vikas says:

    That explains why BGP uses different ports. Thanks.

  2. Naveen says:

    Thanks a lot.

  3. NTllect says:

    also, for the sake of completeness, we can influence the way three-way handshake works:

    http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp4.html#wp1043787

  4. JP Senior says:

    I was reading this blog post, and realized that it didn’t describe what would happen if two BGP peers tried to open a connection to each other at the same time.

    Basically, there is no mechanism that will define which BGP speaker will be either the client or server, as each speaker will try to connect to each other [by default], and the first one wins – in the event of a tie, there is a colission detection routine to declare a winner.

    RFC 1713 section 6.8 describes BGP collision detection with a three-step process, beginning by the router examining all of its OpenSent and OpenConfirm sessions and comparing the BGP identifier of each one.

    It seems they’ve thought of everything!

  5. Kelyluis says:

    Thank you for you sharing information. I also have anotherbest resource for people who want to search online internet-dictionary.
    Please check out this Tcp Ip Port Numbers Internet Dictionary
    Thank you for you sharing information.

  6. TI says:

    >> “I was reading this blog post, and realized that it didn’t describe what would happen if two BGP peers tried to open a connection to each other at the same time”

    Can anybody confirm me if a router has the higher BGP router-id will become the client?

    • http://www.ietf.org/rfc/rfc4271.txt

      6.8. BGP Connection Collision Detection

      If a pair of BGP speakers try to establish a BGP connection with each
      other simultaneously, then two parallel connections well be formed.
      If the source IP address used by one of these connections is the same
      as the destination IP address used by the other, and the destination
      IP address used by the first connection is the same as the source IP
      address used by the other, connection collision has occurred. In the
      event of connection collision, one of the connections MUST be closed.

      Based on the value of the BGP Identifier, a convention is established
      for detecting which BGP connection is to be preserved when a
      collision occurs. The convention is to compare the BGP Identifiers
      of the peers involved in the collision and to retain only the
      connection initiated by the BGP speaker with the higher-valued BGP
      Identifier.

  7. Gaurav says:

    Does the client/server negotiation depends on bgp router-id. If so how? I could not see router-id being exchanged during tcp handshake.
    Thanks

  8. @Gaurav

    This happens during the OPEN portion of the BGP state machine. For details check the section entitled “6.8. BGP Connection Collision Detection” in RFC 4271 “A Border Gateway Protocol 4 (BGP-4)” at http://www.rfc-editor.org/rfc/rfc4271.txt.

  9. Nazam Ansari says:

    Hii,
    I would like to know in case of eBGP peering why loopback address isn’t used instead of physical ip address of the interface. As loopback address is used in iBGP peering

  10. Jack says:

    Hi Brian,

    I did the lab again to determine who should be client (destination port 179). who should be server. Just find the one with smaller ip on the interface will be client. the other side is server.

    BGP router-id change may affect the process of negotiation. But after several tch reset session, the one with smaller ip will be client finally.

    It seems it is different from your result.

    The IOS version is 2600 Software (C2691-ADVIPSERVICESK9-M), Version 12.4(15)T5, RELEASE SOFTWARE (fc4).

  11. Jack says:

    Hi Brian,

    What is the RFC number, please?

    • RFC 4271 – A Border Gateway Protocol 4 (BGP-4)

      6.8.  BGP Connection Collision Detection
         If a pair of BGP speakers try to establish a BGP connection with each
         other simultaneously, then two parallel connections well be formed.
         If the source IP address used by one of these connections is the same
         as the destination IP address used by the other, and the destination
         IP address used by the first connection is the same as the source IP
         address used by the other, connection collision has occurred.  In the
         event of connection collision, one of the connections MUST be closed.
         Based on the value of the BGP Identifier, a convention is established
         for detecting which BGP connection is to be preserved when a
         collision occurs.  The convention is to compare the BGP Identifiers
         of the peers involved in the collision and to retain only the
         connection initiated by the BGP speaker with the higher-valued BGP
         Identifier.
         Upon receipt of an OPEN message, the local system MUST examine all of
         its connections that are in the OpenConfirm state.  A BGP speaker MAY
         also examine connections in an OpenSent state if it knows the BGP
         Identifier of the peer by means outside of the protocol.  If, among
         these connections, there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, and this
         connection collides with the connection over which the OPEN message
         is received, then the local system performs the following collision
         resolution procedure:
            1) The BGP Identifier of the local system is compared to the BGP
               Identifier of the remote system (as specified in the OPEN
               message).  Comparing BGP Identifiers is done by converting them
               to host byte order and treating them as 4-octet unsigned
               integers.
            2) If the value of the local BGP Identifier is less than the
               remote one, the local system closes the BGP connection that
               already exists (the one that is already in the OpenConfirm
               state), and accepts the BGP connection initiated by the remote
               system.
            3) Otherwise, the local system closes the newly created BGP
               connection (the one associated with the newly received OPEN
               message), and continues to use the existing one (the one that
               is already in the OpenConfirm state).
         Unless allowed via configuration, a connection collision with an
         existing BGP connection that is in the Established state causes
         closing of the newly created connection.
         Note that a connection collision cannot be detected with connections
         that are in Idle, Connect, or Active states.
         Closing the BGP connection (that results from the collision
         resolution procedure) is accomplished by sending the NOTIFICATION
         message with the Error Code Cease.

  12. Karthic says:

    I remember reading somewhere that there is another method for influencing who uses the BGP server port other than router-ids?

    Is there any?

 

Leave a Reply

Categories

CCIE Bloggers