[afnog] 32 bit ASN

[Mark Tinka]

On Friday, January 28, 2011 01:19:14 am Geert Jan de Groot 
wrote:

> The question raises whether one should not only ask one's
> upstream bot also the upstream of the upstream, whether
> 32-bit ASNs are safe.

The chain would essentially follow this line of logic, yes. 
But...

> This would essentially block deployment of 32-bit ASNs
> as certainly someone "would feel uneasy", and time to
> upgrade equipment, after several years, has now run out.

... agree. It's not feasible to ask your upstream's 
upstream's upstream's upstream's upstream's upstream's 
upstream... and so on and so on... to wire up for native 32-
bit ASN support.

> I stand with my original statement that only the BGP
> originator *must* be 32-bits capable to initiate the BGP
> announcements. For it's peers it is desirable
> (otherwise, all it's peers will look the same, AS23456),
> but nothing breaks. This is a specific property of the
> design chosen for this. This was tested, and I believe
> it to be safe.

I tend to agree, since it's not reasonable to expect all 
networks in a path to natively support 4-byte ASN's today.

However, one probably wants to keep in mind that upstream 
routers may still be running vulnerable code that breaks BGP 
or crashes a box when all the conditions line up. I'd 
actually caution operators to check this when they get a 
turn-up request from their sales team and the customer's BGP 
ASN is 32-bits long. It's not hard.

> I am surprized about the lack of knowledge from vendors
> on this. If your box talks BGP then all of this
> shouldn't be a surprise, and perhaps we can learn from
> eachother whom to contact to get clueful responses and,
> hopefully, working images.

Well, support from Cisco, Juniper and Brocade is already 
there for various platforms, as well as the fix for the 
issues we've seen already.

The issue now is when operators can add support for it into 
their networks. In most cases, it'll just be a software 
upgrade. In some cases (may be rare, haven't really 
checked), very old and unsupported platforms may not have 
been exposed to this feature enhancement.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20110128/80208ad6/attachment.pgp>