Removing Private ASNs restriction

Hello, 

According to CCIE R&S Official Cert Guide vol. 2, "if the ASN of the eBGP peer is in the current AS_PATH, the private ASNs will not be removed, either."

Can someone please explain what is the point of this restriction, since an eBGP peer will discard a prefix anyway if it sees its own AS number in the AS-PATH?

Many thanks, 

Cristian

Comments

  • HI Martinl

    It's on Chapter 2, BGP Routing Policies. 

    I'm reading it in the PDF format, it's on page 156, the Removing Private ASNs section. 

    Kind regards, 

    Cristian

  • Hi,

    Assuming local router runs in AS 400:

       "remove-private-as" will remove all private AS's in the AS-path up until the very first public AS number; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009 and 65004, thus when it sends the update, the AS path will be 400 300 200 65005 600 (initial version of this feature)

          "remove-private-as all" will remove all private AS's in the AS-path; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009, 65004 and 65005, thus when it sends the update, the AS path will be 400 300 200 600 (second version of this feture, allowing to remove all private AS's)

          "remove-private-as all replace-as" will remove all private AS's in the AS-path and replace it with local router AS; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009, 65004, 65005 and replace it with 400, thus when it sends the update, the AS path will be 400 400 400 300 200 400 600 (enhanced second version allowing to keep the AS path length)

    Regards,

    Cristian.

     

     

  • Very good explanation mate! [Y]

     

    Hi,

    Assuming local router runs in AS 400:

       "remove-private-as" will remove all private AS's in the AS-path up until the very first public AS number; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009 and 65004, thus when it sends the update, the AS path will be 400 300 200 65005 600 (initial version of this feature)

          "remove-private-as all" will remove all private AS's in the AS-path; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009, 65004 and 65005, thus when it sends the update, the AS path will be 400 300 200 600 (second version of this feture, allowing to remove all private AS's)

          "remove-private-as all replace-as" will remove all private AS's in the AS-path and replace it with local router AS; if the AS path was 65009 65004 300 200 65005 600, it will remove 65009, 65004, 65005 and replace it with 400, thus when it sends the update, the AS path will be 400 400 400 300 200 400 600 (enhanced second version allowing to keep the AS path length)

    Regards,

    Cristian.

     

     

     

  • JoeMJoeM ✭✭✭

    Yes. Great explanation!   Easy to remember.

  • Hi Cristian, 

    Very interesting point, thanks for the explanation. 

     

  • Because it's easier to copy/paste from old book.

    Sent from my iPhone

    On Apr 15, 2015, at 05:23, Martinl <[email protected]> wrote:

    Yes, What I don't understand why authors of the book did not update chapter/paragraph to reflect new ios 15 options.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Hi Martinl and Cristian, 

    Thank you for the very good observations. 

    However, I don't feel that my initial question has been clarified yet.

    If we consider the three restrictions for pre-15.1 removal of private ASNs, what's the purpose of the third one and can someone think of a (real-life) scenario in which it could prove to be useful?

    1. Private ASNs can be removed only at the point of sending an eBGP Update.

    2. If the current AS_SEQ contains both private and public ASNs, the private ASNs will not be removed.

    3. If the ASN of the eBGP peer is in the current AS_PATH, the private ASNs will not be removed, either.

    First of all, this third restriction doesn’t really make sense when a public ASN peers with another public ASN, because in this case rule number two would apply anyway (the AS_SEQ would contain both public (the ASN of the eBGP peer) and private ASNs). Secondly, even if we peer a public ASN with a private one, a router would reject a prefix if its own ASN is listed in the AS_SEQ (so I guess we would need an allowas-in command).

    The only way I can see it come into play is for a peering between a public and a private ASN, but this would defeat the purpose of the removal of private ASNs feature, wouldn't it?

    Many thanks, 

    Cristian

     

  • Hi,

    The explanation for the third bullet is plain simple, avoid loops. If you have like this: R1(AS65009) being eBGP peer with R2(AS300) and R2 being eBGP peer with R3(As65009), R2 CANNOT remove private-AS's from the AS-path when sending updates to R1 or R3 cause that could lead to loops (R2 being the service provider needs to make sure it does not create loops). Yes, you can fix this by going to R1 and R3 and configuring allowas-in, but at that point you as the customer/client choose to fix this, at the same time accepting the possibility for loops.

    Regards,

    Cristian.

  • Hi Cristian, 

    Thank you for the quick reply, it's much clearer now. 

    Kind regards, 

    Cristian

  • I forgot to add that, however, if you use the "all" keyword, the private AS is removed even if the eBGP neighbor private AS number is in the AS path. 

Sign In or Register to comment.