# Understanding the BGP Peering details your CCNA didn't teach you **URL:** \ **Category:** F5 Technical Articles\ **Tags:** big-ip, application-delivery, bgp, routing\ **Created:** [October 8, 2019, 2:16pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064 "2019-10-08T14:16:31Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [October 8, 2019, 2:16pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/1 "2019-10-08T14:16:31Z")
## 1 Quick Facts - BGP uses TCP port 179 and is path vector protocol, rather than distance vector or link-state - Keep-alive is 60s by default and Hold time is 180s - Only hold time is negotiated in Open message - Lowest hold time is used - Routes are only installed in the routing table and advertised to peer is deemed valid (\*) and best (\>) - For BGP to advertise a route using network command such route has to be in the routing table first - BGP transport and route advertisement (known as NLRI in BGP) are independent - Transport can use either IPv4 or IPv6 - IPv6 NLRI can be advertised over an IPv4 BGP connection and vice-versa ## 2. The BGP peering for IPv4 ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/6/6c0e6ef9c45c579e4645fde9c6f29543d8d944fd.png) BIG-IP establishes TCP connection on port 179 with peer and each one exchange  **OPEN Message** : ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/3/b/3be8b54adce7e8479fbd2eb4d0c3449520c90743.png) Here’s BIG-IP’s  **OPEN Message** : ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/f/f/ff2f9ee03858cf9efa08d7eb6d69f57f35fe82e9.png) Here’s Cisco’s  **OPEN Message:** ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/8/7/871c7ba6e120ba87f2e4ba9f28ff865323d2393e.png) **Marker**  is always the same value and is just to signal the beginning of BGP message so don’t worry about it. **Length**  is just the total length of this BGP message **Type**  could be UPDATE (2), KEEPALIVE (4) but in this case it is an OPEN Message (1). **Version**  is always the same as this is BGPv4. **My AS**  is the same because this is iBGP but if it was eBGP My AS on both sides would differ. **Hold Time**  picked value is the lowest one and this is negotiated. Since lowest value on BIG-IP’s side is 90 seconds then both peers will send KEEPALIVE messages at 30 seconds interval. **BGP Identifier**  is the bgp router-id that we typed in. **Optional Parameters Length**  is the total length combined of all BGP extensions **Optional Parameters**  are BGP extensions. At this point, if something goes wrong with peering, we should see BGP sending a NOTIFICATION message to terminate peering process: ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/7/0/708d60282c579723cdcc788676f3f29bd935b209.png) The above one was issued because I shutdown the neighbour relationship manually but [other types of error](https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-3) would reveal a different message. In a running packet capture, we should see **KEEPALIVE** messages and corresponding **TCP ACKs** at agreed interval based on **Hold Time** : ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/7/712d86873fa2dad8e867c11d2239386e9a876214.png) Other than that, UPDATE messages are also common and I will show them right now. ## 3. The UPDATE message for IPv4 It’s kind of built-in. For IPv4 we will see Type 2 message ( **UPDATE** ) and the NLRI ( **routes** ). The 2 prefixes below share the same attributes and this is why they’re grouped together: ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/d/e/de1750b62c7aebc28ebab7cab3ba9dbb65b54098.png) ## 4. The BGP peering for IPv6 It’s the same thing as IPv4 but an additional capability is negotiated called  **Multiprotocol extensions capability**  with  **IPv6**  as  **AFI**  value: ![image_281140.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/6/65cee98158292b3d07ae79ccfa5b0bf1ba347e84.jpeg) In case you never heard of AFI/SAFI here’s what they mean: - [AFI (Address Family Indicator)](https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml): This is the kind of route BGP is capable of handling, normally IPv4 or IPv6 but can also be VPNv4 for MP-BGP (out of scope here). - [SAFI (Subsequent Address Family Indicator)](https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml): This is whether route is UNICAST or MULTICAST, normally UNICAST. If you ever configured BGP and typed in address-family commands then you’ve touched AFI/SAFI already. ## 5. BONUS! Carrying IPv4 prefixes over an IPv6 BGP connection (WHAT?) Yes, it’s possible but next-hop of an IPv4 route is going to be IPv4 so make sure there is connectivity or create the relevant route-map. ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/d/dd156769f3c862abf07acd68ef660ab3885549e5.png) Notice that we’re transporting BGP packets over IPv6 but routes advertised are IPv4 prefixes: ![image_281140.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/f/f8916d3ecee9375011117d91bfdd73f29509cee1.png) You can also carry IPv6 prefixes over IPv4 if we do the other way round. ---
**Author:** ![shsingh](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/shsingh/32/9060_2.png) [@shsingh](https://community.f5.com/u/shsingh)\ **Post date:** [October 8, 2019, 9:37pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/2 "2019-10-08T21:37:21Z")
fantastic article! ---
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [October 9, 2019, 8:57am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/3 "2019-10-09T08:57:14Z")
Thank you 🙂 ---
**Author:** ![dragonflymr](https://avatars.discourse-cdn.com/v4/letter/d/90db22/32.png) [@dragonflymr](https://community.f5.com/u/dragonflymr)\ **Post date:** [October 9, 2019, 12:45pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/4 "2019-10-09T12:45:04Z")
Hi, Great article! Hope you will continue this topic. Will be great to have something about real life best practices for BGP config related to cluster. Another topic could be about BIG-IP redistributing routes from upstream do downstream routers. Piotr ---
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [October 9, 2019, 4:26pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/5 "2019-10-09T16:26:51Z")
Will take into consideration your suggestion, Piotr. Thank you! 🙂 ---
**Author:** ![Guilherme](https://avatars.discourse-cdn.com/v4/letter/g/77aa72/32.png) [@Guilherme](https://community.f5.com/u/Guilherme)\ **Post date:** [October 14, 2019, 6:16pm UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/6 "2019-10-14T18:16:57Z")
Very well explained, congratulations! ---
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [October 16, 2019, 11:57am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/7 "2019-10-16T11:57:03Z")
Thank you, Guilherme! ---
**Author:** ![dragonflymr](https://avatars.discourse-cdn.com/v4/letter/d/90db22/32.png) [@dragonflymr](https://community.f5.com/u/dragonflymr)\ **Post date:** [October 29, 2019, 11:00am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/8 "2019-10-29T11:00:30Z")
Hi Rodrigo, Slightly off topic but can you by chance advice about BGP/BFD configuration. As far as I know those protocols can be configured via imish and tmsh/iControl, but you have to choose one (no way to use both ways at the same time). What would be your advice for new config - go for tmsh/iControl or stay with imish? tmsh/iControl looks as more friendly and elastic (especially ability to use iControl) but maybe this way is less powerful that imish and not enough for more complicated configurations? Is that possible to manage BGP/BFD via tmsh/iControl and at the same time (for the same Route Domain) to manage other protocols using imish? Not sure after reading manual - it suggests that all protocols should be removed from RD config but maybe this is not a case? Piotr ---
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [November 6, 2019, 9:26am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/9 "2019-11-06T09:26:51Z")
Hi Piotr, As far as I know, tmsh is supposed to completely replace imish. If they left imi as read-only in later versions that’s likely because all the features are now available via tmsh. So, for new config, I’d stick to tmsh. You can even do automation with iControl and that’s much better than imish alone. Regarding your last question about using both tmsh and imish I never tried myself so I can’t answer it. I’d need to test it and see if it works. Cheers. Rodrigo ---
**Author:** ![dragonflymr](https://avatars.discourse-cdn.com/v4/letter/d/90db22/32.png) [@dragonflymr](https://community.f5.com/u/dragonflymr)\ **Post date:** [November 6, 2019, 9:33am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/10 "2019-11-06T09:33:38Z")
Hi, Thanks for info. Do you mean that there will be (or already is in v15) support for other protocols than BFD/BGP? Latest documentation about this topic I can find is for v14.1.2 - [BIG-IP Dynamic Routing with tmsh and iControl REST | BIG-IP Documentation](https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-dynamic-routing-with-tmsh-and-icontrol-rest-14-0-0.html). There seems to be no such manual (BIG-IP Dynamic Routing with tmsh and iControl REST) for v15 ☹ Piotr ---
**Author:** ![Rodrigo\_Albuque](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@Rodrigo\_Albuque](https://community.f5.com/u/Rodrigo_Albuque)\ **Post date:** [November 6, 2019, 10:34am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/11 "2019-11-06T10:34:09Z")
Hi Piotr I’m trying to get an authoritative response for you on that. Stay tuned. ---
**Author:** ![dragonflymr](https://avatars.discourse-cdn.com/v4/letter/d/90db22/32.png) [@dragonflymr](https://community.f5.com/u/dragonflymr)\ **Post date:** [November 6, 2019, 10:35am UTC](https://community.f5.com/t/understanding-the-bgp-peering-details-your-ccna-didnt-teach-you/66064/12 "2019-11-06T10:35:01Z")
Thanks a lot!!!