To present this in a demonstration we've done as before and created a two node network and will setup an eBGP adjacency between the two nodes. The link between the nodes will be using the 10.1.12.0/24 network.So we'll start up by setting the addressing on the interfaces as per the diagram. First R1:
Now R2:
OK, so maybe we do a ping to confirm connectivity:
So we're going to need a network to advertise into BGP so lets have a loopback on R2 with IP address 2.2.2.2/24:
Great all done for interfaces and networks, lets crack on and configure the BGP on router R2. We're going to configure the BGP session with AS#123. We'll set the BGP router-id as the loopback address (this is shown for completeness but is not an essential configuration step). We're going to add the loopback interface in as a network to advertise. Remember the BGP 'network' statement doesn't work int he same way as most IGPs. The 'network' statement in BGP is saying "Here is a network I want to advertise to my neighbors".
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.
No comments:
Post a Comment