BGP As Path Manipulation

BGP AS_PATH Manipulations:
allowas-in, local-as, remove-private-as

DISCLAIMER: The content has not been fact checked or peer reviewed. The document may
contain errors.
Selected command output has been removed for brevity.
Introduction
This document covers the following BGP topics from my study session: allowas-as, local-as
and remove-private-as. AS_PATH prepending is weaved in with the other topics. Regular
expressions are not covered here. The topics are listed in the CCIE Enterprise Infrastructure
blueprint under the BGP AS_PATH manipulations section, as follows:
● 1.5.d AS path manipulations
○ 1.5.d i local-AS, allowas-in, remove-private-as
○ 1.5.d ii Prepend
○ 1.5.d iii Regexp
Scenario
To demonstrate the concepts, a simple looped topology of five routers is used. Not all routers
may be used for the purpose of investigating the features.
The IP address design is constructed as 10.10.x.0/24, where x is a combination of the router

numbers, between the link connecting the routers. For example, R1 and R2 share the
10.10.12.0/24 subnet. Each router also has a Loopback0 interface configured in the form
x.x.x.x/32, where x identifies the router number. For example, the Loopback0 interface IP
address for R1 is 1.1.1.1/32. The Loopback0 address is also used as the router ID for
routing protocols.
© Network Playroom 1
allowas-in
BGP uses the AS_PATH attribute for loop detection and avoidance. The AS_PATH attribute
is a list of AS numbers that the update has traversed. When BGP sends an update to
another AS, its own AS is added to the AS_PATH attribute. If a router sees its own AS
number in the AS_PATH attribute, it rejects the update.
The allowas-in command allows BGP to accept an update even if it contains its own AS.
To demonstrate this behavior, R1 (AS 65001) and R2 (AS 65001) will form an eBGP peering.
R2 will send a modified BGP update to R1, where the AS_PATH attribute has been
manipulated to include R1’s AS number. Two networks will be advertised but only one will
have the altered AS_PATH attribute, so that the difference can be shown clearly. The
Loopback0 network (2.2.2.2/32) and the directly connected network to R3 (10.10.23.0/24)
will be added to BGP using the network command.
However, before the BGP updates are manipulated, a baseline shall be established to see
how R2 would advertise the routes normally.
First, eBGP peering is configured between R1 and R2 over the directly connected network.
R1#
router bgp 65001
neighbor 10.10.12.2 remote-as 65002
R2#
router bgp 65002
Second, the networks are advertised on R2.
router bgp 65002

network 2.2.2.2 mask 255.255.255.255
network 10.10.23.0 mask 255.255.255.0
NOTE: The network command in BGP works differently from IGPs. There must be an exact
match in the routing table. If the mask parameter is left out, a classful mask is assumed.
R2#show ip route connected | exclude L
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.10.12.0/24 is directly connected, GigabitEthernet0/1
C 10.10.23.0/24 is directly connected, GigabitEthernet0/0
R1 should receive the routes, as displayed in the BGP table.
R1#show ip bgp
BGP table version is 3, local router ID is 1.1.1.1
Network Next Hop Metric LocPrf Weight Path

*> 2.2.2.2/32 10.10.12.2 0 0 65002 i
*> 10.10.23.0/24 10.10.12.2 0 0 65002 i
Now that basic BGP configuration and behavior has been reviewed, it is time to investigate
the allowas-in command. For this, R2’s Loopback0 network advertisement will be
manipulated by defining a prefix-list to match it and then prepending R1’s AS number to it
using a route-map. R2’s own AS number will also be added to AS_PATH two more times and
R1’s AS number will be added once to show how the attribute can be controlled beyond a
single AS number prepend.
This setup will cause R1 to reject the update at first due to finding its own AS in the
AS_PATH attribute. Then the allowas-in command is used to disable the AS_PATH
attribute check and allow R1 to accept the update anyway.
The following diagram illustrates the idea.
In addition to AS_PATH prepending, R2 will add its own AS number to the attribute. In
conclusion, the full AS_PATH will be {65002 65002 65002 65001}.
First, the prefix-list and route-map are configured in the following way. The prefix-list R2-LO0
matches R2’s Loopback0 address. The route-map ADD_AS_PATH matches the prefix-list
and modifies the AS_PATH attribute.
ip prefix-list R2-LO0 permit 2.2.2.2/32
!
route-map ADD_AS_PATH permit 10
match ip address prefix-list R2-LO0
set as-path prepend 65002 65002 65001
Use the show route-map command to verify the configuration.
R2#show route-map
route-map ADD_AS_PATH, permit, sequence 10
Match clauses:
ip address prefix-lists: R2-LO0
Set clauses:
as-path prepend 65002 65002 65001
Policy routing matches: 0 packets, 0 bytes
Second, the route-map is attached to the neighbor statement and configured in the outbound
direction, because the BGP updates will be sent out towards R1.
router bgp 65002

neighbor 10.10.12.1 route-map ADD_AS_PATH out
BGP update debugging is enabled on R1 to explore incoming updates and a hard reset is
issued on R2 to rotate the adjacency and push the updates out.
R1#debug bgp ipv4 unicast updates
R2#clear ip bgp *
The following log messages appear on R1.
BGP(0): 10.10.12.2 rcv UPDATE w/ attr: nexthop 10.10.12.2, origin i, metric 0,

originator 0.0.0.0, merged path 65002 65002 65002 65001, AS_PATH , community ,
extended community , SSA attribute
BGPSSA ssacount is 0
BGP(0): 10.10.12.2 rcv UPDATE about 2.2.2.2/32 -- DENIED due to: AS-PATH contains
our own AS;
It is clearly stated that the update is dropped because the AS_PATH attribute contains R1’s
own AS.
The other route (10.10.23.0/24) should still be received. That can be verified with the show
ip bgp command.
R1#show ip bgp
R1#
There is no output, which means the BGP table is empty and R1 is not learning anything
from R2. This is also clear from the show ip bgp summary command, which indicates
that zero prefixes have been received.
R1#show ip bgp summary

BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.10.12.2 4 65002 12 11 1 0 0 00:07:17 0
Checking on the other side, R2 is advertising only 2.2.2.2/32 to R1.
R2#show ip bgp neighbors 10.10.12.1 advertised-routes


*> 2.2.2.2/32 0.0.0.0 0 32768 i
Both routes are still in R2’s BGP table.
R2#show ip bgp

*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 10.10.23.0/24 0.0.0.0 0 32768 i
Why is only one route (2.2.2.2/32) advertised to R1 but the other one (10.10.23.0/24) is not?
The problem is actually the route-map. The route-map is only allowing R2’s Loopback0
network to be advertised. Remember that there is an implicit deny statement at the end.
Unless a route is explicitly permitted, it is denied.
Another permit statement must be added to the route-map, which allows any other networks
to be advertised (without modification). A simple permit statement without any match or set
statements is sufficient.
route-map ADD_AS_PATH permit 20
R2#show route-map
Match clauses:
ip address prefix-lists: R2-LO0
Set clauses:
as-path prepend 65002 65002 65001
Match clauses:
Set clauses:
The 10.10.23.0/24 route is received on R1 and it is installed in the routing table. The
2.2.2.2/32 route is still rejected, because the update contains R1’s own AS.
*BGP(0): 10.10.12.2 rcv UPDATE about 2.2.2.2/32 -- DENIED due to: AS-PATH
contains our own AS;
*BGP(0): Revise route installing 1 of 1 routes for 10.10.23.0/24 ->
10.10.12.2(global) to main IP table
R1#show ip bgp

*> 10.10.23.0/24 10.10.12.2 0 0 65002 i
R1#show ip route bgp

B 10.10.23.0/24 [20/0] via 10.10.12.2, 00:02:39
Finally, the allowas-in command can be configured to allow R1 to accept R2’s Loopback0
network despite it having R1’s own AS in the update.
router bgp 65001

neighbor 10.10.12.2 allowas-in
The following log messages are seen on R1.
*BGP(0): 10.10.12.2 rcvd UPDATE w/ attr: nexthop 10.10.12.2, origin i,

metric 0, merged path 65002, AS_PATH
*BGP(0): 10.10.12.2 rcvd 10.10.23.0/24
*BGP(0): 10.10.12.2 rcvd UPDATE w/ attr: nexthop 10.10.12.2, origin i,
metric 0, merged path 65002 65002 65002 65001, AS_PATH
*BGP(0): 10.10.12.2 rcvd 2.2.2.2/32
Both routes are in R1’s BGP table. The AS_PATH attribute for 2.2.2.2/32 contains R1’s own
AS but it is still accepted as a valid route.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 65002 65002 65002 65001 i
*> 10.10.23.0/24 10.10.12.2 0 0 65002 i
Both routes are also installed in the routing table and used for packet forwarding.
R1#show ip route bgp
2.0.0.0/32 is subnetted, 1 subnets

B 2.2.2.2 [20/0] via 10.10.12.2, 00:02:48
B 10.10.23.0/24 [20/0] via 10.10.12.2, 00:02:48
local-as
The local-as command allows a router to appear to external BGP peers as a member of
another autonomous system. In loose words, the router fakes its AS number to the outside
world.
The local-as feature is typically used for the purpose of AS number migration. Without this
feature, BGP configuration would have to be removed entirely and restored, which would
cause a disruption.
NOTE: The AS number has a key role in BGP loop detection and avoidance. Routing loops
can be created through improper configuration.
R1 is configured in local AS 65111, while the real AS is still 65001.
router bgp 65001
neighbor 10.10.12.2 local-as 65111
Since R2 will see R1 as being in AS 65111, this change must be reflected in the neighbor
statement.
router bgp 65002

Again, R1’s real AS number is still 65001.

3 network entries using 432 bytes of memory
3 path entries using 240 bytes of memory
2/2 BGP path/bestpath attribute entries using 304 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1000 total bytes of memory
BGP activity 12/9 prefixes, 13/10 paths, scan interval 60 secs

10.10.12.2 4 65002 3098 3092 14 0 0 00:04:28 2
R2 sees R1 in AS 65111.

2 network entries using 288 bytes of memory
2 path entries using 160 bytes of memory
1/1 BGP path/bestpath attribute entries using 152 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 600 total bytes of memory
BGP activity 9/7 prefixes, 9/7 paths, scan interval 60 secs

10.10.12.1 4 65111 10 11 9 0 0 00:05:41 0
The local-as command does not actually replace the AS number advertised to peers. The
router actually prepends the local AS number in front of its real AS number. It also seems
that the local AS is added to received routes.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 65111 65002 i
*> 10.10.23.0/24 10.10.12.2 0 0 65111 65002 i
To test the local AS prepending to the real AS, R1 will advertise its Loopback0 network to
R2.
R1#
router bgp 65001
network 1.1.1.1 mask 255.255.255.255
The path appears in the BGP table as a normal locally originated route would.
R1#show ip bgp

*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.10.12.2 0 0 65111 65002 i
*> 10.10.23.0/24 10.10.12.2 0 0 65111 65002 i
When the route is received on R2, both the real AS and local AS of R1 are included in
AS_PATH.
R2#show ip bgp

*> 1.1.1.1/32 10.10.12.1 0 0 65111 65001 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 10.10.23.0/24 0.0.0.0 0 32768 i
remove-private-as
BGP contains AS number ranges for different purposes. As a rough cut, AS numbers
1-65,411 are for public use and AS numbers 64,512-65,535 are for private use.
The purpose of the remove-private-as command is quite clear from the command
syntax alone. That is, it removes private AS numbers from the AS_PATH in outbound routing
updates. This command is available for external BGP peers only.
Depending on the code version of IOS, the behavior of the remove-private-as command
is different. Check the details for the specific software version from the Cisco command
reference.
For this part, R1 and R2 are put in public AS numbers 11 and 22, respectively. The basic
networks are also advertised from R2 to R1.
R1#
router bgp 11
R2#
router bgp 22
network 2.2.2.2 mask 255.255.255.255
network 10.10.23.0 mask 255.255.255.0
At first, the routes advertised to R1 only include R2’s public AS number 22.
R1#show ip bgp
*> 2.2.2.2/32 10.10.12.2 0 0 22 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
To verify that the remove-private-as command actually works only in the outbound
direction, R2 shall advertise routes that include private AS numbers (the same AS_PATH
prepending from the previous section can be used) and private AS removal is configured
inbound on R1.
R2#
router bgp 22
R1#
router bgp 11
neighbor 10.10.12.2 remove-private-as
The routes are still learned with the private AS numbers intact.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 65002 65002 65001 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
If the remove-private-as command is applied on R2 right now, it should not change the
output on R1. Although R2 should remove private AS numbers from outgoing updates, the
processing logic on the router may prevent this from happening. The private AS numbers are
assigned on R2 through AS_PATH prepending locally, so it does not make sense for R2 to
assign private AS numbers via a route-map and then remove them via the
remove-private-as command before sending the updates out to R1.
R1#
router bgp 11
no neighbor 10.10.12.2 remove-private-as
R2#
router bgp 22
neighbor 10.10.12.1 remove-private-as
The routes still have the private AS numbers.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 65002 65002 65001 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
To do this properly, another router R3 is added in its own BGP AS 33. An external BGP
peering is configured between R2 and R3 over the 10.10.23.0/24 network.
R2#
router bgp 22
R3#
router bgp 33
Then R3 shall advertise its Loopback0 address with a modified AS_PATH attribute, as
follows {65003 65033 65333}. This can also be done without specifying only one
network to match using a prefix-list but instead slapping the private AS numbers on all
outgoing updates to R2.
R3#
route-map R3_ADD_PRIVATE_AS permit 10
set as-path prepend 65003 65033 65333
!
router bgp 33
network 3.3.3.3 mask 255.255.255.255
neighbor 10.10.23.2 route-map R3_ADD_PRIVATE_AS out
R2 receives R3’s Loopback0 route with the manipulated AS_PATH attribute, which includes
the private AS numbers.
R2#show ip bgp

*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.10.23.3 0 0 33 65003 65033 65333 i
*> 10.10.23.0/24 0.0.0.0 0 32768 i
R1 also learns the route with the private AS numbers, despite remove-private-as being
configured on R2, which should, by sound reasoning, remove them.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 65003 65033 65333 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
Why are the private AS numbers not removed?
The answer to this can be found from the Cisco command reference. See: BGP Command
Reference - remove-private-as
neighbor remove-private-as
To remove private autonomous system numbers from the autonomous system path (a list of
autonomous systems that a route passes through to reach a BGP peer) in eBGP outbound
routing updates, use the neighbor remove-private-as command in router configuration,
address family configuration, or peer-group template mode. To disable this function, use the
no form of this command.
neighbor {ip-address | peer-group-name} remove-private-as [all [replace-as]]
no neighbor {ip-address | peer-group-name} remove-private-as
Syntax Description
ip-address IP address of the BGP-speaking neighbor.
peer-group-name Name of a BGP peer group.
all (Optional) Removes all private AS numbers from the AS path in outgoing
updates.
replace-as (Optional) As long as the all keyword is specified, the replace-as

