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 622 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

444 New Members signed up the last 30 days!

satisfaction-guaranteed

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


Forum Replies

  1. Hello Rene,
    I have couple of questions regarding the timers used in BGP. Correct me if I am wrong. Bgp uses keepalive of 60 seconds and hold down timer of 180 seconds by default. So here the keepalive works like hello messages like in ospf and hold down timer works like dead timer in ospf. Am I correct? Let’s say Router A is peering with Router B by EBGP and router A is using keepalive of 60 seconds and hold down timer of 180 seconds whereas Router B is using keepalive of 100 seconds and hold down timer of 300 seconds. In this case, what would be the negotiated

    ... Continue reading in our forum

  2. The default keepalive and holddown timer are 60 and 180 seconds (3x the keepalive):

    R1#show ip bgp neighbors | include keepalive
      Last read 00:00:20, last write 00:00:50, hold time is 180, keepalive interval is 60 seconds
    

    So what happens when you change these? For example, R1 uses a lower keepalive and holddown timer while 192.168.12.2 (R2) uses the default:

    R1(config)#router bgp 1
    R1(config-router)#neighbor 192.168.12.2 timers 10 30 
    

    The end result will be:

    R1#show ip bgp neighbors | include keepalive
      Last read 00:00:08, last write 00:00:08, hold time is 
    ... Continue reading in our forum

  3. Hi Rene,

    Do you have any idea how to use ASR 9010 capture BGP update message?
    The situation is:
    In topology: R1–SW1–SW2–R2,
    R1 and R2 has established BGP neighbor, and R1 can receive updates from R2,
    BUT, R2 cannot receive updates from R1.
    So, I’m trying to capture packet on R2 to see if the updates from R1 have been dropped.
    FYI, SW1 and SW2 are Layer 2 switch and are transparent in logically.

  4. Hi Chris,

    I took another look, this comes from the RFC 1771.

    The fourth high-order bit (bit 3) of the Attribute Flags octet is the Extended Length bit. It defines whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1). Extended Length may be used only if the length of the attribute value is greater than 255 octets.

    The lower-order four bits of the Attribute Flags octet are unused. They must be zero (and must be ignored when received).

    The funny thing is, they removed the part about 255 octets from a later RFC (RFC 4271):

    The fou

    ... Continue reading in our forum

15 more replies! Ask a question or join the discussion by visiting our Community Forum