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.

BGP-Unknown-1

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 understanding 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!

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>