Heads-up for IS-IS development
Hello everyone, just to provide a heads-up, I am currently working on some enhancements to the FRR IS-IS implementation, in the first place there is the addition of MT support according to RFC5120. Also, I would like to reimplement the serializer/deserializer for the wireformat of the IS-IS PDUs as the current implementation is not very robust and not very extensible. That new serializer/deserializer can then also be used as a basis to make the regeneration of LSP fragments more efficient. I'll be on the technical call today, feel free to give any comments or ask any questions you might have there, or to inquire here on the list. All Best, Christian
Hello, On 04/04/2017 04:05 PM, Christian Franke wrote:
just to provide a heads-up, I am currently working on some enhancements to the FRR IS-IS implementation, in the first place there is the addition of MT support according to RFC5120.
There has been some progress on this. There is a tree at https://github.com/opensourcerouting/frr/tree/vol-isis-mt which provides the MT implementation. While the MT implementation itself is fairly complete and should support any number of topologies, there is currently little flexibility in the import/export of ip reachability information: if the ipv6-unicast topology is enabled, it will be used to flood and calculate ipv6 forwarding information as it is commonly done on other platforms. I will look into the current work on OSPF multi topology to see if/how we could do this with more flexibility. The branch also requires some cleanup and a few more knobs, but it might already be interesting to play around with/look at. If you do, I would be glad about any feedback that you can give. All Best, Christian
Hi folks, I’ve noticed that since fpm was converted to a module (couple of weeks ago), I’m not able to establish any fpm connection. Looks like this is a consequence of fpm-module not being initialized. Am i missing something here? (yes, I’m building with —enable-fpm). (gdb) bt #0 frr_init () at libfrr.c:345 #1 0x00005555555671fd in main (argc=7, argv=0x7fffffffece8) at main.c:293 (gdb) p frrmod_list $20 = (struct frrmod_runtime *) 0x7ffff7dd5ac0 <frrmod_default> (gdb) p *frrmod_list $21 = { next = 0x5555557b3480 <_frrmod_this_module>, info = 0x7ffff7dd5ec0 <frrmod_default_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 } (gdb) p *frrmod_list->next $22 = { next = 0x0, info = 0x5555557b2000 <_frrmod_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 } Also, CLI doesn’t like this instruction anymore: lnos-x1-mellonox-up(config)# fpm connection ip 127.0.0.1 port 2620 % [ZEBRA] Unknown command: fpm connection ip 127.0.0.1 port 2620 Thanks. /Rodny
Found the missing piece :-) /usr/lib/frr/zebra -s 90000000 --daemon -A 127.0.0.1 -M fpm /Rodny
On Apr 15, 2017, at 3:48 PM, Rodny Molina <rodnymolina@gmail.com> wrote:
Hi folks,
I’ve noticed that since fpm was converted to a module (couple of weeks ago), I’m not able to establish any fpm connection. Looks like this is a consequence of fpm-module not being initialized. Am i missing something here? (yes, I’m building with —enable-fpm).
(gdb) bt #0 frr_init () at libfrr.c:345 #1 0x00005555555671fd in main (argc=7, argv=0x7fffffffece8) at main.c:293
(gdb) p frrmod_list $20 = (struct frrmod_runtime *) 0x7ffff7dd5ac0 <frrmod_default>
(gdb) p *frrmod_list $21 = { next = 0x5555557b3480 <_frrmod_this_module>, info = 0x7ffff7dd5ec0 <frrmod_default_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 }
(gdb) p *frrmod_list->next $22 = { next = 0x0, info = 0x5555557b2000 <_frrmod_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 }
Also, CLI doesn’t like this instruction anymore:
lnos-x1-mellonox-up(config)# fpm connection ip 127.0.0.1 port 2620 % [ZEBRA] Unknown command: fpm connection ip 127.0.0.1 port 2620
Thanks.
/Rodny
Good to know, thank you for posting your findings. I would find it really cool if module (re)loading could be done through the cli at runtime and the modules to load would be stored in the configuration instead of passing them in at startup time via argument. I think it should be possible if the module load statements are written out very early in the config, e.g. after the frr version/default statement, but I guess it night make config parsing slightly harder since registered commands might change in a relevant way while processing it. -Chris On Apr 16, 2017 1:14 AM, "Rodny Molina" <rodnymolina@gmail.com> wrote: Found the missing piece :-) /usr/lib/frr/zebra -s 90000000 --daemon -A 127.0.0.1 -M fpm /Rodny On Apr 15, 2017, at 3:48 PM, Rodny Molina <rodnymolina@gmail.com> wrote: Hi folks, I’ve noticed that since fpm was converted to a module (couple of weeks ago), I’m not able to establish any fpm connection. Looks like this is a consequence of fpm-module not being initialized. Am i missing something here? (yes, I’m building with —enable-fpm). (gdb) bt #0 frr_init () at libfrr.c:345 #1 0x00005555555671fd in main (argc=7, argv=0x7fffffffece8) at main.c:293 (gdb) p frrmod_list $20 = (struct frrmod_runtime *) 0x7ffff7dd5ac0 <frrmod_default> (gdb) p *frrmod_list $21 = { next = 0x5555557b3480 <_frrmod_this_module>, info = 0x7ffff7dd5ec0 <frrmod_default_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 } (gdb) p *frrmod_list->next $22 = { next = 0x0, info = 0x5555557b2000 <_frrmod_info>, dl_handle = 0x0, finished_loading = true, load_name = 0x0, load_args = 0x0 } Also, CLI doesn’t like this instruction anymore: lnos-x1-mellonox-up(config)# fpm connection ip 127.0.0.1 port 2620 % [ZEBRA] Unknown command: fpm connection ip 127.0.0.1 port 2620 Thanks. /Rodny _______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (2)
-
Christian Franke -
Rodny Molina