prepending 2 bytes of zeros....

Mon Oct 24 19:02:21 UTC 2005

At 03:46 AM 25/10/2005, bmanning at vacation.karoshi.com wrote:

>I am greatful to Geoff for his consistant ability to get me interested in
>breaking things...   so, for the assembled mutlitude, what would the impact
>on various peers be if I was to change my orign AS (ok, so i'll have to
>change the router code on my end to support this) from
>
>         4554
>
>         to
>
>         00004554
>
>Any ideas on how IOS (various flavors) will deal w/ this?  (yes, there is
>some lab work to do first, but i don' think there is a comprehensive enough
>lab to cover the full range of possibilities...)

So lets say you are running a BGP version that supports 4-Byte AS code, and 
you local AS is 4554

When you open a session with your BGP peer (using in this case 4554 in the 
2-byte My AS field of the OPEN packet) you will send a BGP capacility 
advertisement to your peer, indicating your willingness to exchange 4-Byte 
AS numbers with your peer.

At this stage IOS (various flavours) do not (to my limited knowledge) 
support this capability, so you will not get a positive response to your 
capability announcement, so you are now on a NEW / OLD transition boundary. 
Your BGP will now operate in this NEW / OLD transition mode. The behaviour 
now depends on whether you are an isolated 0:4554 island, or whether there 
are any 4-Byte AS's that directly peer with your AS.

In the former case you will strip off the leading zero 2-Byte fields from 
your BGP Updates when you pass them to your BGP peer

The the latter case the action will vary, depending on whether the 4-Byte 
AS's in the path are all zero-strippable or not. In the latter case the 
UPDATES will cause a NEW_AS_PATH attribute to be added to the UPDATES you 
generate. in the former case its zero stripping.

So does this answer your question?

   Geoff