Peering With an Unknown Autonomous System

Per popular request, this post has the purpose to explain the solution of the problem of BGP peering with an an unknown AS. I would like to start by stating the obvious.

This is a solution in a search of a problem. Popular as it may be with CCIE workbook vendors and rumor has it with CCIE exam authors, real life has almost no use of this. When faced with a log message that you will read about in few paragraphs, solution is using the phone and not doing the other stuff I'm about to write. That said, it's an interesting and fun problem.

Below is the network diagram that we'll work with. It's very simple and straightforward.



Both R1 and R2 were emulated using Dynamips and were running 12.2(31)SB13 IOS (Service Provider train). I'm sure that any other relatively newer IOS should work just fine.

Here are the relevant startup configurations for R1 and R2.

R1:

hostname R1
interface Loopback0
 ip address 192.168.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 speed 100 
 duplex full
!
router bgp 65001
 no synchronization 
 bgp log-neighbor-changes
 network 192.168.0.1 mask 255.255.255.255
 no auto-summary
!

R2:

hostname R2
 interface Loopback0
 ip address 192.168.0.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 speed 100
 duplex full
!
router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.2 mask 255.255.255.255
 no auto-summary
!

I would like to introduce several scenarios at this point.

• R1 needs to configure BGP with R2, but it doesn't know R2's AS number.


• R1 needs to configure BGP with R2, but R2 was configured to peer with another AS instead of 65001.

In all of the above scenarios, R2's admin is unavailable, or unwilling to help and you, administrator of R1, are on your own. Naturally, as we don't have R2's admin to preconfigure R2, you are again on your own to paste the configs and immediately forget them. Hopefully, it won't be too much to ask.

R1 needs to configure BGP with R2, but it doesn't know R2's AS number

Paste the following BGP configuration to R2 and forget its AS number.

router bgp 65002
 neighbor 192.168.12.1 remote-as 65001
!

With this configuration in place you should proceed to configure R1. However, you don't know what AS number to use. You have one in 65535 chances of getting it right if you just use random one. Let's pick 2.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 2

Unless you guessed the AS number, after few seconds, R1 will display the following log message:

%BGP-3-NOTIFICATION: sent to neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDEA

...
followed by some "nonsense" chain of hex numbers. While you could also decode those, they are not relevant for this case. Everything we need is right here in this log message.

Last 4 characters of the log message above, FDEA, are hex digits of the remote AS. If you convert them to decimal, they are 65002. Let's reconfigure R1 to peer with 65002.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 65002

Sure enough, after few seconds, we get the goody:

%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
R1#ping 192.168.0.2 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/40 ms

Really, it's that simple. This is the easier of the two. Before we continue to the next scenario, make sure to reload routers into startup configurations (or undo the changes).

R1 needs to configure BGP with R2, but R2 was configured to peer with another AS instead of 65001

Paste the following BGP configuration to R2 and forget the AS number.

router bgp 65002
 neighbor 192.168.12.1 remote-as 22
!

Proceed and configure R1 to peer with R2.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 65002

Just like in the previous scenario, in a few seconds, you will receive the following message on R1:

%BGP-3-NOTIFICATION: received from neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDE9

You can jump and decode the last four characters, but only to be disappointed - that is our own AS number. Devil is in the detail and you can use it to your own advantage.

First of all, although very similar, message from scenario one and this one are not the same. Here they are, side by side:

%BGP-3-NOTIFICATION: sent to neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDEA
%BGP-3-NOTIFICATION: received from neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDE9

Note that in the first case, R1 was sending notification and in this case it's receiving it. In a nutshell, this means that when BGP router receives OPEN message with remote AS indicating something else than what it has locally configured to be remote neighbor, it will send back notification to remote peer that it received something else than what it expected, also indicating what it received. However, what it will not send is any indication on what it wanted to see. Unfortunately, there is no technical solution for this problem. Even if you "sniff" the wire, you will not be able to see that R2 was configured to expect AS22.

I know that this is not exactly the answer you expected to get, but the whole excercise was not in vain. It's not completely useless. By being able to read those two log messages above and fully understand what they are communicating, you can at least know which end is somehow misconfigured. If we take our second example further and assume that you received the answer from R2's admin "I configured remote-as as 22 and I can't change it, because I'm in Fiji", how do you solve the peering problem? Of course, you can change the AS of your local BGP router, but that may not be doable if you have more than just a few. Hopefully, Cisco has an ace up its sleeve for that.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 local-as 22 no-prepend replace-as

