Configuring and Testing Border Gateway Protocol (BGP) on Basis of Cisco Hardware and Linux Gentoo with Quagga Package (Zebra)

Transcription

1 Configuring and Testing Border Gateway Protocol (BGP) on Basis of Cisco Hardware and Linux Gentoo with Quagga Package (Zebra) Contents Introduction Used Abbreviations Border Gateway Protocol (BGP) Overview Testing Stand Description Setting Up a Cisco Router for Using BGP Setting Up and Configuring Quagga in Linux Gentoo Testing BGP Operability Conclusions References Introduction In the article mechanisms of functioning of the dynamic routing protocol "BGP" are examined in details. Guides for configuring Cisco routers and Quagga package on basis of Gentoo Linux are given. A stand in which coherence between networks is realized due to routes promoted via BGP was assembled. On this stand a reconnection to a reserve channel on failure of the primary line has been tested. BGP is the basic protocol on the Internet, and due to it ISPs in the whole world are available. One day any serious ISP faces the protocol configuring. We hope that the material, given in this article, will become a good help for technicians on configuring dynamic routing via BGP. Note! In this article fictive network addresses and autonomous system numbers are used. For using BGP in the real Internet it is required to register an autonomous system and a block of IP addresses. For that you may take an advantage of the service "Registration of IP Addresses and Autonomous Systems" offered by NetUP.

2 Used Abbreviations In the article the following abbreviations are used: AS - Autonomous System; BGP - Border Gateway Protocol; ebgp - Exterior BGP, routes exchange between autonomous systems via BGP; ibgp - Interior BGP, routes exchange inside autonomous systems via BGP; IGP - Interior Gateway Protocol; MED - Multi-exit discriminator, an attribute of a Cisco router, used when two autonomous systems are connected by several lines or via a set of routers; Border Gateway Protocol Overview Border Gateway Protocol (BGP, RFC ,1467,1655,1771,1772) was developed by companies IBM and CISCO. A pair of BGP neighbors establishes a connection via TCP, port 179. Neighbors that belong to different autonomous systems should be available for each other directly; for neighbors from the same AS there is no such restriction because the internal routing protocol provides all necessary routes between nodes of the autonomous system. BGP routers exchange messages on changing routes. The maximal length of such a message is 4096 octets, the minimal is 19 octets. Each message has a header of a fixed size. The volume of an information field depends on the message type. Figure 1. BGP message header format. Marker field has 16 octets and its contents can be easily interpreted by a recipient. Marker can be used for detecting losses of synchronization in work of BGP partners. Length field has two octets and defines total message length in octets including the header.

3 Its value should be between 19 and Type field is a message type code and can possess the following values: OPEN - connection start UPDATE - data update NOTIFICATION - notification KEEPALIVE - connection testing After the connection has been established on a transport protocol level, the first message that should be sent is OPEN. On successful passing of the message a partner should respond by sending the KEEPALIVE message. After that any messages are possible. Besides header, the message OPEN contains the following fields: Figure 2. OPEN message format. Version field indicates a version code of the protocol used; nowadays for BGP it equals 4. Two-octet field my autonomous system determines a sender AS code. Hold time field characterizes time (in seconds) that a sender suggests for being set in the hold timer (after an Open message has been accepted, the BGP router should select a hold time value usually less than it was received in the OPEN message and less than it was set on configuring of the system (0-3 sec); it specifies the maximal time in seconds between messages KEEPALIVE and UPDATE or between two UPDATE messages). To each unit within the bounds of BGP it is assigned a 4-octet identifier (BGP identifier), which is specified on installation and is identical for all local network interfaces.

4 Messages like UPDATE are used for transferring the routing data between BGP partners. This message type allows announcing a new route or closing a group of routes, this is possible within one message. Message UPDATE always contains a standard header and can contain other fields according to the scheme below: Figure 3. UPDATE message format. If cancelled routes list length equals zero, no route is cancelled, and the field cancelled routes is absent from the message. The field cancelled routes has a variable length and contains a list of prefixes of IP addresses of routes that have become unavailable; Equal to zero prefix length (in bits) means that the prefix corresponds to all IP addresses and is of a null size itself. The following attribute type codes are provided: ORIGIN (code 1) is a standard obligatory attribute that specifies an origin of routing data. It is generated by an autonomous system that is a source of routing data. AS_PATH (code 2), a standard obligatory attribute also, consists of a set of route segments. The attribute specifies autonomous systems via which the routing data is delivered. Each AS_PATH segment consists of three parts: path segment

