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

53 ../../protocols/bgp.rst:163
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Forwarding Information Base` (`FIB`) is used by the dataplane to forward packets towards their destination. The `FIB` contains, for each destination, the best route that has been selected by the `BGP decision process`. This decision process is an algorithm that selects, for each destination prefix, the best route according to the router's ranking algorithm that is part of its policy. 391/10000 · 391
54 ../../protocols/bgp.rst:164
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Adj-RIB-Out` contains the BGP routes that have been advertised to each BGP peer. The `Adj-RIB-Out` for a given peer is built by applying the peer's `export filter` on the routes that have been installed in the `FIB`. There is one `export filter` per BGP peer. For this reason, the Adj-RIB-Out of a peer may contain different routes than the Adj-RIB-Out of another peer. 374/10000 · 374
55 ../../protocols/bgp.rst:166
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a BGP session starts, the routers first exchange `OPEN` messages to negotiate the options that apply throughout the entire session. Then, each router extracts from its FIB the routes to be advertised to the peer. It is important to note that, for each known destination prefix, a BGP router can only advertise to a peer the route that it has itself installed inside its `FIB`. The routes that are advertised to a peer must pass the peer's `export filter`. The `export filter` is a set of rules that define which routes can be advertised over the corresponding session, possibly after having modified some of its attributes. One `export filter` is associated to each BGP session. For example, on a `shared-cost peering`, the `export filter` only selects the internal routes and the routes that have been learned from a `customer`. The pseudo-code below shows the initialization of a BGP session. 899/10000 · 899
56 ../../protocols/bgp.rst:184
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the above pseudo-code, the `build\_BGP\_update(d)` procedure extracts from the `BGP Loc-RIB` the best path towards destination `d` (i.e. the route installed in the FIB) and prepares the corresponding BGP `UPDATE` message. This message is then passed to the `export filter` that returns `None` if the route cannot be advertised to the peer or the (possibly modified) BGP `UPDATE` message to be advertised. BGP routers allow network administrators to specify very complex `export filters`, see e.g. [WMS2004]_. A simple `export filter` that implements the equivalent of `split horizon` is shown below. 602/10000 · 602
57 ../../protocols/bgp.rst:197
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, the remote router has received all the exportable BGP routes. After this initial exchange, the router only sends `BGP UPDATE` messages when there is a change (addition of a route, removal of a route or change in the attributes of a route) in one of these exportable routes. Such a change can happen when the router receives a BGP message. The pseudo-code below summarizes the processing of these BGP messages. 424/10000 · 424
58 ../../protocols/bgp.rst:237
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a BGP message is received, the router first applies the peer's `import filter` to verify whether the message is acceptable or not. If the message is not acceptable, the processing stops. The pseudo-code below shows a simple `import filter`. This `import filter` accepts all routes, except those that already contain the local AS in their AS-Path. If such a route was used, it would cause a routing loop. Another example of an `import filter` would be a filter used by an Internet Service Provider on a session with a customer to only accept routes towards the IP prefixes assigned to the customer by the provider. On real routers, `import filters` can be much more complex and some `import filters` modify the attributes of the received BGP `UPDATE` [WMS2004]_ . 767/10000 · 767
59 ../../protocols/bgp.rst:256
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The bogon filters 17/10000 · 17
60 ../../protocols/bgp.rst:258
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another example of frequently used `import filters` are the filters that Internet Service Providers use to ignore bogon routes. In the ISP community, a bogon route is a route that should not be advertised on the global Internet. Typical examples include the documentation IPv6 prefix (`2001:db8::/32` used for most examples in this book), the loopback address (`::1/128`) or the IPv6 prefixes that have not yet been allocated by IANA. A well managed BGP router should ensure that it never advertises bogons on the global Internet. Detailed information about these bogons may be found in [IMHM2013]_. 599/10000 · 599
61 ../../protocols/bgp.rst:263
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If the import filter accepts the BGP message, the pseudo-code distinguishes two cases. If this is an `Update message` for prefix `p`, this can be a new route for this prefix or a modification of the route's attributes. The router first retrieves from its `RIB` the best route towards prefix `p`. Then, the new route is inserted in the `RIB` and the `BGP decision process` is run to find whether the best route towards destination `p` changes. A BGP message only needs to be sent to the router's peers if the best route has changed. For each peer, the router applies the `export filter` to verify whether the route can be advertised. If yes, the filtered BGP message is sent. Otherwise, a `Withdraw message` is sent. When the router receives a `Withdraw message`, it also verifies whether the removal of the route from its `RIB` caused its best route towards this prefix to change. It should be noted that, depending on the content of the `RIB` and the `export filters`, a BGP router may need to send a `Withdraw message` to a peer after having received an `Update message` from another peer and conversely. 1107/10000 · 1107
62 ../../protocols/bgp.rst:265
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us now discuss in more detail the operation of BGP in an IPv6 network. For this, let us consider the simple network composed of three routers located in three different ASes and shown in the figure below. 208/10000 · 208
63 ../../protocols/bgp.rst:271
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Utilization of the BGP nexthop attribute 40/10000 · 40
64 ../../protocols/bgp.rst:274
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This network contains three routers : `R1`, `R2` and `R3`. Each router is attached to a local IPv6 subnet that it advertises using BGP. There are two BGP sessions, one between `R1` and `R2` and the second between `R2` and `R3`. A `/127` subnet is used on each interdomain link (`2001:db8::4/127` on `R1-R2` and `2001:db8::0/127` on `R2-R3`) in conformance with the latest recommendation :rfc:`6164`. The BGP sessions run above TCP connections established between the neighboring routers (e.g. `2001:db8::5 - 2001:db8::6` for the `R1-R2` session). 546/10000 · 546
65 ../../protocols/bgp.rst:279
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us assume that the `R1-R2` BGP session is the first to be established. A `BGP Update` message sent on such a session contains three fields : 144/10000 · 144
66 ../../protocols/bgp.rst:281
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the advertised prefix 21/10000 · 21
67 ../../protocols/bgp.rst:282
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `BGP nexthop` 17/10000 · 17
68 ../../protocols/bgp.rst:283
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the attributes including the AS-Path 36/10000 · 36
69 ../../protocols/bgp.rst:285
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We use the notation `U(prefix, nexthop, attributes)` to represent such a `BGP Update` message in this section. Similarly, `W(prefix)` represents a `BGP withdraw` for the specified prefix. Once the `R1-R2` session has been established, `R1` sends `U(2001:db8:1234::/48,2001:db8::5,AS10)` to `R2` and `R2` sends `U(2001:db8:5678:/48,2001:db8::6,AS20)`. At this point, `R1` can reach `2001:db8:5678::/48` via `2001:db8::6` and `R2` can reach `2001:db8:1234::/48` via `2001:db8::5`. 478/10000 · 478
70 ../../protocols/bgp.rst:287
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the `R2-R3` has been established, `R3` sends `U(2001:db8:acbd::/48,2001:db8::2,AS30)`. `R2` announces on the `R2-R3` session all the routes inside its RIB. It thus sends to `R3` : `U(2001:db8:1234::/48,2001:db8::1,AS20:AS10)` and `U(2001:db8:5678::/48,2001:db8::1,AS20)`. Note that when `R2` advertises the route that it learned from `R1`, it updates the BGP nexthop and adds its AS number to the AS-Path. `R2` also sends `U(2001:db8:abcd::48,2001:db8::6,AS20:AS30)` to `R1` on the `R1-R3` session. At this point, all BGP routes have been exchanged and all routers can reach `2001:db8::1234/48`, `2001:db8:5678::/48` and `2001:db8:abcd::/48`. 647/10000 · 647
71 ../../protocols/bgp.rst:289
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — If the link between `R2` and `R3` fails, `R3` detects the failure as it did not receive `KEEPALIVE` messages recently from `R2`. At this time, `R3` removes from its RIB all the routes learned over the `R2-R3` BGP session. `R2` also removes from its RIB the routes learned from `R3`. `R2` also sends `W(2001:db8:acbd::/48)` to `R1` over the `R1-R3` BGP session since it does not have a route anymore towards this prefix. 420/10000 · 420
72 ../../protocols/bgp.rst:291
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Origin of the routes advertised by a BGP router 47/10000 · 47