Exit Zen
76
../../protocols/bgp.rst:298
English
The first solution is the most frequent. Advertising routes learned from an intradomain routing protocol is not recommended, this is because if the route flaps [#fflap]_, this would cause a large number of BGP messages being exchanged in the global Internet.
0/2580 · 258
77
../../protocols/bgp.rst:304
English
The BGP decision process
0/240 · 24
78
../../protocols/bgp.rst:306
English
Besides the import and export filters, a key difference between BGP and the intradomain routing protocols is that each domain can define its own ranking algorithm to determine which route is chosen to forward packets when several routes have been learned towards the same prefix. This ranking depends on several BGP attributes that can be attached to a BGP route.
0/3630 · 363
79
../../protocols/bgp.rst:311
English
The first BGP attribute that is used to rank BGP routes is the `local-preference` (local-pref) attribute. This attribute is an unsigned integer that is attached to each BGP route received over an eBGP session by the associated import filter.
0/2410 · 241
80
../../protocols/bgp.rst:313
English
When comparing routes towards the same destination prefix, a BGP router always prefers the routes with the highest `local-pref`. If the BGP router knows several routes with the same `local-pref`, it prefers among the routes having this `local-pref` the ones with the shortest AS-Path.
0/2840 · 284
81
../../protocols/bgp.rst:315
English
The `local-pref` attribute is often used to prefer some routes over others.
0/750 · 75
82
../../protocols/bgp.rst:319
English
A common utilization of `local-pref` is to support backup links. Consider the situation depicted in the figure below. `AS1` would always like to use the high bandwidth link to send and receive packets via `AS2` and only use the backup link upon failure of the primary one.
0/2720 · 272
83
../../protocols/bgp.rst:325
English
How to create a backup link with BGP ?
0/380 · 38
84
../../protocols/bgp.rst:327
English
As BGP routers always prefer the routes with the highest `local-pref` attribute, this policy can be implemented using the following import filter on `R1`
0/1530 · 153
85
../../protocols/bgp.rst:335
English
With this import filter, all the BGP routes learned from `RB` over the high bandwidth links are preferred over the routes learned over the backup link. If the primary link fails, the corresponding routes are removed from `R1`'s RIB and `R1` uses the route learned from `RA`. `R1` reuses the routes via `RB` as soon as they are advertised by `RB` once the `R1-RB` link comes back.
0/3790 · 379
86
../../protocols/bgp.rst:337
English
The import filter above modifies the selection of the BGP routes inside `AS1`. Thus, it influences the route followed by the packets forwarded by `AS1`. In addition to using the primary link to send packets, `AS1` would like to receive its packets via the high bandwidth link. For this, `AS2` also needs to set the `local-pref` attribute in its import filter.
0/3590 · 359
87
../../protocols/bgp.rst:346
English
Sometimes, the `local-pref` attribute is used to prefer a `cheap` link compared to a more expensive one. For example, in the network below, `AS1` could wish to send and receive packets mainly via its interdomain link with `AS4`.
0/2280 · 228
88
../../protocols/bgp.rst:352
English
How to prefer a cheap link over an more expensive one ?
0/550 · 55
89
../../protocols/bgp.rst:354
English
`AS1` can install the following import filter on `R1` to ensure that it always sends packets via `R2` when it has learned a route via `AS2` and another via `AS4`.
0/1620 · 162
90
../../protocols/bgp.rst:363
English
However, this import filter does not influence how `AS3` , for example, prefers some routes over others. If the link between `AS3` and `AS2` is less expensive than the link between `AS3` and `AS4`, `AS3` could send all its packets via `AS2` and `AS1` would receive packets over its expensive link. An important point to remember about `local-pref` is that it can be used to prefer some routes over others to send packets, but it has no influence on the routes followed by received packets.
0/4890 · 489
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