Exit Zen
35
../../protocols/bgp.rst:118
English
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.
0/5440 · 544
36
../../protocols/bgp.rst:122
English
The BGP protocol :rfc:`4271` defines several types of messages that can be exchanged over a BGP session :
0/1050 · 105
37
../../protocols/bgp.rst:124
English
`OPEN` : this message is sent as soon as the TCP connection between the two routers has been established. It initializes the BGP session and allows the negotiation of some options. Details about this message may be found in :rfc:`4271`.
0/2360 · 236
38
../../protocols/bgp.rst:125
English
`NOTIFICATION` : this message is used to terminate a BGP session, usually because an error has been detected by the BGP peer. A router that sends or receives a `NOTIFICATION` message immediately shutdowns the corresponding BGP session.
0/2350 · 235
39
../../protocols/bgp.rst:126
English
`UPDATE`: this message is used to advertise new or modified routes or to withdraw previously advertised routes.
0/1110 · 111
40
../../protocols/bgp.rst:127
English
`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.
0/4850 · 485
41
../../protocols/bgp.rst:129
English
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 :
0/6020 · 602
42
../../protocols/bgp.rst:131
English
a list of IP prefixes that are withdrawn
0/400 · 40
43
../../protocols/bgp.rst:132
English
a list of IP prefixes that are (re-)advertised
0/460 · 46
44
../../protocols/bgp.rst:133
English
the set of attributes (e.g. AS-Path) associated to the advertised prefixes
0/740 · 74
45
../../protocols/bgp.rst:135
English
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 :
0/2220 · 222
46
../../protocols/bgp.rst:137
English
`Withdraw message` to indicate a BGP `UPDATE` message containing one route that is withdrawn
0/920 · 92
47
../../protocols/bgp.rst:138
English
`Update message` to indicate a BGP `UPDATE` containing a new or updated route towards one destination prefix with its attributes
0/1280 · 128
48
../../protocols/bgp.rst:143
English
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.
0/1520 · 152
49
../../protocols/bgp.rst:151
English
Organization of a BGP router
0/280 · 28
50
../../protocols/bgp.rst:159
English
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 :
0/2260 · 226
51
../../protocols/bgp.rst:161
English
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.
0/2360 · 236
52
../../protocols/bgp.rst:162
English
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.
0/2340 · 234
53
../../protocols/bgp.rst:163
English
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.
0/3910 · 391
54
../../protocols/bgp.rst:164
English
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.
0/3740 · 374