3. Topology The topology we will be using is: We have a number of separate ASs, each containing one router, and another AS (200) containing four routers, which we will use when we look at iBGP. It is far from a complex topology, but will enable us to cover all that we need to learn. A larger picture is available at http://1.802101.com/802books With that said, let’s start creating our first peers.4. eBGP Peering As we have already discussed BGP connects autonomous systems (AS) together, and this is where we are going to jump right in, by setting up a BGP neighbor relationship between two ASs. Once we have finished out first practical example we will then look into how the relationships form, and at the message types used with BGP messages. 4.1 Differences between iBGP and eBGP Before we start configuring our first peering lets have a quick look at the differences between iBGP and eBGP peers. Other than the fact that one connects routers within one AS and the other connects two different ASs together, what, if any, are the other differences are there between iBGP and eBGP? The differences are in what attributes are taken into consideration when deciding on how that information effects our routing tables.We will cover the different BGP attributes in greater depth later on, but for the moment we should know that Local Preference is used by iBGP only, whereas AS_PATH is used by eBGP only. eBGP peers will change the NEXT_HOP attribute, whereas iBGP will not (and this will be important later on). TTLs are also handled differently, with eBGP the TTL is set to 1, with iBGP the TTL is able to go to the maximum of 255. BGP offers loop prevention between ASs based on the AS_ PATH attribute, because this is not used within iBGPs loop prevention must rely on the split horizon rule; that a route learned via iBGP will not be advertised to another iBGP speaker, unless it’s learned through an IGP, this would indicate that all iBGP speakers should be be ina full mesh, which sometimes is not convenient for the network in question, but we can use confederations and route reflectors (both covered later) to overcome this. So let’s kick off by setting up a neighbor relationship between Ri in AS 100 and R2 in AS 200, which will be our first eBGP relationship. I have shut down the so/o interface on R2 in order that when we are ready we can turn on the interface, and hopefully capture some good traffic. 4.2 Basic eBGP Peers With any BGP relationship, whether it beexternal or internal, we start with the command “router bgp” followed by an AS number: Rl#conf t Rl (config) #router bgp ? <1-65535> Autonomous system number Rl (config) #router bgp 100 Rl (config-router) # Once we have entered our command and AS number we are taken into the routing protocol sub-prompt. It is here that we start to define who, and how, we are connecting to. From the config-router command prompt we type in “neighbor” followed by the IP address of the neighbor we wish to peer to. It’s important (to point out the obvious) that we must already have connectivity to this neighbor for the relationship to form. Before we press enter we must also specify which AS they are in using the command “remote-as”, this command is the same whether we are configuring an eBGP. relationship or an iBGP relationship. The commands we will use are therefore: R1 (config-router) #neighbor 10.1.1.2 remo te-as 200 The full command sequence for Ri would be: Rl (config) #router bgp 100 Rl (config-router) #neighbor 10.1.1.2 remo te-as 200The commands we need to enter on R2 are very similar, and once entered we will see our neighbor relationship form when we get the neighbor up message: R2#conf t R2 (config) #router bgp 200 R2(config-router) #neighbor 10.1.1.1 remo te-as 100 R2(config-router) # *Mar 1 01:31:01.311: %BGP-5-ADJCHANGE: n eighbor 10.1.1.1 Up R2 (config-router) #exit So there we have how to create a BGP relationship in a few lines. We can confirm that Riand R2 are neighbors using the “sh ip bgp neighbors” command and below is some of the output from this: Rl#sh ip bgp neighbors BGP neighbor is 10.1.1.2, remote As 200, external Link BGP version 4, remote router ID 172.17 0.1 BGP state = Established, up for 00:00: 52 Last read 00:00:21, last write 00:00:2 1, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and receiv ed(old & new) Address family IPv4 Unicast: adverti sed and received Message statistics: InQ depth is 0 OutQ depth is 0 Sent RevdOpens: 1 1 Notifications: 0 0 Updates: 0 0 Keepalives: 2 2 Route Refresh: 0 0 Total: 3 3 Default minimum time between advertise ment runs is 30 seconds Connection state is ESTAB, I/O status: 1 , unread input bytes: 0 Connection is ECN Disabled, Minimum inco ming TTL 0, Outgoing TTL 1 Local host: 10.1.1.1, Local port: 29372 Foreign host: 10.1.1.2, Foreign port: 17 9 We can see the following useful information, firstly that the relationship is an external one, and secondly that the router ID advertised by R2 is 172.17.0.1, our BGP state is established, and has been for a little under a minute. In that time we have sent two keepalive messages, which we will cover in 4.6. Lastly we can see that the connection is using port 179 on R2 and 29372 on R1, indicating that R2 is the active peer of the relationship. Before we move on to the mechanics of how connections are formed it needs to be pointed out that if the router receives a connection request on port 179 from a source address not explicitly listed in its configuration (by using the neighbor command) then the request will be ignored, we'll be needing this later on.4.3 BGP peer formation and neighbor states Before I set up the BGP connection on R2 I shut down the interface connecting it to R1 so that when ready we can turn on the interface and capture the traffic. There a number of ways to accomplish this. If we are using GNS3 then we can right click on the link between the two routers and select “Start Capturing”, alternatively we can use IOS and issue the command “debug bgp all”. From the IOS debug output we get the following: *Mar 1 01:31:01.287: BGP: 10.1.1.2 passi ve open to 10.1.1.1 *Mar 1 01:31:01.291: BGP: 10.1.1.2 went from Active to Idle *Mar 1 01:31:01.291: BGP: 10.1.1.2 went from Idle to Connect *Mar 1 01:31:01.299: BGP: 10.1.1.2 rcv m essage type 1, length (excl. header) 26 *Mar 1 01:31:01.299: BGP: 10.1.1.2 rev O PEN, version 4, holdtime 180 seconds *Mar 1 01:31:01.299: BGP: 10.1.1.2 went from Connect to OpenSent *Mar 1 01:31:01.303: BGP: 10.1.1.2 sendi ng OPEN, version 4, my as: 100, holdtime 180 seconds *Mar 1 01:31:01.303: BGP: 10.1.1.2 rcv 0 PEN w/ OPTION parameter len: 16 *Mar 1 01:31:01.303: BGP: 10.1.1.2 rcevd OPEN w/ optional parameter type 2 (Capab ility) len 6 *Mar 1 01:31:01.303: BGP: 10.1.1.2 OPENhas CAPABILITY code: 1, length 4 *Mar 1 01:31:01.303: BGP: 10.1.1.2 OPEN has MP_EXT CAP for afi/safi: 1/1 *Mar 1 01:31:01.303: BGP: 10.1.1.2 rcevd OPEN w/ optional parameter type 2 (Capab ility) len 2 *Mar 1 01:31:01.30. has CAPABILITY cod 128, length 0 *Mar 1 01:31:01.303: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability(old) for al 1 address-families *Mar 1 01:31:01.303: BGP: 10.1.1.2 revd OPEN w/ optional parameter type 2 (Capab ility) len 2 *Mar 1 01:31:01.303: BGP: 10.1.1.2 OPEN has CAPABILITY cod 2, length 0 *Mar 1 01:31:01.303: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability(new) for al 1 address-families BGP: 10.1.1.2 rcvd OPEN w/ remote AS 200 *Mar 1 01:31:01.303: BGP: 10.1.1.2 went from OpenSent to Openconfirm *Mar 1 01:31:01.303: BGP: 10.1.1.2 send message type 1, length (incl. header) 45 *Mar 1 01:31:01.311: BGP: 10.1.1.2 went from Openconfirm to Established *Mar 1 01:31:01.315: %BGP-5-ADJCHANGE: n eighbor 10.1.1.2 Up BGP: 10.1.1.2 OPEN We can see that the router goes through a number of states, from an initial Active it goes to Idle, from there it goes to Connect. From Connect it goes to OpenSent, and then to OpenConfirm, before finally becoming Established. These states are known as the BGP Finite-State Machine. Idle is the initial state when the routing process is enabled, or when the device is reset. Thedevice waits to receive a connection request from a remote peer, this is shown as the passive open message in the output above. Once we get the connection request we then move to the Connect state where the BGP process detects that a peer is attempting to connect and set up a TCP session. The router then tries to establish the TCP session with a peer. If the session is successful we then go into the OpenSent state where the connection is established and an OPEN message is sent. Hopefully we should hear back from the remote peer, at which stage we would then move to the OpenConfirm state, where once we receive the OPEN message from the remote peer we then wait for an initial keepalive message to be received. Once received we transition to the Established state, at which point we can safely say that peering is now fully operational. Both routers will try and initiate the connection process, but once the OPEN process is completed. the routers will see that there is no need for both sessions to run in order to create the peering, so one session will be terminated. It is the router with the highest ID whose session will remain active. These are not the only messages sent by the peers. Once the relationship is in the Established state the peers exchange keepalives to make sure that the remote peer is still available, the keepalive messages are sent, by default every 60seconds, and if no reply is heard within the holdtime (default 180 seconds) the router declares the peer to be dead. The other messages used are Update and Notification messages. Before we go through these though we need to revisit our topology and make a slight modification. 4.4 Router IDs Having a router id is a requirement of BGP. If you do not set one yourself using the command “bgp router-id ” (such as “bgp router- id 1.1.1.1”) then the router will select one for you, the router will first try to use the highest IP address of any loopback interface, and if none are found, then the highest IP address of any physical interface. If you do not have any IP addresses configured and try to configure a BGP routing process you will get the following message: Router (config) #router bgp 100 Router (config-router) # *Jan 1 15:40:48.862: %BGP-4-NORTRID: BGP could not pick a router-id. Please conf igure manually. Router (config-router) # During this book I will be using the same format for all of the BGP router IDs, which will be therouter number four times, separated by dots (like an IP address), so R1 (router 1) would be 1.1.1.1, R2 will be 2.2.2.2, and so on. If the router-id is not explicitly shown during initial configuration examples, please assume that it has been done, we don’t want to reply on pot luck, we should control this. We need to enter the bgp process again using the “router bgp ” command, then specify a router id using the command “bgp router-id ”: Rl (config) #router bgp 100 Rl (config-router) #bgp router-id 1.1.1.1 Rl (config-router) # *Mar 1 00:09:44.791: %BGP-5-ADJCHANGE: n eighbor 10.1.1.2 Down Router ID changed R1 (config-router) # *Mar 1 00:09:47.639: %BGP-5-ADJCHANGE: n eighbor 10.1.1.2 Up R1 (config-router) # R2(config) #router bgp 200 R2(config-router) #bgp router-id 2.2.2.2 R2(config-router) # *Mar 1 00:10:07.955: *BGP-S-ADJCHANGE: n eighbor 10.1.1.1 Down Router ID changed R2 (config-router) # *Mar 1 00:10:09.603: %BGP-5-ADJCHANGE: n eighbor 10.1.1.1 Up R2 (config-router) # We can see our neighbor relationship come down, and get re-established, and now if we look at the bgp neighbor details on Ri we can confirm that R2 now has the correct router-id:Rl#sh ip bgp neigh BGP neighbor is 10.1.1.2, remote AS 200, external link BGP version 4, remote router ID 2.2.2.2 BGP state = Established, up for 00:00:22 So now we have corrected our router-id, but a BGP network is pretty useless unless we can route traffic over it. 4.5 Route advertisement using the network command In order to advertise routes into an eBGP relationship we have a couple of options. The simplest of which is to use the network command: Rl#conf t Rl (config) #router bgp 100 R1 (config-router) #network 10.1.0.0 mask 255.255.255.0 This will cause an UPDATE message to be passed. over to R2 and R2 will then add this network first into its BGP table and then, if both valid and best it will then add the route into it's routing table: R2#sh ip bgp BGP table version is 2, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - inco mpleteNetwork Next Hop Metric LocPrf We ight Path *> 10.1.0.0/24 10.1.1.1 0 0 100 i R2#sh ip route Codes: C - connected, S - static, R - RI P, M - mobile, B - BGP D - EIGRP, EX — EIGRP external, 0 - OSPF, IA - OSPF inter area Nl - OSPF NSSA external type 1, N 2 - OSPF NSSA external type 2 El - OSPF external type 1, E2 - 0 SPF external type 2 i - IS-IS, su - IS-IS summary, Ll - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candid ate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/24 is subnetted, 3 subnets c 10.2.1.0 is directly connected, Serial0/1 is directly connected, Serial0/2 c 10.1.1.0 is directly connected, Serial0/0 B 10.1.0.0 [20/0] via 10.1.1.1, 00 2:00:33 R2#ping 10.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.0 -1, timeout is 2 seconds: Success rate is 100 percent (5/5), round -trip min/avg/max = 12/101/308 ms R2¢We can see that R2 has learnt of the 10.1.0.0/24 network through BGP (B), that it has come from AS 100 (as shown in the path), and that we have reachability (it is valid), through the next hop ip address of 10.1.1.1. This presents a good place to step back to BGP message types and have a look at UPDATE and NOTIFICATION messages. 4-6 Message Types When we started to advertise the 10.1.0.0/24 network into BGP it triggered an UPDATE message from Ri to Re, and below is the exact contents of that UPDATE message. In this packet we can see that we are informed that the AS_PATH is AS 100, the NEXT_HOP is 10.1.1.1, and the NLRI (Network Layer Reachability Information) is for the prefix 10.1.0.0/24. This is not the only information that the UPDATE message contains, but we will cover some of the other information later on. The other message type we have left to cover is a NOTIFICATION message, hopefully we won't see any of these as these are used to signal that something is wrong with a BGP session, such a message will be sent if an unsupported option issent in an OPEN message, or if a peer fails to send an UPDATE or KEEPALIVE message. If an error is detected then the BGP session is closed. A table of the error codes found within a NOTIFICATION message is below. Error Code Error Type Error Subcode 1 Message header Error 1- Connection Not Synchronized 2 - Bad Message Length 3 - Bad Message Type OPEN message Error 1- Unsupported Version 2- Bad Peer AS 3 - Bad BGP Identifier 4 - Unsupported Optional Parameter 5 - Authentication Failure 6 - Unacceptable Hold Time UPDATE message Error 1- Malformed Attribute List 2 - Unrecognized well- know attribute 3 - Missing Well-Known Attribute 4 - Attribute Flags Error 5 - Attribute Length Error 6 - Invalid Origin Attribute 7 - AS Routing Loop 8 - Invalid NEXT_HOPattribute 9 - Optional Attribute E:ror 10 - Invalid Network Field 4 Hold Timer Expired 5 Finite State Error 6 Cease 4.7 Topology Tables Now that we know how the 10.1.0.0/24 network reached R2 we need to know what R2 actually did with the information in the UPDATE message. BGP uses tables called RIBs (short for Routing Information Base) when the UPDATE message informed R2 about the additional network this was placed into the RIB, and from there populated the ip routing table on R2: R2#sh ip bgp BGP table version is 2, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, ry RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - inco mplete Network Next Hop Metric LocPrf We ight Path