5 type, path segment length, and path segment estimate. NEXT_HOP (code 3) is a standard and obligatory attribute; it specifies an IP address of a border router that should be considered as an objective of the next step on the way to a destination point. MULTI_EXIT_DISC (code 4) is an optional non-transient attribute that occupies 4 octets and is a positive integer. This attribute value can be used on selecting one of several ways to a neighbor autonomous system. LOCAL_PREF (code 5) is an optional attribute that occupies 4 octets. It is used by a BGP router for informing BGP partners in its autonomous system about a degree of preference of the route declared. ATOMIC_AGGREGATE (code 6) is a standard attribute used for informing partners about a route selection providing access to a broader list of addresses. AGGREGATOR (code 7) is an optional transient attribute of 6 octets length. The attribute contains the last code of the autonomous system that specifies an aggregate route (occupies two octets) and an IP address of the BGP router that have created the route (4 octets). Information about workability of the neighbor routers is got from KEEPALIVE messages that should be sent frequently enough to allow confine in time range allotted by the hold timer. Usually this time doesn't exceed one third of the hold time, but shouldn't be less than 1 second. If the selected value of the hold time equals zero then periodical sending of KEEPALIVE messages is not necessary. NOTIFICATION message is sent when an error occurs. The BGP connection at that immediately breaks. Besides the header, a NOTIFICATION message has the following fields: Figure 4. NOTIFICATION message format. Error code is a one-octet field denoting the message type. The following error codes are possible:

6 An error in the message header An error in the OPEN message An error in the UPDATE message Hold time elapsed Finite state machine error (mistiming) Interruption One-octet field error subcode provides additional error information. Each error code can have one or more subcodes. If the field contains zero then no subcode is defined. Testing Stand Description For testing an operability of BGP, NetUP specialists have built a testing stand including four autonomous systems: AS including the net /24 AS including networks /24; /24; /24 AS including the network /24 AS including the network /24 As routers 3 servers with Linux Gentoo OS were used and one Cisco The stand scheme is on the figure below:

7 Figure 5. Stand scheme for testing BGP operability.

8 Setting Up a Cisco Router for Using BGP Minimal configuration For a simple configuration of the Cisco router for working with BGP the following commands are used: router bgp neighbor remote-as neighbor remote-as network The command router bgp [AS] gives the router number of its autonomous system and includes exchange of BGP routes between autonomous systems. The command neighbor [ip-address] remote-as [AS] adds in the table of neighbor BGP routers a record with an IP address of the router and the number of the autonomous system it belongs to. The command network [ip-address] informs the router that the current network should be announced as available via the current router. Selection of an Optimal Route On selecting the best way to the destination network, in BGP several criteria are used; each of them can be configured manually. Route selecting algorithm consists of the following steps: For each record in the table of neighbor routers we check if the respective unit is accessible, and reject those which are inaccessible. Select the way with the greatest weight. If the weight is identical, select the route with the maximal value of the LOCAL_PREF parameter. If LOCAL_PREF values are identical and the route is initialized by an external (non-local) router, select the shortest AS_PATH. If lengths of AS_PATH are identical, select the least ORIGIN code. If codes of the ORIGIN attribute are equal, select the route with the least attribute MED value. If attributes MED are identical, then ebgp is more preferred than ibgp.