When configured like so, R2 will be completely unaware that R1 is actually AS65001:

R2#sh ip bgp 192.168.0.1
BGP routing table entry for 192.168.0.1/32, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x420
 Not advertised to any peer
 22
   192.168.12.1 from 192.168.12.1 (192.168.0.1)
     Origin IGP, metric 0, localpref 100, valid, external, best

Also, R1 and its other BGP peers will not see AS22 in any updates:

R1#sh ip bgp 192.168.0.2
BGP routing table entry for 192.168.0.2/32, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x420
 Not advertised to any peer
 65002
   192.168.12.2 from 192.168.12.2 (192.168.0.2)
     Origin IGP, metric 0, localpref 100, valid, external, best

Mandatory reachability test:

R1#ping 192.168.0.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/40 ms

I hope that this tutorial was of some use. If that's the case, please leave some feedback.

She is beyond udnerstanding for my quirks and worries. I really, really appreciate all the effort she is putting up to just live with me. Oh, I do love her, really!

Very Long Break... and a CCDE Story

I know. I have not written any blogs for exactly 70 days. A lot of water passed under the bridge since then and even more things happened. I will refrain myself from writing about economy and even more so about the people running this lovely country I live in. Nevertheless, I digress. If you are here, you obviously don't care about all that.

I finished CCDE studies. I went for CCDE exam. I am now waiting for results. I almost wrote "veni, vidi, vici", but I'm missing the last bit of that sentence at the moment :-). According to Cisco, the wait could be as long as 12 weeks (44 days from now and counting). Let me tell you how it all went. Respecting the NDA, naturally. Since I already wrote this story elsewhere (Cisco Learning Network), I will repeat it here, for my own records and I will add a thing or two. This is better version.

First, security in the exam centre is quite impressive and I think that Cisco and VUE have the cheating covered. Everyone, including myself was worried about that, being a computer-based exam and all. I'm not any longer. Security was impressive! Multiple ID checks whenever entering or leaving the testing room, audio/video surveillance at all times and on top of that, exam that will change every time. Well done, Cisco and VUE!

The quality of the testing room, computer, chair and just about everything else (except for lunch, which was rubbish at best) was first class. There were even noise-cancelling headphones and earplugs to wear if one was worried about the noise - which there was none! Room was completely isolated from the rest of the world and there were less than 20 people in a plenty of space. Computers were quiet, too. Once again, well done!

Major worry of all people involved was taking the notes. As some of you may know, VUE testing centres do not allow anything, especially not paper to be taken into the room and this was no exception. Instead, they usually provide plastic pad and a pen, which usually doesn't work or there is way too little of writing space. Well, people taking CCDE will be happy to know that they will get good pads, good pen and plenty of space to write -- and you can always ask for more. I repeat myself, but... Well done! Ah yes, there is also in-exam note taking system that can be seen in the Practical Demo. Personally, I didn't use it. Neither did I use pad, but that was just my way of dealing with The Beast.

Of course, I cannot go into the details of the exam, but look at the demo, it should give you an idea of what to expect. Keep in mind that demo is easy and short compared to the real deal. Also, if you can, look at the Networkers presentations, as they cover other details of the exam - length, format, modules, etc. Please, do not ask me about more details, as I will provide absolutely none. Sorry, but I actually care about the quality of this exam as I was, at least a little bit, involved in its making.

Of course, the key question that can be raised is... how does one prepare for the exam, given that so little is known about it. Before taking the exam, I would have told you to read all the books and hope for the best. After taking the exam, the only thing I can tell you is to read all the books and hope for the best! Seriously, this exam is something else compared to CCIE - entirely. Well done, Cisco! :-)

The books that I mentioned in this very blog proved to be spot-on essential reading for the exam. I would like to add "Definitive MPLS Network Designs" to the list. Books won't help much by themselves. This is not an exam that you can answer questions and pass. You need more than that.

CCDE Practical is the exam that makes you think, makes you explain and makes you question yourself repeatedly. They are testing analytical skills, connecting the dots and associating apparently unrelated bits of information to find a solution for a particular situation. It requires full concentration throughout the exam. I cannot stress this enough... YOU HAVE TO READ EVERYTHING. You cannot pass without reading the scenarios and understanding them fully! Oh yes, you know what's coming here. Well done, Cisco.

I was impressed and humbled with The Beast! I'm also cautiously optimistic.

She is still here and is still so full of understanding for my networking quirks. My lovely cicimici :-).