routeserver.texi 21 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550
  1. @c -*-texinfo-*-
  2. @c @value{COPYRIGHT_STR}
  3. @c See file quagga.texi for copying conditions.
  4. @c
  5. @c This file is a modified version of Jose Luis Rubio's TeX sources
  6. @c of his RS-Manual document
  7. @node Configuring Quagga as a Route Server
  8. @chapter Configuring Quagga as a Route Server
  9. The purpose of a Route Server is to centralize the peerings between BGP
  10. speakers. For example if we have an exchange point scenario with four BGP
  11. speakers, each of which maintaining a BGP peering with the other three
  12. we can convert it into a centralized scenario where
  13. each of the four establishes a single BGP peering against the Route Server.
  14. We will first describe briefly the Route Server model implemented by Quagga.
  15. We will explain the commands that have been added for configuring that
  16. model. And finally we will show a full example of Quagga configured as Route
  17. Server.
  18. @menu
  19. * Description of the Route Server model::
  20. * Commands for configuring a Route Server::
  21. * Example of Route Server Configuration::
  22. @end menu
  23. @node Description of the Route Server model
  24. @section Description of the Route Server model
  25. First we are going to describe the normal processing that BGP announcements
  26. suffer inside a standard BGP speaker, as shown in @ref{fig:normal-processing},
  27. it consists of three steps:
  28. @itemize @bullet
  29. @item
  30. When an announcement is received from some peer, the `In' filters
  31. configured for that peer are applied to the announcement. These filters can
  32. reject the announcement, accept it unmodified, or accept it with some of its
  33. attributes modified.
  34. @item
  35. The announcements that pass the `In' filters go into the
  36. Best Path Selection process, where they are compared to other
  37. announcements referred to the same destination that have been
  38. received from different peers (in case such other
  39. announcements exist). For each different destination, the announcement
  40. which is selected as the best is inserted into the BGP speaker's Loc-RIB.
  41. @item
  42. The routes which are inserted in the Loc-RIB are
  43. considered for announcement to all the peers (except the one
  44. from which the route came). This is done by passing the routes
  45. in the Loc-RIB through the `Out' filters corresponding to each
  46. peer. These filters can reject the route,
  47. accept it unmodified, or accept it with some of its attributes
  48. modified. Those routes which are accepted by the `Out' filters
  49. of a peer are announced to that peer.
  50. @end itemize
  51. @float Figure,fig:normal-processing
  52. @center @image{fig-normal-processing,400pt,,Normal announcement processing}
  53. @caption{Announcement processing inside a ``normal'' BGP speaker}
  54. @end float
  55. Of course we want that the routing tables obtained in each of the routers
  56. are the same when using the route server than when not. But as a consequence
  57. of having a single BGP peering (against the route server), the BGP speakers
  58. can no longer distinguish from/to which peer each announce comes/goes.
  59. @anchor{filter-delegation}This means that the routers connected to the route
  60. server are not able to apply by themselves the same input/output filters
  61. as in the full mesh scenario, so they have to delegate those functions to
  62. the route server.
  63. Even more, the ``best path'' selection must be also performed inside
  64. the route server on behalf of its clients. The reason is that if, after
  65. applying the filters of the announcer and the (potential) receiver, the
  66. route server decides to send to some client two or more different
  67. announcements referred to the same destination, the client will only
  68. retain the last one, considering it as an implicit withdrawal of the
  69. previous announcements for the same destination. This is the expected
  70. behavior of a BGP speaker as defined in @cite{RFC1771}, and even though
  71. there are some proposals of mechanisms that permit multiple paths for
  72. the same destination to be sent through a single BGP peering, none are
  73. currently supported by most existing BGP implementations.
  74. As a consequence a route server must maintain additional information and
  75. perform additional tasks for a RS-client that those necessary for common BGP
  76. peerings. Essentially a route server must:
  77. @anchor{Route Server tasks}
  78. @itemize @bullet
  79. @item
  80. Maintain a separated Routing Information Base (Loc-RIB)
  81. for each peer configured as RS-client, containing the routes
  82. selected as a result of the ``Best Path Selection'' process
  83. that is performed on behalf of that RS-client.
  84. @item
  85. Whenever it receives an announcement from a RS-client,
  86. it must consider it for the Loc-RIBs of the other RS-clients.
  87. @anchor{Route-server path filter process}
  88. @itemize @bullet
  89. @item
  90. This means that for each of them the route server must pass the
  91. announcement through the appropriate `Out' filter of the
  92. announcer.
  93. @item
  94. Then through the appropriate `In' filter of
  95. the potential receiver.
  96. @item
  97. Only if the announcement is accepted by both filters it will be passed
  98. to the ``Best Path Selection'' process.
  99. @item
  100. Finally, it might go into the Loc-RIB of the receiver.
  101. @end itemize
  102. @end itemize
  103. When we talk about the ``appropriate'' filter, both the announcer and the
  104. receiver of the route must be taken into account. Suppose that the route
  105. server receives an announcement from client A, and the route server is
  106. considering it for the Loc-RIB of client B. The filters that should be
  107. applied are the same that would be used in the full mesh scenario, i.e.,
  108. first the `Out' filter of router A for announcements going to router B, and
  109. then the `In' filter of router B for announcements coming from router A.
  110. We call ``Export Policy'' of a RS-client to the set of `Out' filters that
  111. the client would use if there was no route server. The same applies for the
  112. ``Import Policy'' of a RS-client and the set of `In' filters of the client
  113. if there was no route server.
  114. It is also common to demand from a route server that it does not
  115. modify some BGP attributes (next-hop, as-path and MED) that are usually
  116. modified by standard BGP speakers before announcing a route.
  117. The announcement processing model implemented by Quagga is shown in
  118. @ref{fig:rs-processing}. The figure shows a mixture of RS-clients (B, C and D)
  119. with normal BGP peers (A). There are some details that worth additional
  120. comments:
  121. @itemize @bullet
  122. @item
  123. Announcements coming from a normal BGP peer are also
  124. considered for the Loc-RIBs of all the RS-clients. But
  125. logically they do not pass through any export policy.
  126. @item
  127. Those peers that are configured as RS-clients do not
  128. receive any announce from the `Main' Loc-RIB.
  129. @item
  130. Apart from import and export policies,
  131. `In' and `Out' filters can also be set for RS-clients. `In'
  132. filters might be useful when the route server has also normal
  133. BGP peers. On the other hand, `Out' filters for RS-clients are
  134. probably unnecessary, but we decided not to remove them as
  135. they do not hurt anybody (they can always be left empty).
  136. @end itemize
  137. @float Figure,fig:rs-processing
  138. @center @image{fig-rs-processing,430pt,,Route Server Processing Model}
  139. @caption{Announcement processing model implemented by the Route Server}
  140. @end float
  141. @node Commands for configuring a Route Server
  142. @section Commands for configuring a Route Server
  143. Now we will describe the commands that have been added to quagga
  144. in order to support the route server features.
  145. @deffn {Route-Server} {neighbor @var{peer-group} route-server-client} {}
  146. @deffnx {Route-Server} {neighbor @var{A.B.C.D} route-server-client} {}
  147. @deffnx {Route-Server} {neighbor @var{X:X::X:X} route-server-client} {}
  148. This command configures the peer given by @var{peer}, @var{A.B.C.D} or
  149. @var{X:X::X:X} as an RS-client.
  150. Actually this command is not new, it already existed in standard Quagga. It
  151. enables the transparent mode for the specified peer. This means that some
  152. BGP attributes (as-path, next-hop and MED) of the routes announced to that
  153. peer are not modified.
  154. With the route server patch, this command, apart from setting the
  155. transparent mode, creates a new Loc-RIB dedicated to the specified peer
  156. (those named `Loc-RIB for X' in @ref{fig:rs-processing}.). Starting from
  157. that moment, every announcement received by the route server will be also
  158. considered for the new Loc-RIB.
  159. @end deffn
  160. @deffn {Route-Server} {neigbor @{A.B.C.D|X.X::X.X|peer-group@} route-map WORD @{import|export@}} {}
  161. This set of commands can be used to specify the route-map that
  162. represents the Import or Export policy of a peer which is
  163. configured as a RS-client (with the previous command).
  164. @end deffn
  165. @deffn {Route-Server} {match peer @{A.B.C.D|X:X::X:X@}} {}
  166. This is a new @emph{match} statement for use in route-maps, enabling them to
  167. describe import/export policies. As we said before, an import/export policy
  168. represents a set of input/output filters of the RS-client. This statement
  169. makes possible that a single route-map represents the full set of filters
  170. that a BGP speaker would use for its different peers in a non-RS scenario.
  171. The @emph{match peer} statement has different semantics whether it is used
  172. inside an import or an export route-map. In the first case the statement
  173. matches if the address of the peer who sends the announce is the same that
  174. the address specified by @{A.B.C.D|X:X::X:X@}. For export route-maps it
  175. matches when @{A.B.C.D|X:X::X:X@} is the address of the RS-Client into whose
  176. Loc-RIB the announce is going to be inserted (how the same export policy is
  177. applied before different Loc-RIBs is shown in @ref{fig:rs-processing}.).
  178. @end deffn
  179. @deffn {Route-map Command} {call @var{WORD}} {}
  180. This command (also used inside a route-map) jumps into a different
  181. route-map, whose name is specified by @var{WORD}. When the called
  182. route-map finishes, depending on its result the original route-map
  183. continues or not. Apart from being useful for making import/export
  184. route-maps easier to write, this command can also be used inside
  185. any normal (in or out) route-map.
  186. @end deffn
  187. @node Example of Route Server Configuration
  188. @section Example of Route Server Configuration
  189. Finally we are going to show how to configure a Quagga daemon to act as a
  190. Route Server. For this purpose we are going to present a scenario without
  191. route server, and then we will show how to use the configurations of the BGP
  192. routers to generate the configuration of the route server.
  193. All the configuration files shown in this section have been taken
  194. from scenarios which were tested using the VNUML tool
  195. @uref{http://www.dit.upm.es/vnuml,VNUML}.
  196. @menu
  197. * Configuration of the BGP routers without Route Server::
  198. * Configuration of the BGP routers with Route Server::
  199. * Configuration of the Route Server itself::
  200. * Further considerations about Import and Export route-maps::
  201. @end menu
  202. @node Configuration of the BGP routers without Route Server
  203. @subsection Configuration of the BGP routers without Route Server
  204. We will suppose that our initial scenario is an exchange point with three
  205. BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates
  206. some routes (with the @var{network} command), and establishes BGP peerings
  207. against the other two routers. These peerings have In and Out route-maps
  208. configured, named like ``PEER-X-IN'' or ``PEER-X-OUT''. For example the
  209. configuration file for router RA could be the following:
  210. @exampleindent 0
  211. @example
  212. #Configuration for router 'RA'
  213. !
  214. hostname RA
  215. password ****
  216. !
  217. router bgp 65001
  218. no bgp default ipv4-unicast
  219. neighbor 2001:0DB8::B remote-as 65002
  220. neighbor 2001:0DB8::C remote-as 65003
  221. !
  222. address-family ipv6
  223. network 2001:0DB8:AAAA:1::/64
  224. network 2001:0DB8:AAAA:2::/64
  225. network 2001:0DB8:0000:1::/64
  226. network 2001:0DB8:0000:2::/64
  227. neighbor 2001:0DB8::B activate
  228. neighbor 2001:0DB8::B soft-reconfiguration inbound
  229. neighbor 2001:0DB8::B route-map PEER-B-IN in
  230. neighbor 2001:0DB8::B route-map PEER-B-OUT out
  231. neighbor 2001:0DB8::C activate
  232. neighbor 2001:0DB8::C soft-reconfiguration inbound
  233. neighbor 2001:0DB8::C route-map PEER-C-IN in
  234. neighbor 2001:0DB8::C route-map PEER-C-OUT out
  235. exit-address-family
  236. !
  237. ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
  238. ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
  239. !
  240. ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
  241. ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
  242. !
  243. ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
  244. ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
  245. !
  246. ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
  247. ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
  248. !
  249. route-map PEER-B-IN permit 10
  250. match ipv6 address prefix-list COMMON-PREFIXES
  251. set metric 100
  252. route-map PEER-B-IN permit 20
  253. match ipv6 address prefix-list PEER-B-PREFIXES
  254. set community 65001:11111
  255. !
  256. route-map PEER-C-IN permit 10
  257. match ipv6 address prefix-list COMMON-PREFIXES
  258. set metric 200
  259. route-map PEER-C-IN permit 20
  260. match ipv6 address prefix-list PEER-C-PREFIXES
  261. set community 65001:22222
  262. !
  263. route-map PEER-B-OUT permit 10
  264. match ipv6 address prefix-list PEER-A-PREFIXES
  265. !
  266. route-map PEER-C-OUT permit 10
  267. match ipv6 address prefix-list PEER-A-PREFIXES
  268. !
  269. line vty
  270. !
  271. @end example
  272. @node Configuration of the BGP routers with Route Server
  273. @subsection Configuration of the BGP routers with Route Server
  274. To convert the initial scenario into one with route server, first we must
  275. modify the configuration of routers RA, RB and RC. Now they must not peer
  276. between them, but only with the route server. For example, RA's
  277. configuration would turn into:
  278. @example
  279. # Configuration for router 'RA'
  280. !
  281. hostname RA
  282. password ****
  283. !
  284. router bgp 65001
  285. no bgp default ipv4-unicast
  286. neighbor 2001:0DB8::FFFF remote-as 65000
  287. !
  288. address-family ipv6
  289. network 2001:0DB8:AAAA:1::/64
  290. network 2001:0DB8:AAAA:2::/64
  291. network 2001:0DB8:0000:1::/64
  292. network 2001:0DB8:0000:2::/64
  293. neighbor 2001:0DB8::FFFF activate
  294. neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
  295. exit-address-family
  296. !
  297. line vty
  298. !
  299. @end example
  300. Which is logically much simpler than its initial configuration, as it now
  301. maintains only one BGP peering and all the filters (route-maps) have
  302. disappeared.
  303. @node Configuration of the Route Server itself
  304. @subsection Configuration of the Route Server itself
  305. As we said when we described the functions of a route server
  306. (@pxref{Description of the Route Server model}), it is in charge of all the
  307. route filtering. To achieve that, the In and Out filters from the RA, RB and
  308. RC configurations must be converted into Import and Export policies in the
  309. route server.
  310. This is a fragment of the route server configuration (we only show
  311. the policies for client RA):
  312. @example
  313. # Configuration for Route Server ('RS')
  314. !
  315. hostname RS
  316. password ix
  317. !
  318. bgp multiple-instance
  319. !
  320. router bgp 65000 view RS
  321. no bgp default ipv4-unicast
  322. neighbor 2001:0DB8::A remote-as 65001
  323. neighbor 2001:0DB8::B remote-as 65002
  324. neighbor 2001:0DB8::C remote-as 65003
  325. !
  326. address-family ipv6
  327. neighbor 2001:0DB8::A activate
  328. neighbor 2001:0DB8::A route-server-client
  329. neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
  330. neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export
  331. neighbor 2001:0DB8::A soft-reconfiguration inbound
  332. neighbor 2001:0DB8::B activate
  333. neighbor 2001:0DB8::B route-server-client
  334. neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import
  335. neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export
  336. neighbor 2001:0DB8::B soft-reconfiguration inbound
  337. neighbor 2001:0DB8::C activate
  338. neighbor 2001:0DB8::C route-server-client
  339. neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import
  340. neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export
  341. neighbor 2001:0DB8::C soft-reconfiguration inbound
  342. exit-address-family
  343. !
  344. ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64
  345. ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
  346. !
  347. ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
  348. ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
  349. !
  350. ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
  351. ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
  352. !
  353. ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
  354. ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
  355. !
  356. route-map RSCLIENT-A-IMPORT permit 10
  357. match peer 2001:0DB8::B
  358. call A-IMPORT-FROM-B
  359. route-map RSCLIENT-A-IMPORT permit 20
  360. match peer 2001:0DB8::C
  361. call A-IMPORT-FROM-C
  362. !
  363. route-map A-IMPORT-FROM-B permit 10
  364. match ipv6 address prefix-list COMMON-PREFIXES
  365. set metric 100
  366. route-map A-IMPORT-FROM-B permit 20
  367. match ipv6 address prefix-list PEER-B-PREFIXES
  368. set community 65001:11111
  369. !
  370. route-map A-IMPORT-FROM-C permit 10
  371. match ipv6 address prefix-list COMMON-PREFIXES
  372. set metric 200
  373. route-map A-IMPORT-FROM-C permit 20
  374. match ipv6 address prefix-list PEER-C-PREFIXES
  375. set community 65001:22222
  376. !
  377. route-map RSCLIENT-A-EXPORT permit 10
  378. match peer 2001:0DB8::B
  379. match ipv6 address prefix-list PEER-A-PREFIXES
  380. route-map RSCLIENT-A-EXPORT permit 20
  381. match peer 2001:0DB8::C
  382. match ipv6 address prefix-list PEER-A-PREFIXES
  383. !
  384. ...
  385. ...
  386. ...
  387. @end example
  388. If you compare the initial configuration of RA with the route server
  389. configuration above, you can see how easy it is to generate the Import and
  390. Export policies for RA from the In and Out route-maps of RA's original
  391. configuration.
  392. When there was no route server, RA maintained two peerings, one with RB and
  393. another with RC. Each of this peerings had an In route-map configured. To
  394. build the Import route-map for client RA in the route server, simply add
  395. route-map entries following this scheme:
  396. @example
  397. route-map <NAME> permit 10
  398. match peer <Peer Address>
  399. call <In Route-Map for this Peer>
  400. route-map <NAME> permit 20
  401. match peer <Another Peer Address>
  402. call <In Route-Map for this Peer>
  403. @end example
  404. This is exactly the process that has been followed to generate the route-map
  405. RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B
  406. and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the
  407. original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is
  408. different.
  409. The same could have been done to create the Export policy for RA (route-map
  410. RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so
  411. simple that we decided not to use the @var{call WORD} commands, and we
  412. integrated all in a single route-map (RSCLIENT-A-EXPORT).
  413. The Import and Export policies for RB and RC are not shown, but
  414. the process would be identical.
  415. @node Further considerations about Import and Export route-maps
  416. @subsection Further considerations about Import and Export route-maps
  417. The current version of the route server patch only allows to specify a
  418. route-map for import and export policies, while in a standard BGP speaker
  419. apart from route-maps there are other tools for performing input and output
  420. filtering (access-lists, community-lists, ...). But this does not represent
  421. any limitation, as all kinds of filters can be included in import/export
  422. route-maps. For example suppose that in the non-route-server scenario peer
  423. RA had the following filters configured for input from peer B:
  424. @example
  425. neighbor 2001:0DB8::B prefix-list LIST-1 in
  426. neighbor 2001:0DB8::B filter-list LIST-2 in
  427. neighbor 2001:0DB8::B route-map PEER-B-IN in
  428. ...
  429. ...
  430. route-map PEER-B-IN permit 10
  431. match ipv6 address prefix-list COMMON-PREFIXES
  432. set local-preference 100
  433. route-map PEER-B-IN permit 20
  434. match ipv6 address prefix-list PEER-B-PREFIXES
  435. set community 65001:11111
  436. @end example
  437. It is posible to write a single route-map which is equivalent to
  438. the three filters (the community-list, the prefix-list and the
  439. route-map). That route-map can then be used inside the Import
  440. policy in the route server. Lets see how to do it:
  441. @example
  442. neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
  443. ...
  444. !
  445. ...
  446. route-map RSCLIENT-A-IMPORT permit 10
  447. match peer 2001:0DB8::B
  448. call A-IMPORT-FROM-B
  449. ...
  450. ...
  451. !
  452. route-map A-IMPORT-FROM-B permit 1
  453. match ipv6 address prefix-list LIST-1
  454. match as-path LIST-2
  455. on-match goto 10
  456. route-map A-IMPORT-FROM-B deny 2
  457. route-map A-IMPORT-FROM-B permit 10
  458. match ipv6 address prefix-list COMMON-PREFIXES
  459. set local-preference 100
  460. route-map A-IMPORT-FROM-B permit 20
  461. match ipv6 address prefix-list PEER-B-PREFIXES
  462. set community 65001:11111
  463. !
  464. ...
  465. ...
  466. @end example
  467. The route-map A-IMPORT-FROM-B is equivalent to the three filters
  468. (LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map
  469. A-IMPORT-FROM-B (sequence number 1) matches if and only if both
  470. the prefix-list LIST-1 and the filter-list LIST-2 match. If that
  471. happens, due to the ``on-match goto 10'' statement the next
  472. route-map entry to be processed will be number 10, and as of that
  473. point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If
  474. the first entry does not match, `on-match goto 10'' will be
  475. ignored and the next processed entry will be number 2, which will
  476. deny the route.
  477. Thus, the result is the same that with the three original filters,
  478. i.e., if either LIST-1 or LIST-2 rejects the route, it does not
  479. reach the route-map PEER-B-IN. In case both LIST-1 and LIST-2
  480. accept the route, it passes to PEER-B-IN, which can reject, accept
  481. or modify the route.