BGP Messages

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Nice summary , thanks

3

Rene,

Great lesson, how do I capture traffic in GNS3 to see these messages. Please let me know.

Thanks

Hamood

4

Hi Hamood,

GNS3 makes this really simple. You can right-click on any interface and select “capture”. It will automatically start Wireshark and show you the traffic that flows through the link.

Rene

5

Rene,

Thank you so much, your lessons with wireshark are very help full to read and understand these BGP messages.

Question,
Is there is a need to change hold time on the production network to optimize network performance.

Thanks
Hamood

Hamood

6

Hi Hamood,

You are welcome. I also like the wireshark captures, they help to visualize things.

Changing the hold time won’t matter much, it’s only used to check if the other BGP neighbor is “alive” or not. There are some other BGP timers that you can play with though to improve convergence speed.

Rene

7

Thank you Rene.

Can you list some useful in troubleshooting debug commands and is there any way to filter in with ACLs? For example, I like creating ACL for the desired traffic when utilizing debug ip packets.

Best,
MS/

8

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

9

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

10

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

11

Thanks Rene

12

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
13

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.

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!

14

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.

15

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

16

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.

17

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.

18

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!)?

19

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
20

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!