North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: prepending 2 bytes of zeros....
At 03:46 AM 25/10/2005, [email protected] 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?