We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 529 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


265 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Notable Replies

  1. This information on how BGP neighbors establish adjacency is articulate and useful. Thank You!


  2. Hi Rene

    Thank you for great article. I had a question though.
    Why didn't R1 enter connect state and instead shifted to Active straight from idle? On the other hand i see R2 did enter connect state?


  3. Hi Jie,

    It's possible that the MTU is causing your issue. Your ISP might be sending BGP updates of 1500 bytes which are dropped on your end. Here's the default TCP segment size that is used for BGP:

    R1#show ip bgp neighbors | include segment
    Maximum output segment queue size: 50
    Datagrams (max data segment is 1460 bytes):

    The segment size is 1460 bytes, add a TCP header (20 bytes) and IP header (20 bytes) and you have a 1500 byte packet. In other words, you should be able to send/receive up to 1500 bytes which is not possible at the moment.

    There's two ways how you can fix this. BGP uses path MTU discovery which you can verify here:

    R1#show ip bgp neighbors | include tcp
      Transport(tcp) path-mtu-discovery is enabled

    So if we reduce the MTU, BGP should reduce its MSS:

    R1(config)#interface GigabitEthernet 0/1
    R1(config-if)#ip mtu 1400

    R1#clear ip bgp *

    Here's the new MSS:

    R1#show ip bgp neighbors | include segment
    Maximum output segment queue size: 50
    Datagrams (max data segment is 1360 bytes):

    You shouldn't have any issues now.

    The other way to solve this is by changing the TCP MSS manually. The command you used is for clients, not for the router itself. Here's an example if you want to learn more. Try this instead:

    R1(config)#interface GigabitEthernet 0/1
    R1(config-if)#no ip mtu 1400

    R1(config)#ip tcp mss 1450

    R1#clear ip bgp *

    R1#show ip bgp neighbors | include segment
    Maximum output segment queue size: 50
    Datagrams (max data segment is 1450 bytes):

    This should solve the problem.


  4. Hi Rene,

    In ebgp loop avoidance is done by as-path, if bgp sees it's own AS coming from a neighbor it will be ignored. And in Opensent stage: This is also the moment where BGP decides whether we use EBGP or IBGP (since we check the AS number). How is this different from ebgp loop avoidance, bgp will see its own AS and considers it as IBGP but not ebgp loop avoidance ? Please clarify. Thank you!

  5. please disregard my last question. I ran a wireshark capture and it seems the router-id determination only comes into play when thereis a "collision" when both sessions try to initiate the bgp session at the same time. Otherwise no matter what the router id is it appears the first bgp keeaplive that makes it to the other side is the one that is listed as the initiator/the router with the "random" source port and the remote router will show the port of 179.

    Thank you.


Continue the discussion forum.networklessons.com

4 more replies