9 If the routes are identical, then we select the nearest IGP neighbor. If the distances are identical, then select a router with the least ID. Configuring Weight Attribute The attribute 'Weight' is a metrics and it allows the system administrator setting manually a certain weight to all routes information about has been received from BGP partners. The more Weight is, the better is the route. This metrics is especially useful when a router is connected to several autonomous systems. Weight remains a local parameter for the router it is configured at. When information about routes comes from many sources, the attribute is configured by using the command: neighbor <IP address> weight <weight> Allowable weight value lies in the range Default value is BGP Network Diagnostics After configuring BGP, a set of commands can be used for checking the configuration and diagnosing the network. These commands can be also used for studying BGP routing process: show ip bgp shows all information concerned with BGP configuration for a selected interface; show ip bgp neighbors outputs information about all configured BGP neighbors, provides detailed statistics relevant to each neighbor router; show ip bgp paths shows all routing information for a local router; show ip bgp summary displays status of all BGP connections. Example of using the command show ip bgp: Router#show ip bgp BGP table version is 67, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> / i

10 * i r / i r> i r> / i r i *> / i * i *> i * i Setting Up and Configuring Quagga in Linux Gentoo Setting Up Quagga Quagga is the software package realizing TCP/IP -based routing protocols. Such protocols as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4 and BGP-4+ are supported. In addition to the standard IPv4, Quagga also supports routing protocols for IPv6. Quagga allows realizing routing functions on a separate computer by exchanging routing information with neighbors and correcting the core routing table. You can dynamically change Quagga configuration and view current configuration information. For installing Quagga use the following command: emerge quagga The package includes a set of daemons for working with various routing protocols (ripd, bgpd, ospfd, etc.), and also the daemon zebra that is used for creation of the routing table and redistribution of routes between various protocols. Quagga configuration files are accessible in the directory /etc/quagga. Below are the configuration files for all three routers used in the testing stand. amalfi.netup server An example of zebra.conf: hostname amalfi

11 password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty An example of bgpd.conf: hostname amalfi_bgpd password zebra router bgp bgp router-id network /24 neighbor remote-as log stdout sat.netup server An example of zebra.conf: hostname sat password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty An example of bgpd.conf: hostname sat_bgpd password zebra router bgp 65004

12 bgp router-id network /24 neighbor remote-as neighbor remote-as log stdout streamer.netup server An example of zebra.conf: hostname streamer password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty no exec-timeout An example of bgpd.conf: hostname streamer_bgpd password zebra router bgp bgp router-id network /24 network /24 network /24 neighbor remote-as neighbor remote-as neighbor remote-as log stdout Starting Quagga

13 When the configuration is complete it's necessary to run the daemons by using the commands: /etc/init.d/zebra start /etc/init.d/bgpd start The daemons can be managed via the telnet protocol, similarly to managing the Cisco router. For that connect to the port 2601 (for zebra) or to the port 2605 (for bgpd) and enter the passwords specified in the configuration files. An example of running the command show ip route bgp on the router amalfi: amalfi# show ip route bgp Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route B>* /24 [20/0] via , eth0, 00:12:45 B>* /24 [20/0] via , eth0, 00:12:15 B>* /24 [20/0] via , eth0, 00:12:45 B>* /24 [20/0] via , eth0, 00:12:45 amalfi# exit The example shows that the router has successfully received via BGP a list of accessible autonomous systems. Testing BGP Operability Simple Routing Information Exchange Thus, on the stand we've got two independent routes from AS to AS 65001: AS > AS > AS AS > AS The first route is accessible via the interface Ethernet0/0: interface Ethernet0/0 ip address

14 The second route - via Ethernet0/1: interface Ethernet0/1 ip address Firstly both routes are operable, and according to the algorithm of route selecting (see above) it should be selected the second route ( > 65001). Let's check this using the command traceroute on the Cisco router: Router#traceroute Type escape sequence to abort. Tracing the route to msec 48 msec 0 msec [AS 65001] 0 msec 0 msec 4 msec Now let's disable the short route. For that disable the appropriate networking interface on the Cisco router: interface Ethernet0/1 shutdown After that all traffic to AS should go via the reserve channel. Let's check this by using the command traceroute: Router#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 0 msec [AS 65002] 0 msec 56 msec 0 msec [AS 65001] 4 msec 0 msec 4 msec After restoration of the primary channel it is necessary to wait for some time (around 5-10 seconds) before Cisco finds out that the connections has been restored. This is indicated by the following log:.jan 2 13:33:15.448: %BGP-5-ADJCHANGE: neighbor Up

