North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: prepending 2 bytes of zeros....

  • From: Geoff Huston
  • Date: Mon Oct 24 15:03:41 2005 
At 03:46 AM 25/10/2005, bmanning@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