BGP Messages

Hi Marty,

Most debug commands are protocol-specific, if you want to debug BGP…just browse through all the different debug ip bgp ? options. There’s too many to list them all, BGP has over 20 main debug commands with some sub-options.

Most debug commands don’t support access-lists but if they do, it’ll show up:

R1#debug ip bgp updates ?
  <1-199>      Access list
  <1300-2699>  Access list (expanded range)
  A.B.C.D      BGP neighbor address
  events       Update events
  in           Inbound updates
  out          Outbound updates
  <cr>

Rene

Rene,

In the capture which you gave for EBGP adjacency have seen two update messages , can you explain when will we have to BGP UPDATE messages.

Thanks,
Dhanu

Hi Dhanu,

The second update message is empty and is used to indicate that all routes have been sent. You can read more about it in RFC4724:

An UPDATE message with no reachable Network Layer Reachability Information (NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can be used by a BGP speaker to indicate to its peer the completion of the initial routing update after the session is established.

Rene

Thanks Rene

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 keepalive and hold down timer that both routers will use? My second question. Let’s say Router A is peering with Router B by EBGP and and Route-maps are in place for filtering in both routers. In this scenario, if I make any change in the outbound route-map assigned to Router A and do not run clear ip bgp * soft, how long is it going to take Router B to get the update? How long does it take a router to get the update when any route goes down in the neighboring AS router? Thank you in advance.

1 Like

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 30, keepalive interval is 10 seconds
  Configured hold time is 30, keepalive interval is 10 seconds

And R2:

R2#show ip bgp neighbors | include keepalive
  Last read 00:00:05, last write 00:00:06, hold time is 30, keepalive interval is 10 seconds

BGP will use the lowest timer values.

How long it takes before an update is sent depends if you are running eBGP or iBGP and doesn’t have anything to do with the keepalive and holddown timer, those are only for the neighbor adjacency. For eBGP, an update is sent every 30 seconds which you can see in the show ip bgp neighbors command:

R1#show ip bgp neighbors | include advertisement
  Default minimum time between advertisement runs is 30 seconds

When you run iBGP, it is instant as you can see here:

R1#show ip bgp neighbors | include advertisement
  Default minimum time between advertisement runs is 0 seconds

Hope this helps!

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.

Hello Wenpeng,

You can use either SPAN on the switches or embedded packet capture on the routers.

You can also do a debug ip packet in combination with an access-list that matches BGP traffic between these two peers. If you see anything arriving at the router, try some debug bgp commands to see if it tells you why it is ignoring/dropping these packets.

Rene

Thanks Rene. I was trying to use NP tool on IOS-XR to capture the packet. And tried debug after read your advice (because I thought debug is used to analysis error, but not used to capture packet). Looks like debug is good enough to see what router received from BGP neighbor.

Glad to hear it was useful. Debug is usually good enough to troubleshoot things like neighbor adjacencies since it shows the packets but also what the router is doing or why it’s dropping a packet / refusing a neighbor adjacency.

I struggle to understand the second sentence when talking about the Extended Length flag.

Extended Length: when the attribute length is 1 octet it is set to 0, for 2 octets it is set to 1. This extended length flag may only be used if the length of the attribute value is greater than 255 octets.

When would the length of the extended value be greater than 255 octets (2040 bits!)?

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 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).

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

255 octets/bytes is a lot it might be possible. Take a look at this screenshot:

The attribute length is 25 bytes in that screenshot. Maybe if you go grazy with AS path prepending you can go above 255 bytes :grin:

1 Like

Thanks Rene!

What really is the difference been “attribute length” and “length of attribute value” though?

The RFC implies “attribute length” can only be 1 or 2 octets long, but “length of attribute value” can apparently be up to 255 octets!

Hi Chris,

Length of attribute value is the total path attribute length. It’s the sum of all attributes for a single NLRI. In the screenshot above, it’s 25 bytes.

The attribute length is where we store this value (and we can use 2 octets for that).

Rene

Hi Reene
Why Do we need keepalive then if update messages are sent every 30 seconds, we can use update for keepalive.

Samit

Hello Samit

It is true that for eBGP, the update timer is set to 30 by default and the keepalive is set to 60 seconds by default. It would be possible to have BGP reset the holddown timer every time an update was received as well, because if an update is received, then the neighbour must be up and running, right?

BGP has been designed so that the update and keepalives are two separate mechanisms. This is because you may want to adjust the keepalives to 15 seconds, the holddown to 45 and the updates to 60. If only the updates functioned as keepalives, you wouldn’t be able to do that. Keeping them separate gives you more control over the timers and how BGP will function.

BGP however is smart enough to send keepalives and holddown messages together within the same packet if they happen to be sent at the same time. This saves on bandwidth and resources in general.

I hope this has been helpful!

Laz

Rene, can you tell us what filter you used to capture this data in Wireshark? I tried just bgp but couldn’t see anything. I’m trying to capture on a serial link. I see you’re using Ethernet.

Thanks,

Andy

Hi Andy,

I probably just used the “bgp” filter in Wireshark to grab all BGP traffic. I usually just do a right mouse click on whatever I need, then update the filter later:

In this case, I change the filter from “bgp.type ==3” to “bgp.type” so that I get everything.

Rene

Hi René and staff,
perhaps, i missed something, and i am new in BGP
but basically i want to be sure which NLRI are advertised from one peer to another: do a peer advertise all the valid paths it knows () OR do a peer advertise only his best paths (>) to the other peer. If only the best path is advertised may we consider that BGP look like a distance vector IGP ? (with extra feature to select the best path, and filtering paths)
I read your lesson to find the answer but i don’t find it, perhaps i missed something (?)
Thank you, regards

Hello Dominique

BGP by default will always advertise the single best path, for a particular destination, to its neighbours. There is a way to change this behaviour, and this is further discussed in the following lesson:

A distance vector routing protocol determines the best path based on distance where distance is usually measured by the number of routers to be traversed (e.g. RIP), or by another metric that involves additional parameters (e.g. EIGRP). BGP on the other hand is a path vector protocol which maintains the path information to the destination as well, including all of the autonomous systems that have to be traversed to get there. Apart from all of the additional parameters that can be configured on BGP, it will find the shortest path based on the number of ASs it must traverse to get to a destination.

BGP and IGPs are the same only in the fact that the best path is chosen and placed in the routing table. The way it is measured in each case differs substantially.

I hope this has been helpful!

Laz