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

40 ../../protocols/bgp.rst:127
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `KEEPALIVE` : this message is used to ensure a regular exchange of messages on the BGP session, even when no route changes. When a BGP router has not sent an `UPDATE` message during the last 30 seconds, it shall send a `KEEPALIVE` message to confirm to the other peer that it is still up. If a peer does not receive any BGP message during a period of 90 seconds [#fdefaultkeepalive]_, the BGP session is considered to be down and all the routes learned over this session are withdrawn. 485/10000 · 485
41 ../../protocols/bgp.rst:129
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As explained earlier, BGP relies on incremental updates. This implies that when a BGP session starts, each router first sends BGP `UPDATE` messages to advertise to the other peer all the exportable routes that it knows. Once all these routes have been advertised, the BGP router only sends BGP `UPDATE` messages about a prefix if the route is new, one of its attributes has changed or the route became unreachable and must be withdrawn. The BGP `UPDATE` message allows BGP routers to efficiently exchange such information while minimizing the number of bytes exchanged. Each `UPDATE` message contains : 602/10000 · 602
42 ../../protocols/bgp.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a list of IP prefixes that are withdrawn 40/10000 · 40
43 ../../protocols/bgp.rst:132
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a list of IP prefixes that are (re-)advertised 46/10000 · 46
44 ../../protocols/bgp.rst:133
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the set of attributes (e.g. AS-Path) associated to the advertised prefixes 74/10000 · 74
45 ../../protocols/bgp.rst:135
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the remainder of this chapter, and although all routing information is exchanged using BGP `UPDATE` messages, we assume for simplicity that a BGP message contains only information about one prefix and we use the words : 222/10000 · 222
46 ../../protocols/bgp.rst:137
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Withdraw message` to indicate a BGP `UPDATE` message containing one route that is withdrawn 92/10000 · 92
47 ../../protocols/bgp.rst:138
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Update message` to indicate a BGP `UPDATE` containing a new or updated route towards one destination prefix with its attributes 128/10000 · 128
48 ../../protocols/bgp.rst:143
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a conceptual point of view, a BGP router connected to `N` BGP peers, can be described as being composed of four parts as shown in the figure below. 152/10000 · 152
49 ../../protocols/bgp.rst:151
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Organization of a BGP router 28/10000 · 28
50 ../../protocols/bgp.rst:159
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this figure, the router receives BGP messages on the left part of the figure, processes these messages and possibly sends BGP messages on the right part of the figure. A BGP router contains three important data structures : 226/10000 · 226
51 ../../protocols/bgp.rst:161
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Adj-RIB-In` contains the BGP routes that have been received from each BGP peer. The routes in the `Adj-RIB-In` are filtered by the `import filter` before being placed in the `BGP-Loc-RIB`. There is one `import filter` per BGP peer. 236/10000 · 236
52 ../../protocols/bgp.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Local Routing Information Base` (`Loc-RIB`) contains all the routes that are considered as acceptable by the router. The `Loc-RIB` may contain several routes, learned from different BGP peers, towards the same destination prefix. 234/10000 · 234
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