The translation has come to an end.
Exit Zen
91
../../protocols/bgp.rst:365
English
Another important utilization of the `local-pref` attribute is to support the `customer->provider` and `shared-cost` peering relationships. From an economic point of view, there is an important difference between these three types of peering relationships. A domain usually earns money when it sends packets over a `provider->customer` relationship. On the other hand, it must pay its provider when it sends packets over a `customer->provider` relationship. Using a `shared-cost` peering to send packets is usually neutral from an economic perspective. To take into account these economic issues, domains usually configure the import filters on their routers as follows :
0/6710 · 671
92
../../protocols/bgp.rst:367
English
insert a high `local-pref` attribute in the routes learned from a customer
0/740 · 74
93
../../protocols/bgp.rst:368
English
insert a medium `local-pref` attribute in the routes learned over a shared-cost peering
0/870 · 87
94
../../protocols/bgp.rst:369
English
insert a low `local-pref` attribute in the routes learned from a provider
0/730 · 73
95
../../protocols/bgp.rst:371
English
With such an import filter, the routers of a domain always prefer to reach destinations via their customers whenever such a route exists. Otherwise, they prefer to use `shared-cost` peering relationships and they only send packets via their providers when they do not know any alternate route. A consequence of setting the `local-pref` attribute like this is that Internet paths are often asymmetrical. Consider for example the internetwork shown in the figure below.
0/4670 · 467
96
../../protocols/bgp.rst:377
English
Asymmetry of Internet paths
0/270 · 27
97
../../protocols/bgp.rst:379
English
Consider in this internetwork the routes available inside `AS1` to reach `AS5`. `AS1` learns the `AS4:AS6:AS7:AS5` path from `AS4`, the `AS3:AS8:AS5` path from `AS3` and the `AS2:AS5` path from `AS2`. The first path is chosen since it was learned from a customer. `AS5` on the other hand receives three paths towards `AS1` via its providers. It may select any of these paths to reach `AS1` , depending on how it prefers one provider over the others.
0/4490 · 449
98
../../protocols/bgp.rst:384
English
BGP convergence
0/150 · 15
99
../../protocols/bgp.rst:387
English
In the previous sections, we have explained the operation of BGP routers. Compared to intradomain routing protocols, a key feature of BGP is its ability to support interdomain routing policies that are defined by each domain as its import and export filters and ranking process. A domain can define its own routing policies and router vendors have implemented many configuration tweaks to support complex routing policies. However, the routing policy chosen by a domain may interfere with the routing policy chosen by another domain. To understand this issue, let us first consider the simple internetwork shown below.
0/6180 · 618
100
../../protocols/bgp.rst:394
English
The disagree internetwork
0/250 · 25
101
../../protocols/bgp.rst:396
English
In this internetwork, we focus on the route towards `2001:db8::1234/48` which is advertised by `AS1`. Let us also assume that `AS3` (resp. `AS4`) prefers, e.g. for economic reasons, a route learned from `AS4` (`AS3`) over a route learned from `AS1`. When `AS1` sends `U(2001:db8::1234/48,AS1)` to `AS3` and `AS4`, three sequences of exchanges of BGP messages are possible :
0/3730 · 373
102
../../protocols/bgp.rst:398
English
`AS3` sends first `U(2001:db8:1234/48,AS3:AS1)` to `AS4`. `AS4` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS3` and does not advertise a route to `AS3`
0/2190 · 219
103
../../protocols/bgp.rst:399
English
`AS4` first sends `U(2001:db8:1234/48,AS4:AS1)` to `AS3`. `AS3` has learned two routes towards `2001:db8:1234/48`. It runs its BGP decision process and selects the route via `AS4` and does not advertise a route to `AS4`
0/2190 · 219
104
../../protocols/bgp.rst:400
English
`AS3` sends `U(2001:db8:1234/48,AS3:AS1)` to `AS4` and, at the same time, `AS4` sends `U(2001:db8:1234/48,AS4:AS1)`. `AS3` prefers the route via `AS4` and thus sends `W(2001:db8:1234/48)` to `AS4`. In the mean time, `AS4` prefers the route via `AS3` and thus sends `W(2001:db8:1234/48)` to `AS3`. Upon reception of the `BGP Withdraws`, `AS3` and `AS4` only know the direct route towards `2001:db8:1234/48`. `AS3` (resp. `AS4`) sends `U(2001:db8:1234/48,AS3:AS1)` (resp. `U(2001:db8:1234/48,AS4:AS1)`) to `AS4` (resp. `AS3`). `AS3` and `AS4` could in theory continue to exchange BGP messages for ever. In practice, one of them sends one message faster than the other and BGP converges.
0/6850 · 685
105
../../protocols/bgp.rst:402
English
The example above has shown that the routes selected by BGP routers may sometimes depend on the ordering of the BGP messages that are exchanged. Other similar scenarios may be found in :rfc:`4264`.
0/1970 · 197
106
../../protocols/bgp.rst:404
English
From an operational perspective, the above configuration is annoying since the network operators cannot easily predict which paths are chosen. Unfortunately, there are even more annoying BGP configurations. For example, let us consider the configuration below which is often named `Bad Gadget` [GW1999]_
0/3030 · 303
107
../../protocols/bgp.rst:410
English
The bad gadget internetwork
0/270 · 27
108
../../protocols/bgp.rst:413
English
In this internetwork, there are four ASes. `AS0` advertises one route towards one prefix and we only analyze the routes towards this prefix. The routing preferences of `AS1`, `AS3` and `AS4` are the following :
0/2100 · 210
109
../../protocols/bgp.rst:415
English
`AS1` prefers the path `AS3:AS0` over all other paths
0/530 · 53
110
../../protocols/bgp.rst:416
English
`AS3` prefers the path `AS4:AS0` over all other paths
0/530 · 53