peering-toolbox:route_server
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
peering-toolbox:route_server [2022/07/31 21:03] – [Purpose] philip | peering-toolbox:route_server [2022/08/26 20:04] (current) – [Bogon Filtering] philip | ||
---|---|---|---|
Line 11: | Line 11: | ||
Without a Route Server, the BGP mesh at an IXP would look similar to the following diagram: | Without a Route Server, the BGP mesh at an IXP would look similar to the following diagram: | ||
- | {{: | + | {{: |
+ | |||
+ | where each line represents a BGP session between two IXP members. This is basically an n-squared mesh. | ||
+ | |||
+ | Introducing a Route Server results in the BGP sessions for each member being with the Route Route Server, meaning that the number of BGP sessions goes up linearly per member (from Route Server point of view). | ||
+ | |||
+ | {{: | ||
+ | |||
+ | with each member only having to maintain their BGP sessions with the two Route Servers. | ||
+ | |||
+ | ===== Routing & Forwarding ===== | ||
It is important to note that the Route Server is not involved in packet forwarding at the IXP, nor does it carry any of the IXP's traffic. The Route Server takes advantage of a BGP feature known as "third party next-hop" | It is important to note that the Route Server is not involved in packet forwarding at the IXP, nor does it carry any of the IXP's traffic. The Route Server takes advantage of a BGP feature known as "third party next-hop" | ||
- | The Route Server also does not insert its Autonomous System Number into the AS Path. This means that, to all intents and purposes, it appears as though the IXP members are peering directly with each other, as their AS Numbers appear immediately adjacent in the AS Path. | + | The Route Server also does not insert its Autonomous System Number into the AS Path. This means that, to all intents and purposes, it appears as though the IXP members are peering directly with each other, as their AS Numbers appear immediately adjacent in the AS Path. BGP implementations adhering to the BGP specification as per [[https:// |
+ | |||
+ | On Cisco IOS, for example, the configuration commands to do this are: | ||
+ | < | ||
+ | router bgp < | ||
+ | no bgp enforce-first-as | ||
+ | </ | ||
+ | Note that on Cisco IOS there is no ability to set this per neighbour, something which needs to be considered if the peering router used has multiple private and public peers connected to it. | ||
+ | |||
+ | ===== Route Server Uses ===== | ||
+ | |||
+ | Apart from helping scale the BGP mesh at larger IXPs, Route Servers have other value add considerations for Internet Exchange Points. | ||
+ | |||
+ | ==== Bogon Filtering ==== | ||
+ | |||
+ | Internet Exchange Points often use their Route Servers to implement bogon prefix filtering and bogon AS filtering. While members of IXPs will normally do this if they are following [[https:// | ||
+ | |||
+ | Bogon prefix filtering means dropping all prefixes which are not used in the public Internet. This includes private, reserved, and unassigned address space. | ||
+ | |||
+ | Bogon AS filtering means dropping all prefixes originated by Autonomous Systems using private, reserved, or unassigned ASNs. | ||
+ | |||
+ | ==== Route Origin Validation ==== | ||
+ | Route Servers are also used nowadays to implement Route Origin Validation, also noted in the [[https:// | ||
+ | |||
+ | ===== Route Servers and Peering Policies ===== | ||
+ | |||
+ | Operators who have an Open Peering policy are typically those who would peer at a Route Server. There is no operational relationship between the peers when they use a Route Server, as each peer only sets up their BGP session with the Route Server. | ||
+ | |||
+ | Operators who have a Selective Peering policy will typically not use the IXPs Route Server unless the Route Server has been set up to allow per-member policy. Operators with Selective Peering policies normally want to have a direct operational relationship with their peer, and would typically set up a Bi-Lateral peering with them. | ||
+ | |||
+ | ===== Implementations ===== | ||
+ | |||
+ | There are several Route Server implementations, | ||
+ | * [[http:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | The majority of Internet Exchange Points use BIRD, and it integrates very easily with [[https:// | ||
+ | At least Cisco and Juniper have Route Server implementations in their router software, but they are generally not recommended for use today (in the author' | ||
+ | On Cisco, from IOS 15.2 and IOS-XE 3.7, the BGP configuration command to enable a neighbour as a Route Server Client is: | ||
+ | < | ||
+ | router bgp <ASN> | ||
+ | | ||
+ | </ | ||
+ | and on Juniper as from JunOS 17.4, the BGP configuration command to enable a neighbour as a Route Server Client is: | ||
+ | < | ||
+ | set routing-instances protocols bgp group < | ||
+ | </ | ||
[[: | [[: |
peering-toolbox/route_server.txt · Last modified: 2022/08/26 20:04 by philip