IEOC - INE's Online Community

Welcome to INE's Online Community - IEOC - a place for CCIE and CCENT candidates to connect, share, and learn. Our Online Community features CCIE forums and discussions for all tracks including Routing & Switching, Voice, Security, Service Provider, Wireless,, and Storage. Through these online communities you can discuss your questions with thousands of your peers, hundreds of CCIE's and INE's own team of world renowned CCIE instructors and authors, Brian Dennis - Quintuple CCIE #2210, Brian McGahan – Triple CCIE #8593, Petr Lapukhov - Quad CCIE #16379, and Mark Snow - Dual CCIE #14073.
Latest post 01-11-2017 10:44 AM by CCIEDad. 0 replies.
Page 1 of 1 (1 items)
Sort Posts: Previous Next
  • 01-11-2017 10:44 AM

    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
      100 300 from (

    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
    BGP routing table entry for, version 167
      100 300 (metric 307200) from (
          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!

    • Post Points: 5
Page 1 of 1 (1 items)
IEOC CCIE Forums Internetwork Expert CCIE Training
About IEOC | Terms of Use | RSS | Privacy Policy
© 2010 Internetwork Expert, Inc. All Rights Reserved