BGP Messages

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

Hi Laz ,

Lets say R1-R2-R3 is forming Ibgp neighborship & running fine.

one day someone change the interface MTU value of R2 towards R3 , will the neighborship between R1 to R3 Impact ?

Thanks

Hello Tanmoy

If the MTU of this interface changes, then the exchange of BGP messages between R1 and R3 will be affected in the same way as any data traffic would be affected between these two routers. If the exchanged messages have a larger IP MTU than that of the interface MTU, communication will fail. However, in order to ensure that such changes will not affect a BGP peering, best practice dictates to use BGP Per Session Path MTU Discovery (PMTUD). You can enable this feature on a Cisco device following the instructions in this Cisco documentation.

I hope this has been helpful!

Laz

Hi Laz,

I was doing a capture of an eBGP session between two routers, and I don’t see any Update messages being exchanged… Only Keepalives. Shouldn’t Update messages be sent every 30 seconds?

image

Thanks,
LP

How accurate is this statement
“The marker field on top is used to indicate if we use MD5 authentication or not. When it’s filled with 1’s then we are not using authentication.”

When I wireshark between two routers and remove the “neighbor passowrd <##>” I do not have the marker field change from all ‘f’ to all ‘1’. There is an option under the TCP packets which is removed when the password/MD5 is removed. However my Marker field does not change. Was anyone else able to have the marker field change?

Hello Luis

Thank you for this question, it identifies what I missed in my previous post. I didn’t make clear that the UPDATE messages are not sent every 30 seconds by default. They are only sent when the neighbor peering is established, and when there are changes in the network topology. Notice what the output of your command states:

Default minimum time between advertisement runs is 30 seconds.

This timer, which defines when UPDATE messages should be sent, defines the minimum time not the maximum time. Therefore, you may have hours or even days pass without an UPDATE. But the keepalives must be sent periodically. This is why you only see keepalives and not updates.

The minimum is defined in order to avoid instability in the BGP routing topology in the event that there are flapping routes. A flapping route is one that continually changes over a small amount of time (on the order of several seconds). This usually happens due to bad network design, or incorrect redistribution of routes between routing protocols. This would cause BGP to continue to attempt to reconverge, sending UPDATE messages continually, and thus causing network instability and ultimately network failure. This is especially important for eBGP, and that is why the default is 30 seconds for eBGP, but there is no such minimum set for the default of iBGP, which has a minimum UPDATE timer of 0 seconds.

Remember also that whenever an UPDATE is sent, this acts as a keepalive as well, so for that particular cycle, no additional keepalive need be sent.

I hope this has been helpful!

Laz

1 Like

Hello Ale

Rene states that this field is filled with all 1’s. Note however, that in the wireshark capture, the value of the marker is in hex. Since the field is 16 octets (128 bits) in length, if it is all 1’s then this can be represented in hex by 32 f’s. So a value of ffffffffffffffffffffffffffffffff seen in wireshark is indeed a marker field of “all 1’s”.

Indeed, according to RFC4271 the marker field MUST be set to all ones, and the use of the marker field for authentication has been deprecated. Even so, this field is kept there for compatibility reasons.

So, to answer your question, the behaviour that you saw in your configuration is normal. The marker field will always be composed of 128 ones in binary, or 32 f’s in hex.

I hope this has been helpful!

Laz

Hi Laz,

1)please define the attributes and differentiate thoroughly like what are the main attributes and what attributes come under these and so on…

2)second thing in wire shark what is the withdrawn route length unit ? please explore this like how many value can come under this?

Hello Pradyumna

The attributes included within the update message are the well-known BGP attributes used in the path selection algorithm. More about these can be found in the following lesson:


Rene further describes the information made available in the update message for each individual BGP attribute. If you want to see more detail about what information is included within the update message, and its structure, you can see this in section 4.3 Update Message Format of RFC 4271 where BGP is described.

According to the RFC mentioned above, the Update message has the following fields:

  +-----------------------------------------------------+
  |   Withdrawn Routes Length (2 octets)                |
  +-----------------------------------------------------+
  |   Withdrawn Routes (variable)                       |
  +-----------------------------------------------------+
  |   Total Path Attribute Length (2 octets)            |
  +-----------------------------------------------------+
  |   Path Attributes (variable)                        |
  +-----------------------------------------------------+
  |   Network Layer Reachability Information (variable) |
  +-----------------------------------------------------+

Note that the first field is the Withdrawn Routes Length field is a fixed size field of 2 octets, while the second, the Withdrawn Routes field, has a variable length. The Withdrawn Routes Length field contains an integer that indicates the total length of the Withdrawn Routes field in octets.

I hope this has been helpful!

Laz