Here is the same output for R2. Note that R2 is connected to R1 via Fa0/0 and R3 via Fa0/1
Finally the same output for R3
OK so we have IP comms between R1, R2 and R3. Now we're going to configure the BGP relationships.
First we'll add the neighbor statement on R1 for R2 (remember we already enabled the BGP process by issuing the 'router bgp 65001' global configuration command.
Now we do the same for the other side of this neighborship on R2 pointing to R1
Note that both have the same AS# because they are iBGP neighbors. We see now that the neighbor relationship is 'Established'
OK so now lets setup the eBGP relationship between R2 and R3. Firstly on R2
Now on R3
Note the difference in AS# between that configured in the 'router bgp' and the 'remote-as' this is an eBGP relationship. We get this console message on R2 - the neighborship is Established.
So lets create our first 'network' to advertise via BGP from R3. We'll just use a loopback interface, here it is loopback0.
We bring this into BGP using the 'network' statement.
Now on R2 we can see that R3 has indeed sent us a route for 184.108.40.206/24. Notice the origin for the route is 'i' or internal. Thats because we brought the route into the BGP RIB (Routing Information Base) using the 'network' keyword.
So what happens if we bring the network in via a redistribution? We'll create another loopback interface on R3 called loopback1 and redistribute that connected interface into the BGP RIB.
Firstly the interface configuration
Now we add the necessary configuration to the bgp routing process. Firstly we need to be careful here. simply redistributing all connected interfaces will also bring our loopback 0 interface in...so lets use a route-map. We'll match the network for loopback 1 using an access-list
Here is the access list (we could use the 'host' keyword instead of 0.0.0.0)
Now the route-map. We're matching access-list 1 which is 220.127.116.11/24 which is the network we configured for interface loopback 1. Any other match is denied and dropped i.e. it won't be redistributed.
So lets have a look at the routing table on R2 to see if we now how two routes, the first from 18.104.22.168 and now a second for 22.214.171.124.
We do! Thats great. Now look at the origin. The first was an 'i' for internal which you remember was brought in using the 'network' keyword. Now the new network 126.96.36.199 has an origin of '?' which means incomplete. The reason for this is we don't know the source of the route so our knowledge of it's origin is...well incomplete. All we know is that someone brought it in from somewhere.
So there is one more origin type and that is 'e' or EGP. Now EGP is a legacy protocol and I've never come across it. To create the 'e' origin type therefore we'll have to 'fudge' it. We're going to use a route-map again to set this.
First lets create another loopback interface on R3 for this EGP candidate route.
OK, so now lets edit the existing route-map to add in our EGP configuration. What we'll do is again using an access-list match the interface lo2. If it matches then change the origin to e and set the source AS# for the EGP to 65003.
OK, now thats done we'll wait for a while till the BGP routes settle (or we can force it with a 'clear ip bgp *' at either side of the peering).
There we go...all three origin types. If these were duplicated routes learned from different sources with the same AS_PATH length we'd choose i first, then e then ?.
So what about R1? You're right we didn't even use this yet...lets take a look at it's routing table...
Nothing? Of course - is the next hop in my routing table? No of course not so the route goes into the BGP RIB but is inaccessible. So we need to set the 'next-hop-self' on R2 to change the next hop to R2's fa0/0 interface.
OK lets see the routing table now.
Looks good - of course R3 has no way of knowing how to get to 188.8.131.52/24 yet but you know how to do that now right? Of course you do...
Thanks for reading.
So the 'neighbor' statement is saying here is my BGP neighbor IP address (in our case R1 with 10.1.12.1 and it's remote-as number is 100.
Right, lets move on to R1 now and configure the BGP session there. We'll want to use AS#100 (remember R2 pointed to remote-as 100) and then add in the neighbor statement. In this example we're not really interested in sending any networks from R1 to R2 so there are no network statements of redistributions etc.
OK! we'll we've put the configuration in and almost immediately we'd commited the neighbor statement to the running config the router went away and tried to establish the BGP session. The router has dumped a log to the console which includes a lot of HEX formatted 'guff' (thats a technical term).
To troubleshoot the issue lets dissect the debug/log. We see that we have a BGP notification saying that the 'peer in wrong AS'. So R1 ha been told here by R2 that the AS number it is using doesn't match it's configured AS#. The router tells you that the AS# is 2 bytes long and...it is ;-) AS#'s are valid between the range of 0 and 64511 (64512 to 65535 are reserved for private use.
Anyway back to the story, the remote side AS# is contained in the log dump as the first 2 bytes after the word '2 bytes' ;-)
The HEX following the message is 007B and the BGP AS# is DECIMAL so we'll need to convert it...where is that scientific calculator?
So we'll use the MAC calculator. Click the '16' button because HEX is base 16...why can't they just say HEX? So lets pop in the HEX we got in the log message 007B. So now click the 10 button because DECIMAL is base 10...of course ;-) and we get...drum roll please
Right so the remote AS# is 123...of course...why didn't I just click on R2 and do a show running-config ;-) We'll this is a scenario of course and it's all about the 'win'.
So lets go onto R1 and change that neighbor line to reflect the correct AS# of 123 not 1 as we had originally set it.
Great, and the BGP session has come up. Tell you what lets just have a look in the routing table to see if that loopback0 interface from R2 is in there?
So thats it, BGP is up and routing updates are being received.
Job well done.
So, we've basically built the basic configuration, nothing fancy. We've added the interface Fa0/0 in for both routers so EIGRP will be enabled onto those. We've also added in the Loopback0 interface of each (just because we did - it has no part to play for this post and can be ignored). You should however give some attention to the chosen EIGRP AS #. Notice that the router R2 has AS# 12345 where R1 is as AS #1. We've done this o illustrate the point that we don't know the remote AS. We need to use an AS number to make EIGRP work int he first place...you can choose any AS number here so long as it isn't 12345 ;-) Think back to the original example where we discussed LA and NJ...you are not supposed to know the AS# otherwise what is the point of debugging the problem?
Right, how do we catch the traffic? Well the router clearly sees all the traffic we need so it makes sense to use the router to collect and show the packets right? OK we all probably know and use 'debug ip packet' but hopefully not on production systems unless you know what you are doing. Here is a screenshot for the command.
Notice the access-list on the end? We could use this to tune down the traffic which the router will be examining. Indeed using 'debug ip packet' on a production system would be suicidal without some sort of filtering. For our demo here however we're not going to need this filtering because we don't have any traffic. You *should* definately note however that there is a missing or 'hidden' command here called 'dump'. IOS has a few of these little easter eggs hiding in the code. Normally it's because they are either really dangerous in the wrong hands or else they are not very well tested and therefore shouldn't be used by mortals. In this case I feel the dump keyword is missed off because if you thought debug ip packet created too much console information to be healthy then adding dumps of data to the console is never going to be the best plan.
So we turn on debugging and ask it to also crack open and dump the data inside the packet like a typical pcap...HEX and all that good stuff.
OK so here is a dump of data. We see the sources are our local Fa0/0 (s=10.1.12.1) and Loopback0 (s=184.108.40.206) interfaces. OK so where is the R2 traffic?
Here's one s=10.1.12.2 great. So where is the AS number man...I bet the big red circle gives it away for you. The first few bytes are header so things like destination MAC for EIGRP mulicast group 220.127.116.11 (0100.5e00.000a) followed by source MAC of R2 (c201.0cab.0000)...etc.
So we have the HEX value of 3039 remember EIGRP uses values from 0 to 65535 which is a 32 bit number (same number of bits as an IP address). So lets pop 3039 into a HEX to DEC calculator and we get 12345...thats IT!
Job done - all we need to do now is change the AS number we used in R1 (AS#1) with the one we just 'discovered' (AS#12345). Now because we can't simply rename the AS number we need to tear down the original and rebuild it. If you had a lot of config below the 'router eigrp' function you are best to do a 'show run | b router eigrp' and copy the config then all you need to do is paste it in.
Job done - enjoy