Support for 4B ASN in BGP
Hello Here is a patch adding 4B ASN support to BGP. It is slightly tested and mostly complete. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi!
is there any git repo for the new patches that have recently appeared?
I hope it will be working in a couple of days. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth If the government wants us to respect the law, it should set a better example.
Martin Kraus wrote:
On Mon, Oct 06, 2008 at 01:21:54AM +0200, Ondrej Zajicek wrote:
Hello
Here is a patch adding 4B ASN support to BGP. It is slightly tested and mostly complete.
is there any git repo for the new patches that have recently appeared? thanks
Or even some snapshot files with the patches added. I really like to update the FreeBSD port with the new patches recently added. /Xavier
Hello!
Here is a patch adding 4B ASN support to BGP. It is slightly tested and mostly complete.
Thanks for the patch. I see only a couple of minor issues with it:
+ return dst - dst_start; +} + + + void
Please do not add too much whitespace.
+#define AS_TRANS 23456
This deserves a comment.
+ { NULL, }, /* BA_EXTENDED_COMM */ + { "as4_path", -1, BAF_OPTIONAL | BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_AS4_PATH */ + bgp_check_as4_path, NULL }, + { "as4_aggregator", 8, BAF_OPTIONAL | BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_AS4_PATH */ + NULL, NULL } };
+/* BA_AS4_PATH is type EAF_TYPE_OPAQUE and not type EAF_TYPE_AS_PATH because + * EAF_TYPE_AS_PATH is supposed to have different format (2 or 4 B for each ASN) + * depending on bgp_as4_support variable. + */ +
Does this make sense? Wouldn't it be better to have a single extended attribute format and convert as necessary? Or, if we decide that we should prefer saving space over simplicity, define a new type for the extended paths.
+ if ((code == BA_AGGREGATOR) && bgp_as4_support && (! p->as4_support))
What is the global setting of `bgp_as4_support' for? Shouldn't it be always a per-instance setting? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Ctrl and Alt keys stuck -- press Del to continue.
On Mon, Oct 06, 2008 at 01:13:21PM +0200, Martin Mares wrote:
+ return dst - dst_start; +} + + + void
Please do not add too much whitespace.
+#define AS_TRANS 23456
This deserves a comment.
OK, i will add some.
+ { NULL, }, /* BA_EXTENDED_COMM */ + { "as4_path", -1, BAF_OPTIONAL | BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_AS4_PATH */ + bgp_check_as4_path, NULL }, + { "as4_aggregator", 8, BAF_OPTIONAL | BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_AS4_PATH */ + NULL, NULL } };
+/* BA_AS4_PATH is type EAF_TYPE_OPAQUE and not type EAF_TYPE_AS_PATH because + * EAF_TYPE_AS_PATH is supposed to have different format (2 or 4 B for each ASN) + * depending on bgp_as4_support variable. + */ +
Does this make sense? Wouldn't it be better to have a single extended attribute format and convert as necessary?
Or, if we decide that we should prefer saving space over simplicity, define a new type for the extended paths. ...
+ if ((code == BA_AGGREGATOR) && bgp_as4_support && (! p->as4_support))
What is the global setting of `bgp_as4_support' for? Shouldn't it be always a per-instance setting?
The 4B ASN support is implemented to always store AS_PATH in native representation and convert it during communication with neighbors. Although in some situations (like having more 4B-non-aware neighbors) this implementation might lead to unnecessary converting compared to lazy variant, i think it is much simpler and therefore error-proof becouse otherwise we have to do reconstruction of real 4B PATH in many places (like filter code, printing ...). Variable 'bgp_as4_support' decides whether this router support 4B ASN or not. It is possible to disable 4B ASN support (using global option 'disable_bgp_as4') (for example for testing or to workaround a bug in the neighbor implementation of 4B ASN) but it shouldn't be neccessary to change this setting. When bgs_as4_support is enabled, then native representation of AS_PATH (type EAF_TYPE_AS_PATH) is 4 B per ASN, otherwise it is 2 B per ASN. The extended attribute AS4_PATH is used only when 4B-aware and 4B-non-aware routers communicate together. If BIRD is 4B-aware, then it discards such attribute ASAP, and when BIRD is not 4B-aware, it is opaque attribute for it. Different possible implemementation would be to have two types: EAF_TYPE_AS2_PATH and EAF_TYPE_AS4_PATH (used for paths with 2 B per ASN and 4 B per ASN). This variant is probably cleaner, but more complicated to implement and does not give us much advantages. The problem with current implementation is that it is not easy to support more bgp instances with different 'bgp_as4_support' and also to change 'bgp_as4_support' during soft reconfiguration. But the option is unnecessary during a normal usage and therefore i don't see this as a big problem. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi!
Although in some situations (like having more 4B-non-aware neighbors) this implementation might lead to unnecessary converting compared to lazy variant, i think it is much simpler and therefore error-proof becouse otherwise we have to do reconstruction of real 4B PATH in many places (like filter code, printing ...).
Well, keeping all paths in the routing table in a single format would have the advantage that the filters wouldn't need to care about the 2B/4B issues at all, which looks simpler to me. The conversion between the format has to be implemented anyway, so we can convert on both input and output in BGP and let the rest of BIRD use a common format. The only disadvantage of this approach I see is that we waste memory on storing paths with 16-bit AS numbers in the 32-bit format. However, it is likely that in the future everybody will have to use 32-bit AS numbers anyway, so it does not make sense to optimize for the 16-bit case too much.
Variable 'bgp_as4_support' decides whether this router support 4B ASN or not. It is possible to disable 4B ASN support (using global option 'disable_bgp_as4') (for example for testing or to workaround a bug in the neighbor implementation of 4B ASN) but it shouldn't be neccessary to change this setting. When bgs_as4_support is enabled, then native representation of AS_PATH (type EAF_TYPE_AS_PATH) is 4 B per ASN, otherwise it is 2 B per ASN.
I would really like to have this configurable per protocol instance -- when you want to work around a bug, you usually do not wish to disable the feature for the whole router, but only for the particular neighbor.
The extended attribute AS4_PATH is used only when 4B-aware and 4B-non-aware routers communicate together. If BIRD is 4B-aware, then it discards such attribute ASAP, and when BIRD is not 4B-aware, it is opaque attribute for it.
I have missed the fact that the attribute is only temporary at the first reading. As a temporary attribute, it can well be opaque, but we should convert it to a common fixed format as soon as possible. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth DRM 'manages access' in the same way that jail 'manages freedom.'
Hello On Mon, Oct 06, 2008 at 02:53:27PM +0200, Martin Mares wrote:
Variable 'bgp_as4_support' decides whether this router support 4B ASN or not. It is possible to disable 4B ASN support (using global option 'disable_bgp_as4') (for example for testing or to workaround a bug in the neighbor implementation of 4B ASN) but it shouldn't be neccessary to change this setting. When bgs_as4_support is enabled, then native representation of AS_PATH (type EAF_TYPE_AS_PATH) is 4 B per ASN, otherwise it is 2 B per ASN.
I would really like to have this configurable per protocol instance -- when you want to work around a bug, you usually do not wish to disable the feature for the whole router, but only for the particular neighbor.
I will think about it.
The extended attribute AS4_PATH is used only when 4B-aware and 4B-non-aware routers communicate together. If BIRD is 4B-aware, then it discards such attribute ASAP, and when BIRD is not 4B-aware, it is opaque attribute for it.
I have missed the fact that the attribute is only temporary at the first reading.
As a temporary attribute, it can well be opaque, but we should convert it to a common fixed format as soon as possible.
It is not converted - if BIRD is 4B-aware, then it is used (together with 2B AS_PATH) to reconstruct real AS_PATH and then immediately discarded. if BIRD is not 4B-aware, then BIRD should handle it as unknown optional transitive atribute. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello!
It is not converted - if BIRD is 4B-aware, then it is used (together with 2B AS_PATH) to reconstruct real AS_PATH and then immediately discarded. if BIRD is not 4B-aware, then BIRD should handle it as unknown optional transitive atribute.
This however does not work with per-instance 4B-awareness. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Nothing is smiple enough to be not screwed up.
On Mon, Oct 06, 2008 at 03:10:16PM +0200, Martin Mares wrote:
Hello!
It is not converted - if BIRD is 4B-aware, then it is used (together with 2B AS_PATH) to reconstruct real AS_PATH and then immediately discarded. if BIRD is not 4B-aware, then BIRD should handle it as unknown optional transitive atribute.
This however does not work with per-instance 4B-awareness.
Per-instance 4B-awareness might be implemented easily by just not advertising that capability (and ignoring such advertisement from that neighbor). That would force 2B-based communication with neighbor, but otherwise we can process it like 4B-aware BGP speaker (reconstruct 4B path from AS_PATH and AS4_PATH and use 4B path as internal representation). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello!
Per-instance 4B-awareness might be implemented easily by just not advertising that capability (and ignoring such advertisement from that neighbor). That would force 2B-based communication with neighbor, but otherwise we can process it like 4B-aware BGP speaker (reconstruct 4B path from AS_PATH and AS4_PATH and use 4B path as internal representation).
OK. So we do not need to store it as a opaque attribute at all (except temporarily during decoding of the update). Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
participants (4)
-
Martin Kraus -
Martin Mares -
Ondrej Zajicek -
Xavier Beaudouin