Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the rss feed! You can also receive updates from this blog via email. Thanks for visiting!
BGP Local-AS
BGP allows you to manipulate your Autonomous System (AS) number in a number of different ways including confederations, local-as, and remote-as commands. This article focuses on manipulating your AS as seen by other remote AS’s using the local-as command. We will also look at some tips and tricks using this in conjunction with BGP allowas-in.
Lets say you have this scenario:
You can download the sample .net file for use with dynamips here.
R1 has the following configuration:
hostname R1
!
int s1/0
ip add 192.168.1.1 255.255.255.252
no shut
!
int lo0
ip add 150.1.1.1 255.255.255.252
!
int lo1
ip add 150.1.2.1 255.255.255.252
!
int lo2
ip add 150.1.3.1 255.255.255.252
!
router ospf 1
network 192.168.1.1 0.0.0.0 area 0
!
router bgp 250
network 150.1.1.0 mask 255.255.255.252
network 150.1.2.0 mask 255.255.255.252
network 150.1.3.0 mask 255.255.255.252
neighbor 192.168.1.2 remote-as 1
So far so good. We have set up R1 with an IGP (ospf) which is not really important for this examples we just want to make sure that all three routers have full IGP connectivity. We have created three loopback interfaces on R1 that we are advertising through BGP.
Lets have a look at R2’s configuration:
hostname R2
!
int s1/0
ip add 192.168.1.2 255.255.255.252
no shut
!
int s1/1
ip add 192.168.1.5 255.255.255.252
no shut
!
router ospf 1
network 192.168.1.2 0.0.0.0 area 0
network 192.168.1.5 0.0.0.0 area 0
!
router bgp 101
neighbor 192.168.1.1 remote-as 250
Wait a minute, alarms bells should be ringing. Didn’t we tell R1 that R2 was in AS 1! Sure enough soon R1, starts popping up with error messages:
R1(config-router)#
*Mar 1 00:02:55.059: %BGP-3-NOTIFICATION: sent to neighbor 192.168.1.2 2/2 (peer in wrong AS) 2 bytes
0065 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0065 00B4 C0A8 0105 1002 0601 0400 0100 0102
0280 0002 0202 00
R2(config-router)#
*Mar 1 00:03:26.335: %BGP-3-NOTIFICATION: received from neighbor 192.168.1.1 2/2 (peer in wrong AS)
2 bytes 0065
That wrong AS 2 bytes 0065 is in hex. Converting 0×0065 to decimal gives us 101. So its telling us “Hey you said he was in as 1, but he is telling me he’s in 101!”. We can change the AS number on R2 or change the neighbor peering statement on R1, or we could do something a bit trickier and tell R2 to pretend to be in AS 1 by using the neighbour local-as command.
R2(config)# router bgp 101
R2(config-router)#neighbor 192.168.1.1 local-as 1
We can see on R1 and R2 that this works:
R2#
*Mar 1 00:04:55.279: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up
R2#sh ip bgp summ
BGP router identifier 192.168.1.5, local AS number 101
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.1 4 250 9 9 0 0 0 00:00:10 0
Cool so we have our neighbor up and we are successfully pretending to be AS 1 to R1. R2 has learnt the three BGP prefixes from R1:
R2#sh ip bgp
BGP table version is 4, local router ID is 192.168.1.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.0/30 192.168.1.1 0 0 1 250 i
*> 150.1.2.0/30 192.168.1.1 0 0 1 250 i
*> 150.1.3.0/30 192.168.1.1 0 0 1 250 i
BGP Allowas-in
Let configure R3:
hostname R3
!
int s1/0
ip add 192.168.1.6 255.255.255.252
no shut
!
router ospf 1
network 192.168.1.6 0.0.0.0 area 0
!
router bgp 1
neighbor 192.168.1.5 remote-as 101
Then add R3 as a BGP neighbor on R2:
R2(config)#router bgp 101
R2(config-router)#neighbor 192.168.1.6 remote-as 1
Here we have R3 in AS 1 peering to R2 in AS 101. Should be cool. But it isn’t. The adjacency is formed between R2 and R3. The problem is no prefixes are being received by R3.
R3#
*Mar 1 00:05:33.347: %BGP-5-ADJCHANGE: neighbor 192.168.1.5 Up
R3#sh ip bgp summ
BGP router identifier 192.168.1.6, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.5 4 101 5 4 1 0 0 00:00:11 0
R3#sh ip bgp
R3#
That last command returns nada! What is the problem?!
Well if we look at R2’s BGP prefixes what does it have as the AS-PATH for the the three prefixes advertised by R1:
R2#sh ip bgp
BGP table version is 4, local router ID is 192.168.1.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.0/30 192.168.1.1 0 0 1 250 i
*> 150.1.2.0/30 192.168.1.1 0 0 1 250 i
*> 150.1.3.0/30 192.168.1.1 0 0 1 250 i
See how it has 1 in the path! What is the rule regarding prefixes when you see your own AS in them. Disregard them, there must be a loop! So When R3 gets the Prefixes from R2, and sees its own AS in the path, it goes “Whoa, i see my own AS in there so there must be a loop!”
To fix this we can use the neighbor allowas-in command. This will override the AS rule, and we will accept the prefix even if we see our own AS:
R3(config)#router bgp 1
R3(config-router)#neighbor 192.168.1.5 allowas-in
Voila! Problem solved.
R3#sh ip bgp
BGP table version is 4, local router ID is 192.168.1.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.0/30 192.168.1.5 0 101 1 250 i
*> 150.1.2.0/30 192.168.1.5 0 101 1 250 i
*> 150.1.3.0/30 192.168.1.5 0 101 1 250 i
Summary:
Resources:
Download preconfigured .net file for dynamips
Download Sample R1 Configuration
Download Sample R2 Configuration
Download Sample R3 Configuration
Thanks for this explanation.
Another interesting topic I ran into under BGP lately is the use of template to create ibgp peering instead of using peer group.
It’s kinda interesting
Hi, Allowas-in can be used for public internet BGPv4 and MP-BGP for MPLS-VPN scenario?
ummm your assuming here that someone has access to all routers. What if you dont have access to the peer itself?? Aside from sniffing the wire If you are peering with a device and u see this error message you will never know what to configure the local as as unless you run a debug. For that matter some IOS
versions will only show ur own as in the debug and the AS of the peering router but it wont tell you what you need to configure as the local as.
In later IOS versions you can actually see via a debug what the expected as is, eg
bad OPEN, remote AS is 400, expected 10
wills,
If you don’t have access to R3 and can not issue the command allowas-in the problem can be solved by issuing the command local-as with the no-prepend option on R2; the no-prepend option will remove the local-as from the AS-Path so R3 will accept the prefiexs
[...] BGP allowas-in, BGP local-as tips and tricks… [...]
While this is a “tip/trick”, please note the following as from an ISP perspective, this really is NOT a good set of options to use for the following reasons:
The BGP local-as / no-prepend/replace-as feature is a “Not Supported Feature”, a non-starter. As an alternative, cisco recommends the customer use a CE solution called Optimized Edge Routing (OER).
The following comments regarding AS# changes are based upon Cisco’s recommendation:
The BGP local-as/no-prepend/replace-as feature is a knob in Cisco IOS added to assist customers in migrating from one AS to another AS, and should only be implemented as a short term workaround while networks are migrated. BGP prepends the autonomous system number from each BGP network that a route traverses. This behavior is designed to maintain network reach ability information and to prevent routing loops from occurring. Configuring this feature incorrectly could create routing loops. This is not intended to be used long term and can introduce operational support issues within ISP ’s network.
This feature, by it’s very nature, breaks the routing loop protection automatically provided by BGP since ISP is not adding their AS to the AS-PATH and the customer is also peering with another provider. These loops could lead to extended outages to the customer due to the fact that the problem would be sporadic and difficult to troubleshoot.
An example scenario is described below.
- ISP advertises 10.1.1.0/24 (Customer site B) to Customer site A overwriting our AS of 999 with AS 65111.
- Customer site A readvertises 10.1.1.0/24 (Customer site B) back to ISP , which would be accepted as ISP is not AS 65111 and ISP ’s AS 999 in not listed in the AS path.
- ISP ’s PE connected to Customer site A will advertise the update of 10.1.1.0/24 to the route reflector’s (RR).
- ISP ’s RR’s will use IGP metrics to pick best path and forward on to ISP PE’s, which would result in other Customer sites (C, D, etc) homed to those
PE’s receiving the wrong path creating routing loops.
- This starts the churning of the BGP route for 10.1.1.0/24 within the GMPLS network, including RR’s and advertisements to ISP PE’s and other customer
sites off of those PE’s. Once the churn begins, ISP will have no way of knowing for sure where the advertisement should be coming from and the delay in
troubleshooting this could be extended dramatically.
Please note the example above only uses one route. Potentially, this could occur with numerous routes from numerous customer locations. This would also
lead to an increase in memory utilization and processor utilization on the PE routers as noted in the past with similar EIGRP-related routing loop issues.
[...] BGP local-as tips and [...]