2. cnp3-ebook
3. protocols/bgp
4. English
5. Zen

16 ../../protocols/bgp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — over a `provider->customer` relationship, the `provider` advertises all the routes that it knows to its `customer`. 115/10000 · 115
17 ../../protocols/bgp.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second rule ensures that the customer domain receives a route towards all destinations that are reachable via its provider. The first rule allows the prefixes of the customer domain to be distributed throughout the Internet. 228/10000 · 228
18 ../../protocols/bgp.rst:62
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Coming back to the figure above, `AS4` advertises to its two providers `AS1` and `AS2` its own prefixes and the routes learned from its customer, `AS7`. On the other hand, `AS4` advertises to `AS7` all the routes that it knows. 227/10000 · 227
19 ../../protocols/bgp.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second type of peering relationship is the `shared-cost` peering relationship. Such a relationship usually does not involve a payment from one domain to the other in contrast with the `customer->provider` relationship. A `shared-cost` peering relationship is usually established between domains having a similar size and geographic coverage. For example, consider the figure above. If `AS3` and `AS4` exchange many packets via `AS1`, they both need to pay `AS1`. A cheaper alternative for `AS3` and `AS4` would be to establish a `shared-cost` peering. Such a peering can be established at IXPs where both `AS3` and `AS4` are present or by using private peering links. This `shared-cost` peering should be used to exchange packets between hosts inside `AS3` and hosts inside `AS4`. However, `AS3` does not want to receive on the `AS3-AS4` `shared-cost` peering links packets whose destination belongs to `AS1` as `AS3` would have to pay to send these packets to `AS1`. 971/10000 · 971
20 ../../protocols/bgp.rst:68
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets. 1049/10000 · 1049
21 ../../protocols/bgp.rst:72
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Finally, the last type of peering relationship is the `sibling`. Such a relationship is used when two domains exchange all their routes in both directions. In practice, such a relationship is only used between domains that belong to the same company. 250/10000 · 250
22 ../../protocols/bgp.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts : 195/10000 · 195
23 ../../protocols/bgp.rst:78
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets) 216/10000 · 216
24 ../../protocols/bgp.rst:79
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `export filter` that specifies, for each peering relationship, the routes that can be advertised to the neighboring domain 126/10000 · 126
25 ../../protocols/bgp.rst:80
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `ranking` algorithm that is used to select the best route among all the routes that the domain has received towards the same destination prefix 147/10000 · 147
26 ../../protocols/bgp.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A domain's import and export filters can be defined by using the Route Policy Specification Language (RPSL) specified in :rfc:`2622` [GAVE1999]_ . Some Internet Service Providers, notably in Europe, use RPSL to document [#fripedb]_ their import and export policies. Several tools help to easily convert a RPSL policy into router commands. 338/10000 · 338
27 ../../protocols/bgp.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below provides a simple example of import and export filters for two domains in a simple internetwork. In RPSL, the keyword `ANY` is used to replace any route from any domain. It is typically used by a provider to indicate that it announces all its routes to a customer over a `provider->customer` relationship. This is the case for `AS4`'s export policy. The example below clearly shows the difference between a `provider->customer` and a `shared-cost` peering relationship. `AS4`'s export filter indicates that it announces only its internal routes (`AS4`) and the routes learned from its clients (`AS7`) over its `shared-cost` peering with `AS3`, while it advertises all the routes that it uses (including the routes learned from `AS3`) to `AS7`. 760/10000 · 760
28 ../../protocols/bgp.rst:92
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Import and export policies 26/10000 · 26
29 ../../protocols/bgp.rst:97
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Border Gateway Protocol 27/10000 · 27
30 ../../protocols/bgp.rst:99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Internet uses a single interdomain routing protocol : the Border Gateway Protocol (BGP). The current version of BGP is defined in :rfc:`4271`. BGP differs from the intradomain routing protocols that we have already discussed in several ways. First, BGP is a `path-vector` protocol. When a BGP router advertises a route towards a prefix, it announces the IP prefix and the interdomain path used to reach this prefix. From BGP's point of view, each domain is identified by a unique `Autonomous System` (AS) number [#fasdomain]_ and the interdomain path contains the AS numbers of the transit domains that are used to reach the associated prefix. This interdomain path is called the `AS Path`. Thanks to these AS-Paths, BGP does not suffer from the count-to-infinity problems that affect distance vector routing protocols. Furthermore, the AS-Path can be used to implement some routing policies. Another difference between BGP and the intradomain routing protocols is that a BGP router does not send the entire contents of its routing table to its neighbors regularly. Given the size of the global Internet, routers would be overloaded by the number of BGP messages that they would need to process. BGP uses incremental updates, i.e. it only announces the routes that have changed to its neighbors. 1299/10000 · 1299
31 ../../protocols/bgp.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below shows a simple example of the BGP routes that are exchanged between domains. In this example, prefix `2001:db8:cafe::/48` is announced by `AS1`. `AS1` advertises a BGP route towards this prefix to `AS2`. The AS-Path of this route indicates that `AS1` is the originator of the prefix. When `AS4` receives the BGP route from `AS1`, it re-announces it to `AS2` and adds its AS number to the AS-Path. `AS2` has learned two routes towards prefix `2001:db8:cafe::/48`. It compares the two routes and prefers the route learned from `AS4` based on its own ranking algorithm. `AS2` advertises to `AS5` a route towards `2001:db8:cafe::/48` with its AS-Path set to `AS2:AS4:AS1`. Thanks to the AS-Path, `AS5` knows that if it sends a packet towards `2001:db8:cafe::/48` the packet first passes through `AS2`, then through `AS4` before reaching its destination inside `AS1`. 879/10000 · 879
32 ../../protocols/bgp.rst:106
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Simple exchange of BGP routes 29/10000 · 29
33 ../../protocols/bgp.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BGP routers exchange routes over BGP sessions. A BGP session is established between two routers belonging to two different domains that are directly connected. As explained earlier, the physical connection between the two routers can be implemented as a private peering link or over an Internet eXchange Point. A BGP session between two adjacent routers runs above a TCP connection (the default BGP port is 179). In contrast with intradomain routing protocols that exchange IP packets or UDP segments, BGP runs above TCP because TCP ensures a reliable delivery of the BGP messages sent by each router without forcing the routers to implement acknowledgments, checksums, etc. Furthermore, the two routers consider the peering link to be up as long as the BGP session and the underlying TCP connection remain up [#flifetimebgp]_. The two endpoints of a BGP session are called `BGP peers`. 886/10000 · 886
34 ../../protocols/bgp.rst:116
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A BGP peering session between two directly connected routers 60/10000 · 60
35 ../../protocols/bgp.rst:118
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, to establish a BGP session between routers `R1` and `R2` in the figure above, the network administrator of `AS3` must first configure on `R1` the IP address of `R2` on the `R1-R2` link and the AS number of `R2`. Router `R1` then regularly tries to establish the BGP session with `R2`. `R2` only agrees to establish the BGP session with `R1` once it has been configured with the IP address of `R1` and its AS number. For security reasons, a router never establishes a BGP session that has not been manually configured on the router. 544/10000 · 544