Internet Routing Architectures (CISCO):Configuring Basic BGP Functions and Attributes Previous Table of Contents Next The Next_Hop Attribute Consider the BGP table of RTF: RTF#sh ip bgp BGP table version is 8, local router ID is 192.68.5.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i172.16.1.0/24 172.16.2.254 0 100 0 i *> 0.0.0.0 0 32768 i * i172.16.10.0/24 172.16.2.254 20 100 0 i *> 0.0.0.0 0 32768 i * i172.16.65.0/26 172.16.2.254 20 100 0 i *> 0.0.0.0 0 32768 i * i172.16.220.0/24 172.16.2.254 0 100 0 i *> 172.16.1.1 20 32768 i *> 192.68.10.0 192.68.5.2 0 0 2 i * 192.68.11.0 192.68.5.2 0 2 1 i *>i 172.16.20.1 0 100 0 1 i Network 192.68.11.0/24 is learned via IBGP (note the "i" at the far left) with next hop 172.16.20.1, which is the IP address of the external neighbor of RTA. The EBGP next hop IP address is always carried inside the IBGP, which is why it is very important to have an internal route to the next hop. Otherwise, the BGP route would be unreachable. There are a couple of ways to make sure that you do not have problems reaching the EBGP next hop. The first way is to include the network that the next hop belongs to in the IGP. This is illustrated on RTA by including interface serial 0 in the OSPF; this way, RTF would know about 172.16.20.1. Note that even though OSPF is running on RTA serial 0, it need not exchange any OSPF "Hello" packets on serial 0, hence the passive-interface router command. The second method is to use the next-hop-self (see RTF) neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. On RTF, note how the next-hop-self is added at the end of the neighbor statement toward RTA. This way, when RTF advertises external networks such as 192.68.10.0/24 toward RTA, it will use itself as the next hop. Looking at RTA's BGP table that follows, prefix 192.68.10.0/24 is learned via next hop 172.16.1.2, which is its internal peer with RTF. Because 172.16.1.2 is part of the OSPF already, we have no problem reaching it. RTA#sh ip bgp BGP table version is 20, local router ID is 172.16.2.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i172.16.1.0/24 172.16.1.2 0 100 0 i *> 0.0.0.0 0 32768 i * i172.16.10.0/24 172.16.1.2 0 100 0 i *> 172.16.1.2 20 32768 i * i172.16.65.0/26 172.16.1.2 0 100 0 i *> 172.16.1.2 20 32768 i * i172.16.220.0/24 172.16.1.2 20 100 0 i *> 0.0.0.0 0 32768 i *>i192.68.10.0 172.16.1.2 0 100 0 2 i * 172.16.20.1 0 1 2 i *> 192.68.11.0 172.16.20.1 0 0 1 i Note in the preceding table that 192.68.10.0/24 is actually learned via two different paths, whereas 192.68.11.0/24 is learned via a single path. This might seem misleading, but actually routing is doing the right thing. In this situation, RTF has decided that the best path to reach 192.68.11.0/24 is via RTA (check RTF's BGP table) ; this is why RTF will not advertise network 192.68.11.0/24 back to RTA, and RTA will have a single entry for 192.68.11.0/24. The AS_Path Attribute Looking at RTF's BGP table that follows, you can see the AS_path information at the end of each line. Network 192.68.11.0/24 is learned via IBGP with AS_path 1 and via EBGP with AS_path 2 1. This means that if RTF wanted to reach 192.68.11.0/24 via IBGP, it can go to AS1, and if RTF wanted to reach 192.68.11.0/24 via EBGP, it has to go via AS2 then AS1. BGP always prefers the shortest path, which is why the path via IBGP with AS_path 1 is preferred. The ">" sign at the left is an indication that out of the two available paths that BGP has for 192.68.11.0/24, BGP has preferred the second one as being the "best" path. RTF#sh ip bgp BGP table version is 8, local router ID is 192.68.5.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i172.16.1.0/24 172.16.2.254 0 100 0 i *> 0.0.0.0 0 32768 i * i172.16.10.0/24 172.16.2.254 20 100 0 i *> 0.0.0.0 0 32768 i * i172.16.65.0/26 172.16.2.254 20 100 0 i *> 0.0.0.0 0 32768 i * i172.16.220.0/24 172.16.2.254 0 100 0 i *> 172.16.1.1 20 32768 i *> 192.68.10.0 192.68.5.2 0 0 2 i * 192.68.11.0 192.68.5.2 0 2 1 i *>i 172.16.20.1 0 100 0 1 i Previous Table of Contents Next