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.
  • [geot exclude_region="No Trial" ] Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career![/geot]
  • Full Access to our 541 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


303 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. Hei Rene,
    Thanks for the lesson, in my working experience, i am stuck in a situation for 2 sites. i have the ebgp peering up, but i am receiving 0 prefix from my isp. The isp said when they show ip bgp nei adverticed route that are hundreds of routes advertised, they can receive our route. Any good debug command to troule should this? We have plain bgp config, the same config (different peering ip though) is working with other sites.

    One interesting thing is that when i ping the isp with mtu 1500 it does not work, but it works with 1496. After reading cisco doc, there was a solution which is changing the ip tcp adjuest-mss to 1000 it helps with one location but the other one still has no luck.

  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. andrew says:

    The neighbor relationship defines whether the neighbor is considered external or internal. If you form a neighbor relationship with a BGP router that has the same ASN as you, then it is internal. Since a neighbor relationship must be established before NLRI is exchanged, there is no conflict, since an iBGP neighbor is not subjected to the eBGP loop avoidance techniques you mention.

  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