We have completed the upgrade of IEOC! All posts, comments and user profiles have been migrated. For security reasons, we have reset all passwords. To set a new password please Click Here. Further updates soon to follow.

BGP Local-AS

I'm a little confused by the last part of this explanation:

 

"If you specify the no-prepend keyword, any routes received from the eBGP peer will not have <OldAS> prepended upon reception. By default, the AS number specified with the local-as
command (<OldAS>) is prepended to all updates received, to avoid
potential routing loops. However, this may cause problems with partial
transitions, when part of your AS is using the new AS number, and
another part is still using the old AS number. The routers using the old
number will reject such updates because the same AS number is present
in AS_PATH."

 

In the example given, R1 is using the old ASN (100) and R4 and R6 are transitioned over to the new ASN (146).  If you implement the local-as feature without the "no-prepend" option, I can see that EBGP-learned prefixes from R4 and R6 do indeed have the old ASN (100) prepended on inbound updates.  To test this, I advertised R7's loop0 interface into BGP, and I can see that R6 does indeed prepend AS 100 to the prefix when it learns it in from R7:

R6#show ip bgp 150.1.7.7
  100 300
    155.1.67.7 from 155.1.67.7 (150.1.7.7)

However, I DON'T understand how this would stop R1 from installing the path, as the AS-Path is only checked on inbound EBGP-learned prefixes, and from R1's perspective, R6 is an IBGP neighbor.  To verify, I can go to R1 and see that it has indeed installed the route, despite the fact that it contains its own ASN:

R1# show ip bgp 150.1.7.7
BGP routing table entry for 150.1.7.7/32, version 167
  100 300
    155.1.67.7 (metric 307200) from 155.1.146.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Basically, I agree with what the lesson says about how the prepending feature works, but I don't agree with what the lesson seems to be saying about why you would use it.

The only scenario where I could see this statement potentially being true would be if the AS was segmented, and BGP routers were learning these routes from an EBGP peer that connects the disparate parts of the AS.  In that case though, it will affect ALL routes learned from the other portion of the segmented AS, not just the EBGP-learned routes.  In that case, you could potentially enable one segment of the divided AS to learn EBGP-learned prefixes that were learned in from the other segment of the AS, but it seems unlikely that you would do so.  The reason for that is because you won't be able to learn any of the locally advertised prefixes from that other segment of the AS, as they will still have the local-AS number in them, and therefore, it's likely that you already had to use the allow-as-in feature.  I suppose it's possible that you want to be able to use the remote section of the divided AS for transit only, without any connectivity to prefixed inside the AS, but that seems highly unlikely.

 

Any additional insights would be appreciated!

Sign In or Register to comment.