Loading ...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 bgpIs 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.
[...] Full article here [...]
That explains why BGP uses different ports. Thanks.
Thanks a lot.
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
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!
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.
>> “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.
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
@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.
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