15 As soon as the router detects the primary channel restoration, all traffic goes via this route that is shorter. Using «weights» of routes Sometimes using length of the route as the main selection criterion is not suitable. For example, you may have two Internet channels: a cheap primary channel, and an expensive reserve one, and at that the cheap channel is longer. What to do in this case? Setting route weights will help. Let's set a higher weight for the long route in order to make it being used as the primary one. For this the following commands should be used:! Enter BGP parameters edit mode router bgp 65003! Specify weights neighbor weight 200 neighbor weight 100 Now, in case when both channels are accessible, the router selects the longer route as it has the higher weight: Router#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 0 msec [AS 65002] 0 msec 56 msec 0 msec [AS 65001] 4 msec 0 msec 4 msec Limitations for importing and exporting of routes Very often it is necessary to restrict a list of routes obtained from a BGP unit. Indeed, any unit may declare that a certain subnet is accessible via it, at the same time not providing a real route to the mentioned network. This makes possible attack threats like «Denial of Service», spoofing and other attack types.

16 For protecting against these problems it is necessary to determine a degree of belief to each of the neighbor BGP units, and to limit accordingly a list of routes that will be obtained from such a unit. Other routes will be ignored. Limitation of autonomous system number are set by using access lists by using the parameter as-path: ip as-path access-list <identifier> permit <regular expression> Here a regular expression sets a template for applying the rule. For example, for restriction of the autonomous system the expression be ^65004$. Besides that, it is possible to add limitations for a subnet address by using the prefix-list parameter: ip prefix-list <name> seq <number> permit <subnet address> Where <name> is the name of address list, <number> is a serial number of a record in the list, <subnet address> is an address of the network and its mask. Now it is necessary to attach the lists to a certain BGP neighbor. The keyword in in settings means that filtration rules are applied to addresses declared from the current router. In case of the keyword out is set, the filters are applied to addresses sent by us to the current router. In the BGP parameters edit mode this can be done by the following commands:! For limitation of autonomous systems neighbor <unit address> filter-list <ID of the rule>! For limitation of the network prefix neighbor route-map <route-map name> in route-map <route-map name> permit 10 match ip address prefix-list <prefix-list name> Let's check how this example can be realized on our stand. For that on the router 'streamer.netup' let's limit subnets obtained from the router 'amalfi.netup'. Let's permit declaring only the network /24 and for more clearness configure amalfi.netup for declaring a new subnet /24 that is fictive. For that on streamer.netup we change the configuration file /etc/quagga/bgpd. conf in the following way:

17 router bgp bgp router-id network /24 network /24 network /24 neighbor remote-as neighbor route-map AMALFI in neighbor remote-as neighbor remote-as 65004! ip prefix-list AMALFI_IP_LIST seq 6 permit /24 route-map AMALFI permit 10 match ip address prefix-list AMALFI_IP_LIST On amalfi.netup in the configuration file /etc/quagga/bgpd.conf we add exporting of a fictive network /24: router bgp bgp router-id network /24 network /24 neighbor remote-as 65002

18 After applying the settings let's check which networks were declared from amalfi.netup. For that let's run the following commands on streamer.netup: streamer# show ip route bgp Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route B>* /24 [20/0] via , eth0, 00:02:20 B>* /24 [20/0] via , eth0, 00:02:24 As it was suspected the information about the fictive network /24 haven't passed into the routing data. At that information about the network /24 remained without changes and is available in the list of routes. Conclusions BGP perfectly fulfils routing management tasks in global networks such as the Internet. Testing has shown a prompt hardware reaction on connection losses, and also a very flexible configurability. Such a capability as filtration of sent and received routes allows using BGP as a tool for optimization of Internet traffic routes. According to this article it is very convenient to use BGP for... reserving the Internet channel. Switching between a primary and a reserve channel happens very quickly, that minimizes delays in rendering of services, and clients of an ISP will highly appreciate the quality of service. References Quagga project Web site RFC 1771, A Border Gateway Protocol 4 (BGP-4) Semyonov U.A. «Internet Protocols», chapter devoted to BGP

19 Todd Lammle, Sean Odom, with Kevin Wallace. «CCNP: Routing. Study Giude» SYBEX Inc.;