Quagga BGP

    In a previous article, I described the general Quagga architecture and the routing table device, which is located in the zebra daemon. In this article I want to talk about the device bgpd daemon responsible for implementing the BGP protocol.

    I will not describe general information about BGP. There are a lot of good articles and books about him, and you can get acquainted with the logic of his work, for example, here . I will focus on the mechanism for its implementation in the bgpd daemon. For convenience, the description of the bgpd daemon can be divided into two parts.

    The first part is called the BGP table (similar to the routing table). All known BGP routes with their attributes are stored here, comparisons of various BGP routes are made and the best ones are selected.

    The second part will be called a strapping. Bindings are numerous settings that affect which routes get into the BGP table, which routes are advertised to neighbors, how the attributes of BGP routes change, etc. Those. these are various distribute-list, prefix-list, route-map, redistribute and so on.

    BGP table


    The BGP table in its design is very similar to the routing table in zebra. Similarly, each prefix corresponds to several different routes received from different sources. Only instead of the administrative distance and metric are the various BGP attributes used, as shown in the figure.



    Only attributes affecting the selection of the best route are shown here. For example, the community attribute does not directly affect the choice of the best route and is not shown in the figure.

    Each route also stores a pointer to a BGP neighbor (BGP Peer) from which the route was received, which allows you to use the appropriate information about the neighbor, namely: the type of neighbor (IBGP or EBGP), its router-id and ip-address. When you receive or delete the next route, a procedure is started that, using a sequential pairwise comparison of routes, selects the best one for this prefix.

    Algorithm for comparing two BGP routes


    Of the two routes, the best one is considered to be (the criteria are listed in order of decreasing priority):

    1. Larger Weight value.
    2. Larger Local Preference.
    3. The route was created locally (using the network, redistribute, or aggregate-address command).
    4. Shorter AS-PATH.
    5. Lower Origin value (IGP <EGP <INCOMPLETE)
    6. Lower MED value.
    7. The type of neighbor from which the route was received (eBGP is better than iBGP)
    8. Smaller IGP metric to the next-hop specified in the route.
    9. If both routes are eBGP, then the previously selected as the best (ie, older) route is preferable.
    10. Smaller neighbor-router-id.
    11. Shorter Cluster list.
    12. Smaller neighbor IP address.

    In the above example, the route marked in green is the best because it has the greatest Local Preference.

    If for some routes the first 8 points coincide with the best route, then they (when setting maximum-paths is greater than 1) are remembered and can then be processed and transferred to zebra as a multi-path route.

    In the same way as in zebra, all the prefixes used in the BGP table are organized as a prefix tree, and the same algorithm is used to quickly find the desired prefix.

    Strapping


    The binding around the BGP table is shown.



    BGP routes can come either from BGP neighbors or be created locally. Before they get into the BGP table, they go through a series of checks and their attributes can be filtered out or changed. After choosing the best route, this route is sent to neighbors and gets into the zebra routing table.

    Getting a BGP Route from a Neighbor


    Before routes get to the BGP table, they go through several steps in which they can be filtered or changed. The route path from receiving it from a neighbor to getting into the BGP table is shown in the figure. In bold, commands are shown that include the corresponding functionality.



    First of all, when a packet is received, it is parsed, i.e. the contents of the packet are analyzed, checked for correctness, and an internal structure representing the BGP route is formed from the data contained in the packet.

    Next, an aspath loop check is performed, i.e. Verify that the AS-PATH does not contain the number of the autonomous system to which the router belongs. This check is key to preventing routing loops in BGP.

    Then, various route filtering mechanisms are executed if they are configured for the BGP neighbor from which the packet was received. Distribute-list filters the route based on the prefix ip address, prefix-list based on the prefix ip address and its length, filter-list filters based on the contents of the BGP AS-PATH route.

    If the route has successfully passed all the filtering stages, then the incoming route-map is applied to it. Here, you can flexibly modify the attributes of the received BGP route. Depending on the prefix and various attributes of the BGP route, such as AS-PATH, community, MED, next-hop, origin, the IP addresses of the BGP neighbor, you can change weight, AS-PATH, community, next-hop, local preference, MED, origin or also filter the route.

    Now our route is almost ready to be added to the BGP table, and the last step is to ask zebra for the next-hop validity and metric to it.

    Local BGP Route Creation


    A BGP route can also be created locally using the network or redistribute commands. The figure shows the schemes for adding such routes.



    Adding a route using the network command is quite simple. Unlike Cisco, Quagga does not check for the presence of this route in the zebra routing table. Therefore, this route is filled with default values, route-map is used to change its attributes, and the route is added to the BGP table.

    When the redistribute command is issued, the bgpd daemon calls on the zebra daemon to sign (mark) it on adding or removing routes of a certain type (for example, OSPF) in the routing table. When a new route is added to the routing table, zebra sequentially checks which daemons are subscribed to routes of this type and sends this route to the subscribed daemons. After receiving a new route from zebra, the bgpd daemon changes MED, applies the route-map and adds it to the BGP table.

    Sending a new route to BGP neighbors


    After choosing a new best BGP route, this route is sent to the BGP neighbors. In this case, all BGP neighbors are sorted out sequentially and it is checked whether the route should be sent to this neighbor. This procedure, performed for each BGP neighbor, is shown in the figure.



    The first step is to verify that the recipient of the route is not the neighbor from whom the route was received.

    Next, the community route is checked. If community contains a no-advertise value, then the route is not advertised. Also, the route is not announced if the recipient type is eBGP, and the community contains a no-export value.

    Then comes the filtering using the outgoing distribute-list, prefix-list and filter-list in the same way as for incoming BGP routes.

    It is verified that the route received from the iBGP neighbor should not be transferred to another iBGP neighbor (assuming that Route Reflector is not used).

    For routes that did not have a local preference, the default local preference is set. If there is a neighbor 1.1.1.1 next-hop-self setting, or the neighbor is eBGP, then next-hop is replaced with its own ip address.

    An outgoing route-map is used, which allows you to change the attributes of the advertised route, or filter it at the last stage.

    After successfully passing all the previous steps from the BGP route, a BGP Update packet is generated which is sent to the neighbor.

    Sending a new route to zebra


    In addition to sending a new BGP route to its neighbors, the router also sends this route to zebra. This procedure is shown in the figure.



    Before sending a route to zebra, an Administrative Distance is established for it, depending on the type of route (iBGP or eBGP). All the necessary fields are taken from the BGP route: the type of route (BGP), next-hop (or several next-hop if multi-path is used) and the metric, after which the route is sent to zebra and begins to compete with routes from other routing protocols.

    Conclusion


    Of course, this article does not describe all the features of BGP in Quagga. I did not consider the functionality of route-reflector, confederations, IPv6, etc. Nevertheless, the above architecture of the bgpd daemon is basically preserved even with this functionality in mind. The following is a brief description of the implementation of some additional features of the bgpd daemon.

    To use IPv6, a separate BGP table is created that uses IPv6 prefixes instead of IPv4 prefixes. All other logic of operation of the BGP table for IPv6 and its binding remains more or less similar to the above operation logic for IPv4.

    When using the Route-Reflector, the logic for checking which neighbors to send BGP routes changes slightly, and when a route is received, additional checks appear to exclude loops (checks on the Originator ID and Cluster List attributes).

    Small changes in the operation of the algorithm for choosing the best route in the BGP table (so to speak, fine-tuning it) can be made using the following global BGP settings:

    • bgp bestpath as-path ignore - skips step 4 (AS-PATH length comparison)
    • bgp bestpath compare-routerid - skips step 9 (choosing an older route)
    • bgp bestpath med missing-as-worst - if the route does not have MED, then this setting considers that the route has the maximum possible MED. Without this setting, the missing MED is assumed to be 0.
    • bgp always-compare-med - allows you to compare MED for routes received from different ASs. Without this setting, step 6 for routes received from different ASs is skipped.
    • bgp deterministic-med - changes the order of comparison of routes. Instead of sequentially comparing routes with each other, the routes received from the same AS are first compared with each other. Read more about this setting here .

    Also popular now: