This chapter is from the book
This chapter is from the book
This chapter is from the book
Local AS
When two ISPs merge their networks, many challenges related to BGP design arise. When one AS is being replaced by another AS, its former peering autonomous systems might not honor the new AS and might continue to insist on the previous peering agreements. For example, if ISP A has a private peering agreement with ISP B, and if ISP A is acquired by ISP C, ISP B might not want to peer with ISP C but might honor the previous peering agreement with ISP A.
An ISP generally has various peering agreements with other ISPs. Changing the AS number on a large scale might be too disruptive to its peering sessions with other ISPs. Also, changing the AS number on all the routers in one large AS during one maintenance window might not be feasible or recommended. During the migration, both autonomous systems must coexist and continue to communicate. The BGP Local AS feature helps reduce these challenges.
With the Local AS feature, a BGP speaker can be physically in one AS and acts as such to some neighbors while it appears to be another AS to other neighbors. When sending and receiving AS_PATH to and from neighbors with Local AS configured, BGP prepends the Local AS to the real AS. For these neighbors, BGP uses the Local AS as the remote AS in the configuration. Thus, the Local AS number appears as if it were another AS inserted between the two real autonomous systems.
Figure 4-5 shows an example. When AS 2 is configured on AS 200 as a Local AS, the AS_PATH is prepended with AS 2 for updates from AS 100. When AS 100 receives updates from AS 200, the AS_PATH is prepended with AS 2.
)
Figure
4-5 AS_PATH Updates with Local AS
NOTE
Local AS can be used together with peer groups, but it cannot be customized for individual peers in a peer group. Local AS cannot have the local BGP AS number or the remote peer's AS number. The local-as command is valid only if the peer is a true eBGP peer. It does not work for two peers in different member autonomous systems in a confederation.
Example 4-29 shows a sample BGP configuration in AS 200 border routers for Figure 4-5. 192.168.1.1 is the IP address of a BGP speaker in AS 100. On 192.168.1.1, 2 instead of 200 is configured as the remote AS (not shown).
Example 4-29 Sample Local AS Configuration in AS 200
router bgp 200 neighbor 192.168.1.1 remote-as 100 neighbor 192.168.1.1 local-as 2
Figure 4-6 shows another example of Local AS. In this case, AS 200 is configured with Local AS with two remote autonomous systems, AS 100 and AS 300. When AS 200 border routers advertise prefix 172.16.0.0/16 to AS 300, the AS_PATH is 2 200 2 100. Because loop detection is done only for incoming updates from an eBGP peer, this AS_PATH is not considered a condition of a loop. AS 300 accepts the prefix because it does not detect any loop of AS 300. Similarly, AS 100 accepts prefix 10.0.0.0/8. Multiple occurrences of the Local AS number in the eBGP updates indicate more than one point of Local AS sessions.
)
Figure
4-6 Local AS in Two Connections
NOTE
When Local AS is used, the AS_PATH length becomes longer. If AS_PATH length is used as a deciding factor in selecting preference, AS_PATH prepending might be needed on other paths so that path selection is not affected.
During AS migration, it is possible that some routers are in the original AS and others are in the new AS. When a border router is migrated to the new AS and is configured with Local AS to remote peers, the updates from this border router to other routers that are still in the old AS are denied, because the other routers detect an AS_PATH loop.
Figure 4-7 shows what happens. Before the migration, both R1 and R3 are in AS 2. When R1 is migrated to AS 200 (the new AS), the Local AS is configured with R2 in AS 100. When R3 receives the prefix 172.16.0.0/16, it detects its own AS in the AS_PATH, and the update is denied. Example 4-30 shows the output of debug ip bgp update in on R3.
)
Figure
4-7 Updates Denied on R3 with Local AS on R1
Example 4-30 Loop Detection on R3 as Captured by debug ip bgp update in
*Apr 22 04:59:32.563 UTC: BGP(0): 192.168.13.1 rcv UPDATE w/ attr: nexthop 192.168.13.1, origin i, originator 0.0.0.0, path 200 2 100, community , extended
community *Apr 22 04:59:32.563 UTC: BGP(0): 192.168.13.1 rcv UPDATE about 172.16.0.0/16 -- DENIED due to: AS-PATH contains our own AS;
As mentioned previously, loop detection is performed on the inbound of an eBGP session. Because the session between R1 and R3 is now eBGP, this detection is enforced.
The solution to the problem is to add the no-prepend option to the local-as command. With this option, R1 does not prepend its Local AS number to the update received from R2. For this example, the AS_PATH to R3 is then 200 100. The update is acceptable to R3. The case study near the end of this chapter provides a more-detailed discussion of how to migrate an AS using the Local AS feature.