Configuring and Testing Border Gateway Protocol (BGP) on Basis of Cisco Hardware and Linux Gentoo with Quagga Package (Zebra)
Total Page:16
File Type:pdf, Size:1020Kb
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. 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-1265-1268,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. Its value should be between 19 and 4096. 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. 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 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: ● 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 65001 including the net 192.168.100.0/24 ● AS 65002 including networks 172.16.100.0/24; 172.16.102.0/24; 172.16.103.0/24 ● AS 65003 including the network 192.168.200.0/24 ● AS 65004 including the network 172.16.101.0/24 As routers 3 servers with Linux Gentoo OS were used and one Cisco 3640. The stand scheme is on the figure below: Figure 5. Stand scheme for testing BGP operability. 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 65003 neighbor 172.16.101.2 remote-as 65004 neighbor 172.16.102.1 remote-as 65002 network 192.168.200.0 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. ● If the routes are identical, then we select the nearest IGP neighbor.