keyword causes all private AS numbers in the AS path to be replaced
with the router’s local AS number.
Command Default
No private AS numbers are removed from the AS path.
Contrary to what could be assumed, the remove-private-as command alone does not
actually remove the private AS numbers.
To remove all private AS numbers from the outgoing updates, the all parameter is added.
R2#
router bgp 22
neighbor 10.10.12.1 remove-private-as all
The routes on R1 do not contain private AS numbers anymore.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
R2 can also replace the private AS numbers with its own BGP AS number.
R2#
router bgp 22
neighbor 10.10.12.1 remove-private-as all replace-as
The AS_PATH includes R2’s AS number multiple times now and the private AS numbers
have been removed.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 22 22 22 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
To double check that the private AS numbers on R2 are not removed, if the private AS
numbers are added locally through AS_PATH manipulation, R2’s Loopback0 network shall
be advertised with the previous configuration.
R2#
router bgp 22
R2’s Loopback0 network still contains the private AS numbers, while the private AS numbers
in R3’s Loopback0 network have been removed.
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 65002 65002 65001 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
It makes no difference to R2’s Loopback0 route if the replace-as parameter is also used.
The private AS numbers on R3’s Loopback0 route are replaced with R2’s AS number.
R2#
router bgp 10.10.12.1 remove-private-as all replace-as
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 65002 65002 65001 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 22 22 22 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
Once again, the remove-private-as [all] command does not work in the inbound
direction. If configured on R1, it does not remove the private AS numbers from incoming
updates.
R1#
router bgp 11
R1#show ip bgp

*> 2.2.2.2/32 10.10.12.2 0 0 22 65002 65002 65001 i
*> 3.3.3.3/32 10.10.12.2 0 22 33 22 22 22 i
*> 10.10.23.0/24 10.10.12.2 0 0 22 i
References
Cisco IOS Master Command List, All Releases
CCIE Enterprise Infrastructure Exam Topics - Lab Exam

BGP As Path Manipulation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP As Path Manipulation

Uploaded by

Copyright:

Available Formats

BGP AS_PATH Manipulations:

allowas-in, local-as, remove-private-as

Selected command output has been removed for brevity.

The IP address design is constructed as 10.10.x.0/24, where x is a combination of the router

Second, the networks are advertised on R2.

router bgp 65002

R2#show ip route connected | exclude L

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets

Network Next Hop Metric LocPrf Weight Path

The following diagram illustrates the idea.

Use the show route-map command to verify the configuration.

router bgp 65002

R1#debug bgp ipv4 unicast updates

The following log messages appear on R1.

BGP(0): 10.10.12.2 rcv UPDATE w/ attr: nexthop 10.10.12.2, origin i, metric 0,

R1#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

Checking on the other side, R2 is advertising only 2.2.2.2/32 to R1.

R2#show ip bgp neighbors 10.10.12.1 advertised-routes

Network Next Hop Metric LocPrf Weight Path

Both routes are still in R2’s BGP table.

Network Next Hop Metric LocPrf Weight Path

route-map ADD_AS_PATH permit 20

Network Next Hop Metric LocPrf Weight Path

R1#show ip route bgp

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

router bgp 65001

The following log messages are seen on R1.

*BGP(0): 10.10.12.2 rcvd UPDATE w/ attr: nexthop 10.10.12.2, origin i,

Network Next Hop Metric LocPrf Weight Path

R1#show ip route bgp

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets

R1 is configured in local AS 65111, while the real AS is still 65001.

router bgp 65002

Again, R1’s real AS number is still 65001.

R1#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

R2#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

The routes still have the private AS numbers.

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Why are the private AS numbers not removed?

neighbor {ip-address | peer-group-name} remove-private-as [all [replace-as]]

no neighbor {ip-address | peer-group-name} remove-private-as

peer-group-name Name of a BGP peer group.

replace-as (Optional) As long as the all keyword is specified, the replace-as

No private AS numbers are removed from the AS path.

The routes on R1 do not contain private AS numbers anymore.

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

Network Next Hop Metric LocPrf Weight Path

You might also like