Sunday, 23 December 2018

BGP Series 5: BGP Neighbor States, Message Types, BGP Table and Verification Commands

BGP Series 5: BGP Neighbor States, Message Types, BGP Table and Verification Commands

BGP Neighbor States:

  • Idle: bgp process is not even active. Could be due to bgp being administratively shut (or) no route to neighbor in routing table [most likely]
  • Connect: [very rarely seen] bgp is waiting for tcp connection to be completed
  • Active: Tcp connection failed. Could be due to variety of reasons→ we have a route to the neighbor, but the dest-ip itself is not present (either bgp is not configured on the neighbor, Acl on middle devices are blocking the tcp, and all other reasons why tcp could fail...). In Active state, we will be listening for incoming tcp connections, but we won’t be trying for any connections. It is not essentially a bgp problem, we need to troubleshoot why tcp is failing.
  • OpenSent: TCP connection exists and we sent a BGP Open message to neighbor, but we haven’t yet received a matching Open message from neighbor. Open message is sent only initially and it contains info about us like our AS, bgp capabilities like ipv4/ipv6,...
  • OpenConfirm: Open message has been both sent and received form the neighbor router
  • Established: All neighbor parameters match and peers can exchange Update messages

BGP Message Types:

  • All BGP messages are carried within IP/TCP headers

  • Even though there are different bgp messages like Open, Update, KeepAlive and Notification, the header is the same:

  • img

    • Marker is 16-bytes and usually contains all F-s (in hex) (or) all-1s (in binary). If using authentication, we could see different value
    • Type field indicates what type of bgp message is in the data- Open/Update/Notification/KeepAlive
  • BGP Open Message:

    • Type code=1

    • This is the first bgp message sent to each other for neighbor establishment

    • BGP values and capabilities are exchanged

    • Absolute minimum which are present in the Open message are

      • \1. Version (tells which bgp version I’m using)
      • \2. My AS# (my AS number)
      • \3. Hold Time (my current hold time...by default it is 180 sec or 3 min)
      • \4. Router-id
      • \5. Optional Parameters Length (if we have any optional parameters, we need to tell the length of the optional parameters)
      • \6. BGP Parameters /My BGP Capabilities- like IPv4 unicast, IPv6 unicast, multicast, Route refresh, ...
    • img

  • BGP Update Message:

    • Type code=2

    • Informs neighbors about withdrawn routes, changes routes and new routes

    • img

    • At beginning, we have withdrawn route length and withdrawn routes (if any).

      • It is different from IGP. In IGPs, in order to remove a route, in LSA update message, we set the age field of that route to maximum (3600 sec)
      • BGP has a dedicated field for withdrawn routes
    • Below that, there is a section for new routes and changed routes.

    • We already know of a few bgp attributes such as AS-path and next-hop. If the routes were originating from same AS, then, we will have the same attributes. Only thing different between them will be the prefixes and subnet masks. So, that is why path attributes are used to identify routes.

    • Now, we need to have a path-attribute length because some path attributes are mandatory like next-hop, AS-path and origin. But, there are also lot of optional attributes. So, we need to know the length of the path attributes for those routes. After this, we have the path attributes TLV

      • Each path attribute is a TLV. Has a type telling what attribute it is. Then, length of the data in it and then the Value of the data.
    • After this, we have the NLRI Prefix (subnet) and the prefix length (subnet mask).

    • Example packet capture of BGP Update:

      • img
  • BGP Notification Message:

    • Sometimes in a bgp neighborship, somethings might not match-like the AS might not match our config, etc...then Notification message is sent to that neighbor
    • This is an error message sent to the neighbor
    • Will typically result in bgp reset to the neighbor relationship
    • Type code=3
    • img
    • It contains error code, error sub-code and data
    • Error code tells the type of error-> like malformed bgp header, corrupted bgp message, error in open message, error in update message, etc…
    • For example, in below example, the error code is 2 meaning error in Open message and error-subcode is 2 which means the neighbor is telling me that it is in AS-2 but as per my config that is wrong, you are supposed to be in something else.
    • img
  • KeepAlive Message:

    • It is sent on periodic basis to maintain neighbor relationship
    • If KeepAlive is not received within Hold Timer, bgp neighborship is brought down
    • It contains just the bgp header without any data
    • Type =4
    • img

 

BGP Table and BGP Routes:

  • Just like OSPF has its Link State database, BGP has its own its own bgp table

  • Can be seen by running ‘show ip bgp’

    • This will just list a high-level snapshot of all the bgp-learned routes
    • Includes both locally injected and learned from neighbors
    • With each prefix, we can see 2-3 attributes of that route that are used for best path selection. If we want to see all the attributes, we need to drill down in detail for that route
    • Each prefix can have multiple paths with different next-hops
  • We can add ‘network’ command to get more information in detail about that network

  • Example of bgp table:

    • img

    • If ‘>’ symbol is there, that path is chosen as best path for that route

    • If next-hop is 0.0.0.0, then, this router originated that route, via OSPF,... and injected into bgp

    • We can see that this router learnt the exact same route via an iBgp neighbor as well → we know it is iBGP by looking at the ‘i’ at the left (next to *)

    • Let us skip going into Metric, LocPrf and Weight for now

    • In the far right, if we see the Path field→

      • If the path is empty, it means that the prefix lives in our AS (originated from our AS, either from IGP or other ways)
      • If we look at 10.97.97.0/24, we will look at it as the AS on the right (64997) is where this prefix originated. From there it went to AS 64998 and then it came to us. So, this prefix is 2 AS away from us.
      • Unlike IGPs, BGP does not care how many routers it has to cross to reach that prefix. It only cares about how many AS we need to cross to reach that prefix. Hence, it is called AS-path and BGP is known as Path-vector protocol
      • Note the ‘i’ in the AS-path, we might be confused that it stands for iBGP, but they are not. iBGP is denoted on the left side...The ‘i’ in AS-path stands for something completely different which we will come to later on

    BGP Prefix Status Codes:

    • Prefixes with ‘*’ are considered valid and they will be included in best-path calculation
    • Prefixes with ‘r’ means RIB-failure means I learnt the route, but something prevented me from putting this route into my routing table which could be due to variety of things→ For other reasons for Rib-failure, see ‘iBGP BGP Table Entries section

    Verification commands for eBGP-learnt routes:

    • img
    • ‘Show ip bgp /’ will give more detail about a particular route
    • ‘Show ip bgp neighbors routes’ will show all the routes received from that particular neighbor
    • ‘Show ip bgp summary’ shows summary of the bgp messages received from our bgp neighbors...includes messages sent/received and also number of bgp prefixes received

 

No comments:

Post a Comment