From shamita1010 at gmail.com Thu Feb 1 01:25:49 2007 From: shamita1010 at gmail.com (shamita pisal) Date: Thu, 1 Feb 2007 01:25:49 -0800 Subject: [Xorp-hackers] suggest a debugger for xorp. Message-ID: hi, We are studying the xorp source code .We want to find how xorp communicates with internal modules.(It does through Xrl as documented) but we want to find the functions which calls another modules and how it stores states as well.Also how the routing table entries stored? We want to study the packet flow inside xorp.(through internal modules:how it reads packet from kernel and processing in the xorp then forwarding it to destination address) So this is possible by debugging the code of xorp. Could you please suggest a tool for debugging source code. Thanking you Shamita. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070201/5d1644c6/attachment.html From oho at acm.org Thu Feb 1 07:42:51 2007 From: oho at acm.org (Orion Hodson) Date: Thu, 1 Feb 2007 07:42:51 -0800 Subject: [Xorp-hackers] suggest a debugger for xorp. In-Reply-To: References: Message-ID: <6BD3EC3A-3BB7-48EA-AC6C-4274FC27F570@acm.org> With regards tracing, there is inbuilt tracing of XRLs, though it only logs via XORP standard logging facility (xlog - see libxorp/xlog. [ch] ) Defining XRLDISPATCHTRACE turns on client side tracing. Defining XRLTRACE turns on server side tracing. To see some more switches controllable through the environment try: cd xorp/libxipc grep getenv *.cc There are no explicit states associated with XRL interfaces. You might also want to familiarize yourselves with gprof and gdb. - Orion On Feb 1, 2007, at 1:25 AM, shamita pisal wrote: > hi, > We are studying the xorp source code .We want to find how xorp > communicates with internal modules.(It does through Xrl as > documented) but we want to find the functions which calls another > modules and how it stores states as well.Also how the routing table > entries stored? > We want to study the packet flow inside xorp.(through internal > modules:how it reads packet from kernel and processing in the xorp > then forwarding it to destination address) So this is possible by > debugging the code of xorp. Could you please suggest a tool for > debugging source code. > > Thanking you > Shamita. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From shamita1010 at gmail.com Wed Feb 7 04:59:50 2007 From: shamita1010 at gmail.com (shamita pisal) Date: Wed, 7 Feb 2007 18:29:50 +0530 Subject: [Xorp-hackers] PIM-Bidir - PIM-SM Message-ID: We (a team of four people) wish to implement pim-bidir on xorp.Thearchitecture of xorp had been studied in detail.Also the source code is studied in detail. Earlier it was decided to build a separate module of PIM-Bidir in xorp which will inherit some of the features of PIM-SM.But now after a detailed discussion we are giving a thought to implementing PIM-Bidir in PIM-SM module itself, Making a few changes(eg:DF election instead of DR,RPA election,Packet forwarding rules,the config file.) Pim-Bidir being a variant of PIM-SM only a few changes are required to be done.The PIm-Bidir can use a "switch" i.e if PIM_SM enabled then ... if PIM-bidir enabled then... Could you please give your opinion on this and validate our point. Thanking you in anticipation, Ashish Karpe. Chintamani Wandhare. Shamita Pisal. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070207/14d75d3d/attachment.html From pavlin at icir.org Thu Feb 8 11:02:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 08 Feb 2007 11:02:52 -0800 Subject: [Xorp-hackers] PIM-Bidir - PIM-SM In-Reply-To: Message from "shamita pisal" of "Wed, 07 Feb 2007 18:29:50 +0530." Message-ID: <200702081902.l18J2qVq073434@possum.icir.org> shamita pisal wrote: > We (a team of four people) wish to implement pim-bidir on > xorp.Thearchitecture of xorp had been studied in > detail.Also the source code is studied in detail. > > Earlier it was decided to build a separate module of PIM-Bidir in xorp which > will inherit some of the features of PIM-SM.But now after a detailed > discussion we are giving a thought to implementing PIM-Bidir in PIM-SM > module itself, Making a few changes(eg:DF election instead of DR,RPA > election,Packet forwarding rules,the config file.) Pim-Bidir being a variant > of PIM-SM only a few changes are required to be done.The PIm-Bidir can use a > "switch" > i.e > if PIM_SM enabled then ... > > if PIM-bidir enabled then... > > Could you please give your opinion on this and validate our point. Yes, I believe that implementing PIM-Bidir inside the PIM-SM module is the right approach, because they have too many things in common. Code-wise, as a result of that you need to use conditional statements similar to the one you mentioned above. Configuration-wise, the default setup should be to run PIM-SM in "vanilla" mode (i.e., no PIM-Bidir enabled). A simple switch like "enable-bidir: true/false" (or a more complicated configuration block) should be used to enable/activate the PIM-Bidir processing. It has been a while since I read the Bidir spec in details, so you need to decide whether this switch has to be per network interface or a single switch for the whole PIM-SM module. Regards, Pavlin > Thanking you in anticipation, > Ashish Karpe. > Chintamani Wandhare. > Shamita Pisal. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ashishkarpe at gmail.com Mon Feb 12 22:59:41 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Tue, 13 Feb 2007 12:29:41 +0530 Subject: [Xorp-hackers] Query regarding XRL's Message-ID: Hi all, We want to add a xrl interface for our module(pim bidir). We followed the steps as mentioned in the document "Adding Process To XORP". We wrote a /xrl/interface/pimbidir.xif and /xrl/target/pimbidir.tgt also we modified makefiles in each of directory.But files (.cc & .hh) which were suppose to generated by Python Scripts are not genetated. The modifications we did are follows : In File /xrl/interfaces/makefile.am # PIMBIDIR Interface noinst_LTLIBRARIES += libpimbidirxif.la libpimbidirxif_la_SOURCES = pimbidir_xif.hh pimbidir_xif.cc In File /xrl/targets/makefile.am .. .. tgt_files += pimbidir.tgt .. .. noinst_LTLIBRARIES += libpimbidirbase.la .. .. # PIMBIDIR libpimbidirbase_la_SOURCES = pimbidir_base.hh pimbidir_base.cc $(srcdir)/pimbidir_base.hh $(srcdir)/pimbidir_base.cc: \ $(INTERFACES_DIR)/common.xif \ $(INTERFACES_DIR)/cli_processor.xif \ $(INTERFACES_DIR)/finder_event_observer.xif \ $(INTERFACES_DIR)/mfea_client.xif \ $(INTERFACES_DIR)/redist_transaction4.xif \ $(INTERFACES_DIR)/redist_transaction6.xif \ $(INTERFACES_DIR)/mld6igmp_client.xif \ $(INTERFACES_DIR)/pimbidir.xif .. .. .. So will you please let us know what may the problem in generation of .cc & .hh files? Thanking You Ashish From pavlin at icir.org Tue Feb 13 10:26:19 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 13 Feb 2007 10:26:19 -0800 Subject: [Xorp-hackers] Query regarding XRL's In-Reply-To: Message from "Ashish Karpe" of "Tue, 13 Feb 2007 12:29:41 +0530." Message-ID: <200702131826.l1DIQJHP040014@possum.icir.org> Ashish Karpe wrote: > Hi all, > We want to add a xrl interface for our module(pim bidir). > We followed the steps as mentioned in the document "Adding Process To XORP". > We wrote a /xrl/interface/pimbidir.xif > and /xrl/target/pimbidir.tgt > also we modified makefiles in each of directory.But files (.cc & .hh) > which were suppose to generated by Python Scripts are not genetated. > The modifications we did are follows : > > > In File /xrl/interfaces/makefile.am > > # PIMBIDIR Interface > noinst_LTLIBRARIES += libpimbidirxif.la > libpimbidirxif_la_SOURCES = pimbidir_xif.hh pimbidir_xif.cc > > In File /xrl/targets/makefile.am > .. > .. > tgt_files += pimbidir.tgt > .. > .. > noinst_LTLIBRARIES += libpimbidirbase.la > .. > .. > # PIMBIDIR > libpimbidirbase_la_SOURCES = pimbidir_base.hh pimbidir_base.cc > $(srcdir)/pimbidir_base.hh $(srcdir)/pimbidir_base.cc: > \ > $(INTERFACES_DIR)/common.xif \ > $(INTERFACES_DIR)/cli_processor.xif \ > $(INTERFACES_DIR)/finder_event_observer.xif \ > $(INTERFACES_DIR)/mfea_client.xif \ > $(INTERFACES_DIR)/redist_transaction4.xif \ > $(INTERFACES_DIR)/redist_transaction6.xif \ > $(INTERFACES_DIR)/mld6igmp_client.xif \ > $(INTERFACES_DIR)/pimbidir.xif > .. > .. > .. > > > So will you please let us know what may the problem in generation of > .cc & .hh files? Did you run ./bootstrap from the top-level XORP directory? This will generate Makefile.in from the Makefile.am files. Then running ./configure will generate the final Makefile from Makefile.in. Note that you must have installed the autoconf/automake/libtool tools for ./bootstrap to work. Also, see README for the versions of the tools we are using. It is best to install exactly same versions, otherwise there is no guarantee that it will work. Regards, Pavlin > Thanking You > Ashish > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ashishkarpe at gmail.com Tue Feb 13 12:28:59 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Tue, 13 Feb 2007 12:28:59 -0800 Subject: [Xorp-hackers] PIM-Bidir - PIM-SM In-Reply-To: <200702121919.l1CJJW7b025339@possum.icir.org> References: <200702121919.l1CJJW7b025339@possum.icir.org> Message-ID: On 2/12/07, Pavlin Radoslavov wrote: > > Thanks for your precious guidance. we have one more doubt- how do we > > enable-bidir in config file ? > > > > 1) We are planning to add pimbidir(enable) flag in > > /xorp/etc/template/pimsm4.tp & commands in /xorp/etc/template/pim.cmd > > 2) we are not able to find out how we can catch this enable flag in the > > pimsm module? > > so that we can achieve switching in between modules!!! > > Will you please how it works in the pimsm node!! > > we have gone through the documentation of adding process to Xorp but > > still we did not get the pin-pointed information in this regard. > > Check how a flag like enable-ip-router-alert-option-check has been > implemented. Of course, you need to add a new XRL to enable/disable > the Bidir functionality. > We tried to find enable-ip-router-alert-option-check has been implemented but we are not able to get it exactly. We even tried debuging using DDD(degugger). We placed break points in /xorp/rtrmgr/main_rtrmgr.cc in try{} where it reads config file !! But couldn't understand how actually it reads xorp/etc/templets/pimsm.tp file to crate MasterTempalteTree ( tt ) and compare/manipulate it _mct(Master Config Tree ) i.e we are not able to get mechnasim of how it gets enable-ip-router-alert-option-check flag from config file and pass it on to pimsm module !! It will be very helpfull if someone clears us about this flow & also how should be our approach in achieving it !! Thank you, Ashish Karpe. Chintamani Wandhare. Shamita Pisal. > Hope that helps, > Pavlin > > > > > Thanking you in anticipation, > > > Ashish Karpe. > > > Chintamani Wandhare. > > > Shamita Pisal. > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers at icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > From pavlin at icir.org Tue Feb 13 12:44:17 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 13 Feb 2007 12:44:17 -0800 Subject: [Xorp-hackers] PIM-Bidir - PIM-SM In-Reply-To: Message from "Ashish Karpe" of "Tue, 13 Feb 2007 12:28:59 PST." Message-ID: <200702132044.l1DKiHQn041152@possum.icir.org> > On 2/12/07, Pavlin Radoslavov wrote: > > > Thanks for your precious guidance. we have one more doubt- how do we > > > enable-bidir in config file ? > > > > > > 1) We are planning to add pimbidir(enable) flag in > > > /xorp/etc/template/pimsm4.tp & commands in /xorp/etc/template/pim.cmd > > > 2) we are not able to find out how we can catch this enable flag in the > > > pimsm module? > > > so that we can achieve switching in between modules!!! > > > Will you please how it works in the pimsm node!! > > > we have gone through the documentation of adding process to Xorp but > > > still we did not get the pin-pointed information in this regard. > > > > Check how a flag like enable-ip-router-alert-option-check has been > > implemented. Of course, you need to add a new XRL to enable/disable > > the Bidir functionality. > > > We tried to find enable-ip-router-alert-option-check has been > implemented but we are not able to get it exactly. We even tried > debuging using DDD(degugger). We placed break points in > /xorp/rtrmgr/main_rtrmgr.cc in try{} where it reads config file !! > But couldn't understand how actually it reads > xorp/etc/templets/pimsm.tp file to crate MasterTempalteTree ( tt ) and > compare/manipulate it _mct(Master Config Tree ) i.e we are not able to > get mechnasim of how it gets enable-ip-router-alert-option-check flag > from config file and pass it on to pimsm module !! > It will be very helpfull if someone clears us about this flow & > also how should be our approach in achieving it !! You don't need to do all this to implement a new rtrmgr template option. The rtrmgr is generic when it comes to the content of the template files. All it does is parses the template nodes in the configuration tree and associates action with each node: e.g., XRL to send when this configuration node is created or modified, etc. All you need to do is add something like the following to pimsm4.tp: protocols { pimsm4 { /* .... */ enable-bidir: bool = false; /* ... */ } } protocols { pimsm4 { /* .... */ enable-bidir { %help: short "Enable PIM-Bidir"; %create: xrl "$(pimsm4.targetname)/pim/0.1/enable_bidir?enable:bool=$(@)"; %set: xrl "$(pimsm4.targetname)/pim/0.1/enable_bidir?enable:bool=$(@)"; %delete: xrl "$(pimsm4.targetname)/pim/0.1/enable_bidir?enable:bool=$(DEFAULT)"; } /* ... */ } } This adds a single enable-bidir flag per PIM-SM instance. If you want the flag to be per vif, then you need to move the flag inside the pimsm4/interface/vif node (and of course to modify the XRL arguments). Again, see how it is done with the enable-ip-router-alert-option-check flag. Of course, you also need to specify and implement the new pim/0.1/enable_bidir XRL. FYI, If you want to see all XRLs that are generated (including the XRLs like the one above that are used for configuration), then you need to set the XRLTRACE environmental variable before starting xorp_rtrmgr. Though, this might generate lots of output so you need to save it to a file before analyzing it. Regards, Pavlin From M.Handley at cs.ucl.ac.uk Tue Feb 13 12:56:05 2007 From: M.Handley at cs.ucl.ac.uk (Mark Handley) Date: Tue, 13 Feb 2007 20:56:05 +0000 Subject: [Xorp-hackers] PIM-Bidir - PIM-SM In-Reply-To: References: <200702121919.l1CJJW7b025339@possum.icir.org> Message-ID: <84a612dd0702131256x297e8ac1x29302e6ed6c9b2d6@mail.gmail.com> The XORP design docs are here: http://www.xorp.org/design_docs.html Most of your questions are answered in the rtrmgr design document. Once you understand how the rtrmgr works, then read "An Introduction to Writing a XORP Process", also available from the design docs page. This explains how .xif files work. The XRLs in the rtrmgr template file need to be ones in the target process's .xif file. Then look in xrl/interfaces/pim.xif to see PIM's .xif file. - Mark On 2/13/07, Ashish Karpe wrote: > On 2/12/07, Pavlin Radoslavov wrote: > > > Thanks for your precious guidance. we have one more doubt- how do we > > > enable-bidir in config file ? > > > > > > 1) We are planning to add pimbidir(enable) flag in > > > /xorp/etc/template/pimsm4.tp & commands in /xorp/etc/template/pim.cmd > > > 2) we are not able to find out how we can catch this enable flag in the > > > pimsm module? > > > so that we can achieve switching in between modules!!! > > > Will you please how it works in the pimsm node!! > > > we have gone through the documentation of adding process to Xorp but > > > still we did not get the pin-pointed information in this regard. > > > > Check how a flag like enable-ip-router-alert-option-check has been > > implemented. Of course, you need to add a new XRL to enable/disable > > the Bidir functionality. > > > We tried to find enable-ip-router-alert-option-check has been > implemented but we are not able to get it exactly. We even tried > debuging using DDD(degugger). We placed break points in > /xorp/rtrmgr/main_rtrmgr.cc in try{} where it reads config file !! > But couldn't understand how actually it reads > xorp/etc/templets/pimsm.tp file to crate MasterTempalteTree ( tt ) and > compare/manipulate it _mct(Master Config Tree ) i.e we are not able to > get mechnasim of how it gets enable-ip-router-alert-option-check flag > from config file and pass it on to pimsm module !! > It will be very helpfull if someone clears us about this flow & > also how should be our approach in achieving it !! > > Thank you, > Ashish Karpe. > Chintamani Wandhare. > Shamita Pisal. > > > > Hope that helps, > > Pavlin > > > > > > > > Thanking you in anticipation, > > > > Ashish Karpe. > > > > Chintamani Wandhare. > > > > Shamita Pisal. > > > > _______________________________________________ > > > > Xorp-hackers mailing list > > > > Xorp-hackers at icir.org > > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From sachinutd at gmail.com Wed Feb 14 21:20:07 2007 From: sachinutd at gmail.com (Sachin K) Date: Wed, 14 Feb 2007 23:20:07 -0600 Subject: [Xorp-hackers] Multicast routing Message-ID: How does the XORP multicast router sniff IGMP/MLD messages from the network? I checked the some routers' code. Most of them just open a RAW socket with protocol set to IPPROTO_IGMP. But using this the router gets the packets addressed to 224.0.0.1 only. How does it receive IGMPv2 and IGMPv3 membership reports sent by other hosts? Thanks, Sachin From sureshkannan at gmail.com Thu Feb 15 00:12:18 2007 From: sureshkannan at gmail.com (Suresh kannan) Date: Thu, 15 Feb 2007 13:42:18 +0530 Subject: [Xorp-hackers] Multicast routing In-Reply-To: References: Message-ID: <84f679e0702150012p12c6893as32edc38b31906d69@mail.gmail.com> Hi Sachin, Opening RAW socket for IPPROTO_IGMP, will get all IGMP packets regardless of its destination address from kernel to XORP. Can i know, where it says it will only get 224.0.0.1 packets. I'm not aware such a filtering in RAW socket. Thanks, Regards, Suresh kannan. On 2/15/07, Sachin K wrote: > > How does the XORP multicast router sniff IGMP/MLD messages from the > network? > > I checked the some routers' code. Most of them just open a RAW socket with > protocol set to IPPROTO_IGMP. But using this the router gets the > packets addressed to 224.0.0.1 only. > > How does it receive IGMPv2 and IGMPv3 membership reports sent by other > hosts? > > Thanks, > > Sachin > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070215/647d3073/attachment.html From pavlin at icir.org Thu Feb 15 10:49:15 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 15 Feb 2007 10:49:15 -0800 Subject: [Xorp-hackers] Multicast routing In-Reply-To: Message from "Sachin K" of "Wed, 14 Feb 2007 23:20:07 CST." Message-ID: <200702151849.l1FInFAj061152@possum.icir.org> Sachin K wrote: > How does the XORP multicast router sniff IGMP/MLD messages from the network? > > I checked the some routers' code. Most of them just open a RAW socket with > protocol set to IPPROTO_IGMP. But using this the router gets the > packets addressed to 224.0.0.1 only. > > How does it receive IGMPv2 and IGMPv3 membership reports sent by other hosts? The kernel gets all multicast packets because the interface is set in ALLMULTI mode (i.e., snoop all multicast packets). This happens after the multicast routing socket has been opened with setsockopt(..., MRT_INIT, ...) and then each interface is added with setsockopt(..., MRT_ADD_VIF, ...). Then the userland program can receive the IGMP packets with opening a raw IPPROTO_IGMP socket. BTW, note that there could be only one multicast routing socket open at a time (across all processes). Regards, Pavlin From pavlin at icir.org Thu Feb 15 10:53:57 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 15 Feb 2007 10:53:57 -0800 Subject: [Xorp-hackers] Multicast routing In-Reply-To: Message from "Suresh kannan" of "Thu, 15 Feb 2007 13:42:18 +0530." <84f679e0702150012p12c6893as32edc38b31906d69@mail.gmail.com> Message-ID: <200702151853.l1FIrvoH061238@possum.icir.org> > Opening RAW socket for IPPROTO_IGMP, will get all IGMP packets regardless of > its destination address from kernel to XORP. I doubt this will happen if the interface wasn't in ALLMULTI state (see my previous email on the subject). > Can i know, where it says it will only get 224.0.0.1 packets. I'm not aware > such a filtering in RAW socket. The 224.0.0.1 packets are received only with the RAW socket because every host is a member of the 224.0.0.1 (ALL-SYSTEMS) multicast group (the kernel itself joins that group). For groups that have been joined the interface doesn't need to be in ALLMULTI state. Regards, Pavlin > Thanks, > Regards, > Suresh kannan. > > > On 2/15/07, Sachin K wrote: > > > > How does the XORP multicast router sniff IGMP/MLD messages from the > > network? > > > > I checked the some routers' code. Most of them just open a RAW socket with > > protocol set to IPPROTO_IGMP. But using this the router gets the > > packets addressed to 224.0.0.1 only. > > > > How does it receive IGMPv2 and IGMPv3 membership reports sent by other > > hosts? > > > > Thanks, > > > > Sachin > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ashishkarpe at gmail.com Fri Feb 16 07:54:59 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Fri, 16 Feb 2007 07:54:59 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. Message-ID: hi all, we are implementing the PIM-Bidir in Xorp.we have decided to implement bidir-flag per vif as suggested by Pavlin Sir in his last reply. For bidir mode we have to store only (*,G) entries.So after studying the following classes 1.PimMre (Pim_Mre.hh), 2.PimMribtable (Pim_Mrib_table), 3.PimMrt. Now as we are implementing the pim_bidir flag per "vif" then that perticular vif can be used for forwarding both type of packets i.e. pim sm and bidir. Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for the SM But as we are using same vif for both we need to know weather these entries are same for both? If they differ then How can we differentiate between them.? Thanking you in anticipation, Ashish. shamita. Chintamani. From pavlin at icir.org Fri Feb 16 12:52:05 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 16 Feb 2007 12:52:05 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "Ashish Karpe" of "Fri, 16 Feb 2007 07:54:59 PST." Message-ID: <200702162052.l1GKq5aj078360@possum.icir.org> > hi all, > we are implementing the PIM-Bidir in Xorp.we have decided to implement > bidir-flag per vif as suggested by Pavlin Sir in his last reply. To clarify: I didn't suggest that the flag has to be per vif, but let you decide that :) I intentionally didn't recommend whether the flag to be per vif or per PIM instance, because it has been a while since I read the PIM-Bidir spec and didn't remember what the spec said about incremental PIM-Bidir deployment. Anyway, I just had a quick look in the latest PIM-Bidir spec (draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec allows incremental PIM-Bidir deployment. The following email from one of the PIM-Bidir spec authors confirms that: http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html Actually, an earlier version of the PIM-Bidir spec (draft-ietf-pim-bidir-04.txt) had a section about incremental deployment, but this has been removed in -05: ==================================================== 5.2. Appendix B: Interoperability with legacy code The rules provided in [10] for interoperating between legacy PIM-SM routers and new bi-directional capable routers change only slightly to support this new proposal. The only difference is in the definition of a boundary between a bi-directional capable area and a legacy area of the network. In [10], a bidir capable router forwarding upstream, register encapsulates the data packet to the RP if its RPF neighbor is not bidir capable. In our proposal, since all the routers on a link need to co-operate to elect the Designated Forwarder, if even one of the routers on the link is a legacy router, the election cannot take place. As a result register encapsulation is necessary if one or more routers on the RPF interface are not bi-directional capable. As in [10], a Hello option must be used to differentiate between bi- directional capable and legacy routers, and (S,G) state must be created on the router doing the register encapsulation to prevent loops. ==================================================== The newer model seems to be that each multicast group is forwarded in PIM-SM or PIM-Bidir mode (see below). This suggests that a PIM router has to run in PIM-Bidir mode on all interfaces (or no interfaces), hence it makes more sence to have a single bidir-mode flag per PIM instance. It also seems consistent with the Cisco's "ip pim bidir-enable" configuration per PIM instance: http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html I couldn't find anything about PIM-Bidir in the Juniper documentation. > For bidir mode we have to store only (*,G) entries.So after studying > the following classes > > 1.PimMre (Pim_Mre.hh), > 2.PimMribtable (Pim_Mrib_table), > 3.PimMrt. > > Now as we are implementing the pim_bidir flag per "vif" then that > perticular vif can be used for forwarding both type of packets i.e. > pim sm and bidir. > > Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for the SM > But as we are using same vif for both we need to know weather these > entries are same for both? If they differ then How can we > differentiate between them.? Section "4. RP Discovery" in the PIM-Bidir spec (draft-ietf-pim-bidir-08.txt) says: ==================================================== 4. RP Discovery Routers discover that a range of multicast group addresses operates in bi-directional mode and the address of the Rendezvous-Point address (RPA) serving the group range either through static configuration or using an automatic RP discovery mechanism like the PIM Bootstrap mechanism (BSR) [9] or Auto-RP. ==================================================== Hence, each (*,G) entry needs to have a flag indicating whether it is in PIM-SM mode or PIM-Bidir mode. Regards, Pavlin From ashishkarpe at gmail.com Fri Feb 16 14:04:32 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Fri, 16 Feb 2007 14:04:32 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: <200702162052.l1GKq5aj078360@possum.icir.org> References: <200702162052.l1GKq5aj078360@possum.icir.org> Message-ID: hi, Thank you very much for showing us proper path & correcting us !! bty i have doubt about what do you really mean by routing instance !! Is it that there will be PimBidirNode which will keep all information ( about routing table , Vifs belonging to routing tables ,routing option configuration,etc). Is there any condition where multiple instances of same protocol (say PIM-SM) may exists on same router ? or Routing instance per PIM-SM means per router in domain ? Then now do we have to make completely new pimbidir4.tp file & PimBidirNode & implitment completely separate Bidir module which can inherit common functionality from PIM-SM :) ........... OR just use same pimsm4.tp & enable bidir flag in it (i.e Per PimSM instance ) & thn enable/call new/separate BidirNode from it which will maintain it own routing table , Vifs belonging to routing tables ,routing option configuration,etc !! Thank you, Ashish On 2/16/07, Pavlin Radoslavov wrote: > > hi all, > > we are implementing the PIM-Bidir in Xorp.we have decided to implement > > bidir-flag per vif as suggested by Pavlin Sir in his last reply. > > To clarify: I didn't suggest that the flag has to be per vif, but > let you decide that :) > I intentionally didn't recommend whether the flag to be per vif or > per PIM instance, because it has been a while since I read the > PIM-Bidir spec and didn't remember what the spec said about > incremental PIM-Bidir deployment. > > Anyway, I just had a quick look in the latest PIM-Bidir spec > (draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec > allows incremental PIM-Bidir deployment. The following email from > one of the PIM-Bidir spec authors confirms that: > > http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html > > Actually, an earlier version of the PIM-Bidir spec > (draft-ietf-pim-bidir-04.txt) had a section about incremental > deployment, but this has been removed in -05: > > ==================================================== > 5.2. Appendix B: Interoperability with legacy code > > The rules provided in [10] for interoperating between legacy PIM-SM > routers and new bi-directional capable routers change only slightly to > support this new proposal. The only difference is in the definition of a > boundary between a bi-directional capable area and a legacy area of the > network. In [10], a bidir capable router forwarding upstream, register > encapsulates the data packet to the RP if its RPF neighbor is not bidir > capable. > > In our proposal, since all the routers on a link need to co-operate to > elect the Designated Forwarder, if even one of the routers on the link > is a legacy router, the election cannot take place. As a result register > encapsulation is necessary if one or more routers on the RPF interface > are not bi-directional capable. > > As in [10], a Hello option must be used to differentiate between bi- > directional capable and legacy routers, and (S,G) state must be created > on the router doing the register encapsulation to prevent loops. > ==================================================== > > The newer model seems to be that each multicast group is forwarded > in PIM-SM or PIM-Bidir mode (see below). > > This suggests that a PIM router has to run in PIM-Bidir mode on all > interfaces (or no interfaces), hence it makes more sence to have a > single bidir-mode flag per PIM instance. > It also seems consistent with the Cisco's "ip pim bidir-enable" > configuration per PIM instance: > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html > > I couldn't find anything about PIM-Bidir in the Juniper > documentation. > > > For bidir mode we have to store only (*,G) entries.So after studying > > the following classes > > > > 1.PimMre (Pim_Mre.hh), > > 2.PimMribtable (Pim_Mrib_table), > > 3.PimMrt. > > > > Now as we are implementing the pim_bidir flag per "vif" then that > > perticular vif can be used for forwarding both type of packets i.e. > > pim sm and bidir. > > > > Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for the SM > > But as we are using same vif for both we need to know weather these > > entries are same for both? If they differ then How can we > > differentiate between them.? > > Section "4. RP Discovery" in the PIM-Bidir spec > (draft-ietf-pim-bidir-08.txt) says: > > ==================================================== > 4. RP Discovery > > Routers discover that a range of multicast group addresses operates in > bi-directional mode and the address of the Rendezvous-Point address > (RPA) serving the group range either through static configuration or > using an automatic RP discovery mechanism like the PIM Bootstrap > mechanism (BSR) [9] or Auto-RP. > ==================================================== > > Hence, each (*,G) entry needs to have a flag indicating whether it > is in PIM-SM mode or PIM-Bidir mode. > > Regards, > Pavlin > From ashishkarpe at gmail.com Fri Feb 16 15:05:02 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Fri, 16 Feb 2007 15:05:02 -0800 Subject: [Xorp-hackers] Query regarding XRL's In-Reply-To: <200702131826.l1DIQJHP040014@possum.icir.org> References: <200702131826.l1DIQJHP040014@possum.icir.org> Message-ID: > > Did you run ./bootstrap from the top-level XORP directory? > This will generate Makefile.in from the Makefile.am files. > Then running ./configure will generate the final Makefile from > Makefile.in. When i make new .tp file then after using ./bootstrap, thn ./configure, gamke , it works. but when i tried ./bootstrap (i modified existing .tp file didnt made new one), tried gmake it worked but when i used ./bootsrap gave me error (in short ./bootstrap spoiled my scource code coz now gmake fails event after making gmake clean/distclean) !! So is there any way to revert action done by ./bootstrap ?? :) My installed libtool version is : (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) According to Readme required is - libtool version 1.3.4 ******************************************************************************** Error Shown : linux-m4ij:/home/xorp/Desktop/project/bidir-enable/xorp-1.3 # gmake gmake all-recursive gmake[1]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3' Making all in libxorp gmake[2]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3/libxorp' gmake all-am gmake[3]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3/libxorp' if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wbad-function-cast -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -pipe -MT debug.lo -MD -MP -MF ".deps/debug.Tpo" -c -o debug.lo debug.c; \ then mv -f ".deps/debug.Tpo" ".deps/debug.Plo"; else rm -f ".deps/debug.Tpo"; exit 1; fi libtool: unrecognized option `--tag=CC' Try `libtool --help' for more information. gmake[3]: *** [debug.lo] Error 1 gmake[3]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3/libxorp' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3/libxorp' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3' gmake: *** [all] Error 2 ******************************************************************************* > Note that you must have installed the autoconf/automake/libtool > tools for ./bootstrap to work. > Also, see README for the versions of the tools we are using. It is > best to install exactly same versions, otherwise there is no > guarantee that it will work. > > Regards, > Pavlin > On 2/13/07, Pavlin Radoslavov wrote: > Ashish Karpe wrote: > > > Hi all, > > We want to add a xrl interface for our module(pim bidir). > > We followed the steps as mentioned in the document "Adding Process To XORP". > > We wrote a /xrl/interface/pimbidir.xif > > and /xrl/target/pimbidir.tgt > > also we modified makefiles in each of directory.But files (.cc & .hh) > > which were suppose to generated by Python Scripts are not genetated. > > The modifications we did are follows : > > > > > > In File /xrl/interfaces/makefile.am > > > > # PIMBIDIR Interface > > noinst_LTLIBRARIES += libpimbidirxif.la > > libpimbidirxif_la_SOURCES = pimbidir_xif.hh pimbidir_xif.cc > > > > In File /xrl/targets/makefile.am > > .. > > .. > > tgt_files += pimbidir.tgt > > .. > > .. > > noinst_LTLIBRARIES += libpimbidirbase.la > > .. > > .. > > # PIMBIDIR > > libpimbidirbase_la_SOURCES = pimbidir_base.hh pimbidir_base.cc > > $(srcdir)/pimbidir_base.hh $(srcdir)/pimbidir_base.cc: > > \ > > $(INTERFACES_DIR)/common.xif \ > > $(INTERFACES_DIR)/cli_processor.xif \ > > $(INTERFACES_DIR)/finder_event_observer.xif \ > > $(INTERFACES_DIR)/mfea_client.xif \ > > $(INTERFACES_DIR)/redist_transaction4.xif \ > > $(INTERFACES_DIR)/redist_transaction6.xif \ > > $(INTERFACES_DIR)/mld6igmp_client.xif \ > > $(INTERFACES_DIR)/pimbidir.xif > > .. > > .. > > .. > > > > > > So will you please let us know what may the problem in generation of > > .cc & .hh files? > > Thanking You > > Ashish > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070216/61ef8c52/attachment.html From pavlin at icir.org Fri Feb 16 15:42:45 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 16 Feb 2007 15:42:45 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "Ashish Karpe" of "Fri, 16 Feb 2007 14:04:32 PST." Message-ID: <200702162342.l1GNgjQH080362@possum.icir.org> > bty i have doubt about what do you really mean by routing > instance !! Is it that there will be PimBidirNode which will keep all > information ( about routing table , Vifs belonging to routing tables > ,routing option configuration,etc). I assume there will be a PimNode that will have its flag "is_bidir" flag set to true or false. Most of the existing code inside PimNode won't be modified. Only where the PIM-SM and PIM-Bidir processing is different, the "is_bidir()" method can be used to differentiate between them. The implementation details can be different from what I describe above, but I don't see the reason for duplicating most of the stuff from PimNode to PimBidirNode. Also, have in mind that the is_bidir flag might be changed on-the-fly (via xorpsh), so your code needs to take this into account. > Is there any condition where multiple instances of same > protocol (say PIM-SM) may exists on same router ? or Routing instance > per PIM-SM means per router in domain ? In the future we would like to run multiple protocol instances (or even XORP instances), but we are not there yet. > Then now do we have to make completely new pimbidir4.tp file & > PimBidirNode & implitment completely separate Bidir module which can > inherit common functionality from PIM-SM :) ........... OR just use > same pimsm4.tp & enable bidir flag in it (i.e Per PimSM instance ) & > thn enable/call new/separate BidirNode from it which will maintain it > own routing table , Vifs belonging to routing tables ,routing option > configuration,etc !! Just same pimsm4.tp with enable-bidir flag in it. Changing this flag (e.g., via xorpsh) will invoke the appropriate XRL that will change the "is_bidir" flag inside PimNode. Regards, Pavlin > Thank you, > Ashish > > On 2/16/07, Pavlin Radoslavov wrote: > > > hi all, > > > we are implementing the PIM-Bidir in Xorp.we have decided to implement > > > bidir-flag per vif as suggested by Pavlin Sir in his last reply. > > > > To clarify: I didn't suggest that the flag has to be per vif, but > > let you decide that :) > > I intentionally didn't recommend whether the flag to be per vif or > > per PIM instance, because it has been a while since I read the > > PIM-Bidir spec and didn't remember what the spec said about > > incremental PIM-Bidir deployment. > > > > Anyway, I just had a quick look in the latest PIM-Bidir spec > > (draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec > > allows incremental PIM-Bidir deployment. The following email from > > one of the PIM-Bidir spec authors confirms that: > > > > http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html > > > > Actually, an earlier version of the PIM-Bidir spec > > (draft-ietf-pim-bidir-04.txt) had a section about incremental > > deployment, but this has been removed in -05: > > > > ==================================================== > > 5.2. Appendix B: Interoperability with legacy code > > > > The rules provided in [10] for interoperating between legacy PIM-SM > > routers and new bi-directional capable routers change only slightly to > > support this new proposal. The only difference is in the definition of a > > boundary between a bi-directional capable area and a legacy area of the > > network. In [10], a bidir capable router forwarding upstream, register > > encapsulates the data packet to the RP if its RPF neighbor is not bidir > > capable. > > > > In our proposal, since all the routers on a link need to co-operate to > > elect the Designated Forwarder, if even one of the routers on the link > > is a legacy router, the election cannot take place. As a result register > > encapsulation is necessary if one or more routers on the RPF interface > > are not bi-directional capable. > > > > As in [10], a Hello option must be used to differentiate between bi- > > directional capable and legacy routers, and (S,G) state must be created > > on the router doing the register encapsulation to prevent loops. > > ==================================================== > > > > The newer model seems to be that each multicast group is forwarded > > in PIM-SM or PIM-Bidir mode (see below). > > > > This suggests that a PIM router has to run in PIM-Bidir mode on all > > interfaces (or no interfaces), hence it makes more sence to have a > > single bidir-mode flag per PIM instance. > > It also seems consistent with the Cisco's "ip pim bidir-enable" > > configuration per PIM instance: > > > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html > > > > I couldn't find anything about PIM-Bidir in the Juniper > > documentation. > > > > > For bidir mode we have to store only (*,G) entries.So after studying > > > the following classes > > > > > > 1.PimMre (Pim_Mre.hh), > > > 2.PimMribtable (Pim_Mrib_table), > > > 3.PimMrt. > > > > > > Now as we are implementing the pim_bidir flag per "vif" then that > > > perticular vif can be used for forwarding both type of packets i.e. > > > pim sm and bidir. > > > > > > Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for the SM > > > But as we are using same vif for both we need to know weather these > > > entries are same for both? If they differ then How can we > > > differentiate between them.? > > > > Section "4. RP Discovery" in the PIM-Bidir spec > > (draft-ietf-pim-bidir-08.txt) says: > > > > ==================================================== > > 4. RP Discovery > > > > Routers discover that a range of multicast group addresses operates in > > bi-directional mode and the address of the Rendezvous-Point address > > (RPA) serving the group range either through static configuration or > > using an automatic RP discovery mechanism like the PIM Bootstrap > > mechanism (BSR) [9] or Auto-RP. > > ==================================================== > > > > Hence, each (*,G) entry needs to have a flag indicating whether it > > is in PIM-SM mode or PIM-Bidir mode. > > > > Regards, > > Pavlin > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Fri Feb 16 15:53:50 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 16 Feb 2007 15:53:50 -0800 Subject: [Xorp-hackers] Query regarding XRL's In-Reply-To: Message from "Ashish Karpe" of "Fri, 16 Feb 2007 15:05:02 PST." Message-ID: <200702162353.l1GNroNB080480@possum.icir.org> > > Did you run ./bootstrap from the top-level XORP directory? > > This will generate Makefile.in from the Makefile.am files. > > Then running ./configure will generate the final Makefile from > > Makefile.in. > When i make new .tp file then after using ./bootstrap, thn ./configure, > gamke , it works. > but when i tried ./bootstrap (i modified existing .tp file didnt made new > one), tried gmake it worked but when i used ./bootsrap gave me error (in > short ./bootstrap spoiled my scource code coz now gmake fails event after > making gmake clean/distclean) !! If you just modified an existing *.tp file there is no need to run ./bootstrap. Typically you need to run ./bootstap only if you modify a Makefile.am or configure.in file. > So is there any way to revert action done by ./bootstrap ?? :) Not trivially. If you are using XORP CVS code (from anon CVS), then "cvs update -d -P" and "cvs diff -u -p" will tell you which are the modified files so you can reverse only those files. E.g., if you delete a corrupted file then "cvs update -d -P" will bring it back from anon CVS. If you are using a release like xorp-1.3, then you need to run something like "diff -ur xorp.org xorp.new" to see the differences between the original and your code (where xorp.org and xorp.new are the directories with the original XORP code and your version). > My installed libtool version is : > > (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) > > According to Readme required is - libtool version 1.3.4 > > ******************************************************************************** > Error Shown : > > linux-m4ij:/home/xorp/Desktop/project/bidir-enable/xorp-1.3 # gmake > gmake all-recursive > gmake[1]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3' > Making all in libxorp > gmake[2]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3/libxorp' > gmake all-am > gmake[3]: Entering directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3/libxorp' > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. > -I.. -I.. -g -W -Wall -Wwrite-strings -Wbad-function-cast > -Wmissing-prototypes -Wcast-qual -Wmissing-declarations -Werror > -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -pipe -MT > debug.lo -MD -MP -MF ".deps/debug.Tpo" -c -o debug.lo debug.c; \ > then mv -f ".deps/debug.Tpo" ".deps/debug.Plo"; else rm -f > ".deps/debug.Tpo"; exit 1; fi > libtool: unrecognized option `--tag=CC' > Try `libtool --help' for more information. > gmake[3]: *** [debug.lo] Error 1 > gmake[3]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3/libxorp' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3/libxorp' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3' > gmake: *** [all] Error 2 > ******************************************************************************* Did you read the rest of my email, and more specifically the last sentence in the following paragraph? :) > > Note that you must have installed the autoconf/automake/libtool > > tools for ./bootstrap to work. > > Also, see README for the versions of the tools we are using. It is > > best to install exactly same versions, otherwise there is no > > guarantee that it will work. We are planning to update the autoconf/automake/libtool versions to something more recent, but in the mean time your best bet is to use the versions that are listed in README (or at least versions that are as close as possible to our versions). Regards, Pavlin From sachinutd at gmail.com Fri Feb 16 16:02:29 2007 From: sachinutd at gmail.com (Sachin K) Date: Fri, 16 Feb 2007 18:02:29 -0600 Subject: [Xorp-hackers] Multicast routing In-Reply-To: <200702151853.l1FIrvoH061238@possum.icir.org> References: <84f679e0702150012p12c6893as32edc38b31906d69@mail.gmail.com> <200702151853.l1FIrvoH061238@possum.icir.org> Message-ID: Hi all, I have added VIFs on all physical interfaces and getting the required IGMP messages to userspace. Now I add an MFC entry depending on IGMP message using setsockopt and MRT_ADD_MFC. Does this mean that kernel would do the multicast routing looking at the MFC? or do I need to do something more than adding an MFC entry. For example: [Host A]<--------> vif0 [Router] vif1 <-------> [Host B] [Router] adds vif0 and vif1 and is ready to process IGMP messages. [Host A] sends an IGMP membership report for (S,G) = (Host B, 232.10.10.10) [Router] adds an MFC entry with Iif = vif1 and Oif = vif0. [Host B] is sending multicast packets to 232.10.10.10. But [Host A] is not getting any packets. Note that I am running only my code on [Router], it has no pim or any sorts of standard routing daemons. What would be the problem? Do I need some more configuration on any of the systems? Thanks, Sachin On 2/15/07, Pavlin Radoslavov wrote: > > Opening RAW socket for IPPROTO_IGMP, will get all IGMP packets regardless of > > its destination address from kernel to XORP. > > I doubt this will happen if the interface wasn't in ALLMULTI state > (see my previous email on the subject). > > > Can i know, where it says it will only get 224.0.0.1 packets. I'm not aware > > such a filtering in RAW socket. > > The 224.0.0.1 packets are received only with the RAW socket because > every host is a member of the 224.0.0.1 (ALL-SYSTEMS) multicast > group (the kernel itself joins that group). For groups that have > been joined the interface doesn't need to be in ALLMULTI state. > > Regards, > Pavlin > > > Thanks, > > Regards, > > Suresh kannan. > > > > > > On 2/15/07, Sachin K wrote: > > > > > > How does the XORP multicast router sniff IGMP/MLD messages from the > > > network? > > > > > > I checked the some routers' code. Most of them just open a RAW socket with > > > protocol set to IPPROTO_IGMP. But using this the router gets the > > > packets addressed to 224.0.0.1 only. > > > > > > How does it receive IGMPv2 and IGMPv3 membership reports sent by other > > > hosts? > > > > > > Thanks, > > > > > > Sachin > > > > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers at icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From pavlin at icir.org Fri Feb 16 16:19:14 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 16 Feb 2007 16:19:14 -0800 Subject: [Xorp-hackers] Multicast routing In-Reply-To: Message from "Sachin K" of "Fri, 16 Feb 2007 18:02:29 CST." Message-ID: <200702170019.l1H0JEu0080735@possum.icir.org> > I have added VIFs on all physical interfaces and getting the required > IGMP messages to userspace. > > Now I add an MFC entry depending on IGMP message using setsockopt and > MRT_ADD_MFC. Does this mean that kernel would do the multicast > routing looking at the MFC? or do I need to do something more than > adding an MFC entry. > > For example: > > [Host A]<--------> vif0 [Router] vif1 <-------> [Host B] > > [Router] adds vif0 and vif1 and is ready to process IGMP messages. > > [Host A] sends an IGMP membership report for (S,G) = (Host B, 232.10.10.10) > > [Router] adds an MFC entry with Iif = vif1 and Oif = vif0. > > [Host B] is sending multicast packets to 232.10.10.10. > > But [Host A] is not getting any packets. Note that I am running only > my code on [Router], it has no pim or any sorts of standard routing > daemons. > > What would be the problem? Do I need some more configuration on any of > the systems? Do you see the multicast forwarding entries in the kernel with commands "netstat -gn" (for *BSD) or "cat /proc/net/ip_mr_cache" (for Linux), and do they have the right iif and oif set? Also, I presume that you used TTL of 1 for mfcc_ttls. If yes, then your program has done the right thing. In that case, make sure that the TTL of the multicast data packets as originated by the sender is at least 2. The default TTL is 1 and such packets won't be forwarded. Finally, if this didn't help, check whether there are any firewall rules that might be stopping the multicast packets. Regards, Pavlin From sachinutd at gmail.com Fri Feb 16 16:42:10 2007 From: sachinutd at gmail.com (Sachin K) Date: Fri, 16 Feb 2007 18:42:10 -0600 Subject: [Xorp-hackers] Multicast routing In-Reply-To: <200702170019.l1H0JEu0080735@possum.icir.org> References: <200702170019.l1H0JEu0080735@possum.icir.org> Message-ID: I am using Linux and the ip_mr_cache shows the following: Group Origin Iif Pkts Bytes Wrong Oifs 0A0A0AE8 00000000 0 0 0 0 1:1 Scenario: [Reciever<10.110.95.25>]<---> vif1 [<10.110.95.24>Router<172.16.1.1>] vif0 <----> [Sender<172.16.1.3>] I have set mfcc_ttls to 1 for the Oif and 0 for others. Basically I am using k_chg_mfc(socket, source, group, iif, oifs) from kern.c in pimd project. My Call: k_chg_mfc(igmp_socket, INADDR_ANY, igmph->group, 0, 2) Multicast datagrams are having a TTL value of 64 and the firewall is disable on all machines. I am not getting where I am going wrong. Thanks, Sachin On 2/16/07, Pavlin Radoslavov wrote: > > I have added VIFs on all physical interfaces and getting the required > > IGMP messages to userspace. > > > > Now I add an MFC entry depending on IGMP message using setsockopt and > > MRT_ADD_MFC. Does this mean that kernel would do the multicast > > routing looking at the MFC? or do I need to do something more than > > adding an MFC entry. > > > > For example: > > > > [Host A]<--------> vif0 [Router] vif1 <-------> [Host B] > > > > [Router] adds vif0 and vif1 and is ready to process IGMP messages. > > > > [Host A] sends an IGMP membership report for (S,G) = (Host B, 232.10.10.10) > > > > [Router] adds an MFC entry with Iif = vif1 and Oif = vif0. > > > > [Host B] is sending multicast packets to 232.10.10.10. > > > > But [Host A] is not getting any packets. Note that I am running only > > my code on [Router], it has no pim or any sorts of standard routing > > daemons. > > > > What would be the problem? Do I need some more configuration on any of > > the systems? > > Do you see the multicast forwarding entries in the kernel with > commands "netstat -gn" (for *BSD) or "cat /proc/net/ip_mr_cache" > (for Linux), and do they have the right iif and oif set? > Also, I presume that you used TTL of 1 for mfcc_ttls. > > If yes, then your program has done the right thing. > In that case, make sure that the TTL of the multicast data packets > as originated by the sender is at least 2. The default TTL is 1 and > such packets won't be forwarded. > Finally, if this didn't help, check whether there are any firewall > rules that might be stopping the multicast packets. > > Regards, > Pavlin > From pavlin at icir.org Fri Feb 16 16:51:45 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 16 Feb 2007 16:51:45 -0800 Subject: [Xorp-hackers] Multicast routing In-Reply-To: Message from "Sachin K" of "Fri, 16 Feb 2007 18:42:10 CST." Message-ID: <200702170051.l1H0pj4K081067@possum.icir.org> > I am using Linux and the ip_mr_cache shows the following: > > Group Origin Iif Pkts Bytes Wrong Oifs > 0A0A0AE8 00000000 0 0 0 0 1:1 > > Scenario: > [Reciever<10.110.95.25>]<---> vif1 [<10.110.95.24>Router<172.16.1.1>] > vif0 <----> [Sender<172.16.1.3>] > > I have set mfcc_ttls to 1 for the Oif and 0 for others. Basically I am using > k_chg_mfc(socket, source, group, iif, oifs) from kern.c in pimd project. > > My Call: > k_chg_mfc(igmp_socket, INADDR_ANY, igmph->group, 0, 2) > > Multicast datagrams are having a TTL value of 64 and the firewall is > disable on all machines. > > I am not getting where I am going wrong. You need to set the source address as well. The UNIX kernel doesn't support (*,G) forwarding entries where the source address is INADDR_ANY. If the Linux kernel didn't return an error (as it appears from the ip_mr_cache output), then this is a bug in the kernel. Regards, Pavlin From ashishkarpe at gmail.com Sat Feb 17 07:04:03 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Sat, 17 Feb 2007 07:04:03 -0800 Subject: [Xorp-hackers] error in setting bidir flag per node !!! Message-ID: hi , Due to previous discussion now we have decided to implement enable_bidir flag per PIMSM node !! For this purpose we used same ip_router_alert_option_check as reference !! Before this we had successfully managed to enable_bidir per Vif ( gmake worked :) ) ...... But now we tried to make it for Per PIMSM node (changes were made as per node ) but there is error !! Also we made the following changes in the file pim.xif to configure the pim_bidir flag per node. ============================================================= IN pim.xif --------------- get_pim_bidir? pim_bidir_name:txt -> enabled:bool set_pim_bidir ? pim_bidir_name:txt & enable:bool reset_pim_bidir ? pim_bidir_name:txt ============================================================= ============================================================================= IN xorp/etc/templates/pimsm4.tp ------------------------------- protocols { pimsm4 { targetname: txt = "PIMSM_4"; disable: toggle = false; enabled: bool; /* %deprecated */ enable-pim-bidir: bool = false; interface @: txt { vif @: txt { disable: toggle = false; enabled: bool; /* %deprecated */ enable-ip-router-alert-option-check: bool = false; dr-priority: u32 = 1; hello-period: u32 = 30; hello-triggered-delay: u32 = 5; alternative-subnet @: ipv4net { } } } } protocols { pimsm4 { ----- ----- ----- enable-pim-bidir { %help: short "Enable PIM-Bidir"; %create: xrl "$(pimsm4.targetname)/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@) enable:bool=$(@)"; %set: xrl "$(pimsm4.targetname )/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@)enable:bool=$(@)"; %delete: xrl "$(pimsm4.targetname )/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@)enable:bool=$(DEFAULT)"; } --------------- --------------- --------------- } =============================================================================== we also wrote the required functions in the xrl_pim_node.cc &.hh files. also the changes are made in file pim_node.cc by referring flag _ip_router_flag_check.but we take in the consideration that this flag is per node the changes are as follows. IN file xrl_pim_node.cc *-----------------------------------------------------*/ /*Modification for pim bidir*/ XrlCmdError XrlPimNode::pim_0_1_get_pim_bidir( // Input values, const string& pim_bidir_name, // Output values, bool& enabled) { string error_msg; bool v; if (PimNode::get_pim_bidir(pim_bidir_name, v, error_msg) != XORP_OK) { return XrlCmdError::COMMAND_FAILED(error_msg); } enabled = v; return XrlCmdError::OKAY(); } XrlCmdError XrlPimNode::pim_0_1_set_pim_bidir( // Input values, const string& pim_bidir_name, const bool& enable) { string error_msg; if (PimNode::set_pim_bidir(pim_bidir_name, enable, error_msg) != XORP_OK) { return XrlCmdError::COMMAND_FAILED(error_msg); } return XrlCmdError::OKAY(); } XrlCmdError XrlPimNode::pim_0_1_reset_pim_bidir( // Input values, const string& pim_bidir_name) { string error_msg; if (PimNode::reset_pim_bidir(pim_bidir_name, error_msg) != XORP_OK) { return XrlCmdError::COMMAND_FAILED(error_msg); } return XrlCmdError::OKAY(); } /*-----------------------------------------------------*/ IN file pim_node.cc PimNode::PimNode(int family, xorp_module_id module_id, EventLoop& eventloop) : ProtoNode(family, module_id, eventloop), _pim_mrt(*this), _pim_mrib_table(*this), _rp_table(*this), _pim_bidir(false), _pim_scope_zone_table(*this), _pim_bsr(*this), _is_switch_to_spt_enabled(false), // XXX: disabled by defailt _switch_to_spt_threshold_interval_sec(0), _switch_to_spt_threshold_bytes(0), _is_log_trace(false) .. .. .. IN file pim_node.hh /*------------------------------------------------------*/ /*modification for pim bidir*/ int get_pim_bidir(const string& pim_bidir_name, bool& enabled, string& error_msg); int set_pim_bidir(const string& pim_bidir_name, bool enable, string& error_msg); int reset_pim_bidir(const string& pim_bidir_name, string& error_msg); /*------------------------------------------------------*/ Error after gmake :- ------------------------------------------------ /.libs/libpim.a(xrl_pim_node.o): In function `XrlPimNode::pim_0_1_reset_pim_bidir(std::basic_string, std::allocator > const&)': /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5200: undefined reference to `PimNode::reset_pim_bidir(std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&)' ./.libs/libpim.a(xrl_pim_node.o): In function `XrlPimNode::pim_0_1_set_pim_bidir(std::basic_string, std::allocator > const&, bool const&)': /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5184: undefined reference to `PimNode::set_pim_bidir(std::basic_string, std::allocator > const&, bool, std::basic_string, std::allocator >&)' ./.libs/libpim.a(xrl_pim_node.o): In function `XrlPimNode::pim_0_1_get_pim_bidir(std::basic_string, std::allocator > const&, bool&)': /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5167: undefined reference to `PimNode::get_pim_bidir(std::basic_string, std::allocator > const&, bool&, std::basic_string, std::allocator >&)' collect2: ld returned 1 exit status gmake[2]: *** [xorp_pimsm4] Error 1 gmake[2]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3/pim' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- 1.3' gmake: *** [all] Error 2 can anyone let us know where might be the problem? !!! : ) Also which flag we should we use as refrence for per PIMSM node flags instead of ip_router_flag_check which is per Vif. Thank you, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070217/a5096858/attachment-0001.html From sachinutd at gmail.com Sat Feb 17 07:45:03 2007 From: sachinutd at gmail.com (Sachin K) Date: Sat, 17 Feb 2007 09:45:03 -0600 Subject: [Xorp-hackers] Multicast routing In-Reply-To: <200702170051.l1H0pj4K081067@possum.icir.org> References: <200702170051.l1H0pj4K081067@possum.icir.org> Message-ID: > You need to set the source address as well. Yes it worked when I specified the source. > The UNIX kernel doesn't support (*,G) forwarding entries where the > source address is INADDR_ANY. Does this imply Unix/Linux do not support ASM? If they do support ASM then what should be the source address in MFC entry? > If the Linux kernel didn't return an error (as it appears from the > ip_mr_cache output), then this is a bug in the kernel. I am not sure about this because there should be a way of supporting ASM on Linux. Thanks, Sachin From pavlin at icir.org Sat Feb 17 08:09:49 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 17 Feb 2007 08:09:49 -0800 Subject: [Xorp-hackers] error in setting bidir flag per node !!! In-Reply-To: Message from "Ashish Karpe" of "Sat, 17 Feb 2007 07:04:03 PST." Message-ID: <200702171609.l1HG9n21088551@possum.icir.org> > Due to previous discussion now we have decided to implement > enable_bidir flag per PIMSM node !! For this purpose we used same > ip_router_alert_option_check as reference !! Before this we had > successfully managed to enable_bidir per Vif ( gmake worked :) ) ...... > But now we tried to make it for Per PIMSM node (changes were made as per > node ) but there is error !! Also > > we made the following changes in the file pim.xif to configure the > pim_bidir flag > per node. What is the purpose of the "pim_bidir_name" argument? In your rtrmgr template file you set it to the value of the enable-pim-bidir flag, which is clearly wrong because pim_bidir_name has type "txt", while the value has boolean type. You don't need that argument, so you should remove it from everywhere. Regarding your gmake compilation/linkage error: did you implement the get/set/reset_pim_bidir methods inside PimNode? Regards, Pavlin > ============================================================= > IN pim.xif > --------------- > > > get_pim_bidir? pim_bidir_name:txt -> enabled:bool > set_pim_bidir ? pim_bidir_name:txt & enable:bool > reset_pim_bidir ? pim_bidir_name:txt > > > ============================================================= > > > > ============================================================================= > IN xorp/etc/templates/pimsm4.tp > ------------------------------- > > protocols { > pimsm4 { > targetname: txt = "PIMSM_4"; > disable: toggle = false; > enabled: bool; /* %deprecated */ > > > enable-pim-bidir: bool = false; > > > interface @: txt { > vif @: txt { > disable: toggle = false; > enabled: bool; /* %deprecated */ > enable-ip-router-alert-option-check: bool = false; > dr-priority: u32 = 1; > hello-period: u32 = 30; > hello-triggered-delay: u32 = 5; > alternative-subnet @: ipv4net { > } > } > } > > > > > > } > > protocols { > pimsm4 { > > ----- > ----- > ----- > > > enable-pim-bidir { > %help: short "Enable PIM-Bidir"; > %create: xrl > "$(pimsm4.targetname)/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@) > enable:bool=$(@)"; > %set: xrl "$(pimsm4.targetname > )/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@)enable:bool=$(@)"; > %delete: xrl "$(pimsm4.targetname > )/pim/0.1/enable_pim_bidir?pim_bidir_name:txt=$(@)enable:bool=$(DEFAULT)"; > } > > --------------- > --------------- > --------------- > } > =============================================================================== > > we also wrote the required functions in the xrl_pim_node.cc &.hh files. > also the changes are made in file pim_node.cc by referring flag > _ip_router_flag_check.but we take in the consideration that this flag is per > node the changes are as follows. > > > IN file xrl_pim_node.cc > *-----------------------------------------------------*/ > /*Modification for pim bidir*/ > > > XrlCmdError > XrlPimNode::pim_0_1_get_pim_bidir( > // Input values, > const string& pim_bidir_name, > // Output values, > bool& enabled) > { > string error_msg; > > bool v; > if (PimNode::get_pim_bidir(pim_bidir_name, v, error_msg) > != XORP_OK) { > return XrlCmdError::COMMAND_FAILED(error_msg); > } > > enabled = v; > return XrlCmdError::OKAY(); > } > > XrlCmdError > XrlPimNode::pim_0_1_set_pim_bidir( > // Input values, > const string& pim_bidir_name, > const bool& enable) > { > string error_msg; > > if (PimNode::set_pim_bidir(pim_bidir_name, enable, > error_msg) > != XORP_OK) { > return XrlCmdError::COMMAND_FAILED(error_msg); > } > > return XrlCmdError::OKAY(); > } > > XrlCmdError > XrlPimNode::pim_0_1_reset_pim_bidir( > // Input values, > const string& pim_bidir_name) > { > string error_msg; > > if (PimNode::reset_pim_bidir(pim_bidir_name, error_msg) > != XORP_OK) { > return XrlCmdError::COMMAND_FAILED(error_msg); > } > > return XrlCmdError::OKAY(); > } > > > /*-----------------------------------------------------*/ > > IN file pim_node.cc > > PimNode::PimNode(int family, xorp_module_id module_id, > EventLoop& eventloop) > : ProtoNode(family, module_id, eventloop), > > _pim_mrt(*this), > _pim_mrib_table(*this), > _rp_table(*this), > _pim_bidir(false), > _pim_scope_zone_table(*this), > _pim_bsr(*this), > _is_switch_to_spt_enabled(false), // XXX: disabled by defailt > > _switch_to_spt_threshold_interval_sec(0), > _switch_to_spt_threshold_bytes(0), > _is_log_trace(false) > .. > .. > .. > > IN file pim_node.hh > > /*------------------------------------------------------*/ > /*modification for pim bidir*/ > > int get_pim_bidir(const string& pim_bidir_name, > bool& enabled, > string& error_msg); > > > > int set_pim_bidir(const string& pim_bidir_name, > bool enable, > string& error_msg); > > > > int reset_pim_bidir(const string& pim_bidir_name, > string& error_msg); > > /*------------------------------------------------------*/ > > > Error after gmake :- > ------------------------------------------------ > /.libs/libpim.a(xrl_pim_node.o): In function > `XrlPimNode::pim_0_1_reset_pim_bidir(std::basic_string std::char_traits, std::allocator > const&)': > /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5200: > undefined reference to `PimNode::reset_pim_bidir(std::basic_string std::char_traits, std::allocator > const&, > std::basic_string, std::allocator >&)' > ./.libs/libpim.a(xrl_pim_node.o): In function > `XrlPimNode::pim_0_1_set_pim_bidir(std::basic_string std::char_traits, std::allocator > const&, bool const&)': > /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5184: > undefined reference to `PimNode::set_pim_bidir(std::basic_string std::char_traits, std::allocator > const&, bool, > std::basic_string, std::allocator >&)' > ./.libs/libpim.a(xrl_pim_node.o): In function > `XrlPimNode::pim_0_1_get_pim_bidir(std::basic_string std::char_traits, std::allocator > const&, bool&)': > /home/xorp/Desktop/project/bidir-enable/xorp-1.3/pim/xrl_pim_node.cc:5167: > undefined reference to `PimNode::get_pim_bidir(std::basic_string std::char_traits, std::allocator > const&, bool&, > std::basic_string, std::allocator >&)' > collect2: ld returned 1 exit status > gmake[2]: *** [xorp_pimsm4] Error 1 > gmake[2]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3/pim' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/xorp/Desktop/project/bidir-enable/xorp- > 1.3' > gmake: *** [all] Error 2 > > > can anyone let us know where might be the problem? !!! : ) > > Also which flag we should we use as refrence for per PIMSM node flags > instead of ip_router_flag_check which is per Vif. > > > > Thank you, > Ashish > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Sat Feb 17 08:26:02 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 17 Feb 2007 08:26:02 -0800 Subject: [Xorp-hackers] Multicast routing In-Reply-To: Message from "Sachin K" of "Sat, 17 Feb 2007 09:45:03 CST." Message-ID: <200702171626.l1HGQ27o088710@possum.icir.org> > > You need to set the source address as well. > > Yes it worked when I specified the source. > > > The UNIX kernel doesn't support (*,G) forwarding entries where the > > source address is INADDR_ANY. > > Does this imply Unix/Linux do not support ASM? If they do support ASM > then what should be the source address in MFC entry? UNIX (incl. Linux) do support ASM, but not the way you expect :) All ASM state in the routing level is mapped into (S,G) forwarding entries into the kernel. This is done by installing all (S,G) forwarding entries on-demand. When the first data packet from a new (S,G) dataflow arrives, the kernel sends IGMP_NOCACHE upcall to the userland. This upcall contains the source and group address. The userland program (e.g., XORP) will calculate the (expected) incoming interface and the outgoing interfaces and will take the appropriate action: e.g., install (S,G) MFC in the kernel even if the corresponding routing entry is (*,G). > > If the Linux kernel didn't return an error (as it appears from the > > ip_mr_cache output), then this is a bug in the kernel. > > I am not sure about this because there should be a way of supporting > ASM on Linux. See above. While on the subject. The reason that the UNIX/Linux kernel supports only (S,G) multicast forwarding entries is primarily historic, and it is possible to implement (*,G) support in the kernel. In fact, several years ago I did an experiment and it wasn't terribly difficult to implement it (both in kernel and userland). The kernel code is still available from http://netweb.usc.edu/pim/pimd/experimental/old/ and http://netweb.usc.edu/pim/pimd/experimental/old/pim-kernel-mfc-wc/ The userland code is still left in the last version of the now obsoleted pimd. Regards, Pavlin From shamita1010 at gmail.com Sun Feb 18 04:52:52 2007 From: shamita1010 at gmail.com (shamita pisal) Date: Sun, 18 Feb 2007 04:52:52 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: <200702162052.l1GKq5aj078360@possum.icir.org> References: <200702162052.l1GKq5aj078360@possum.icir.org> Message-ID: >Hence, each (*,G) entry needs to have a flag indicating whether it >is in PIM-SM mode or PIM-Bidir mode. >Regards, >Pavlin hi all, First of all thanks a lot for your precious guidance for our project. As per your reply regarding setting the bidir-bit so as to differentiate between the PIM-SM and PIM-Bidir (*,G) entries ,we are not very clear about how the (*,G) entries are stored in PIM_SM as per your implementation.(We tried searching for those in PIM_MRE.hh ,PIM.h,IPv4.h.)So we are unable to decide the setting of the Bidir-bit for (*,G) entries. Can we use a flag along with the (*,G) entries and store both of them together in the templates???? 2.)Also as per the PIM-SM RFC (Protocol Independent multicast-Sparse mode(PIM-SM):Protocol specification(Revised)) Encoded-Group addresses take the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group multicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... [B]idirectional PIM indicates the group range should use Bidirectional PIM [12]. For PIM-SM defined in this specification, this bit MUST be zero. We have a doubt as how the bidirectional bit is handled in PIM_SM and where exactly is it handled. 3.)Could we use the same templetes(MRT and MRE)as used in PIM-SM for storing the Tables for PIm-Bidir,or do you feel that writing our own templates would be easier???? 4.)Could you also elucidate the implementation of the Packet headers.(i.eplz tell the files in which we should be looking for it). Thanking you in anticipation, Shamita P. On 2/16/07, Pavlin Radoslavov wrote: > > > hi all, > > we are implementing the PIM-Bidir in Xorp.we have decided to implement > > bidir-flag per vif as suggested by Pavlin Sir in his last reply. > > To clarify: I didn't suggest that the flag has to be per vif, but > let you decide that :) > I intentionally didn't recommend whether the flag to be per vif or > per PIM instance, because it has been a while since I read the > PIM-Bidir spec and didn't remember what the spec said about > incremental PIM-Bidir deployment. > > Anyway, I just had a quick look in the latest PIM-Bidir spec > (draft-ietf-pim-bidir-08.txt), and it doesn't seem that the spec > allows incremental PIM-Bidir deployment. The following email from > one of the PIM-Bidir spec authors confirms that: > > http://www1.ietf.org/mail-archive/web/pim/current/msg00182.html > > Actually, an earlier version of the PIM-Bidir spec > (draft-ietf-pim-bidir-04.txt) had a section about incremental > deployment, but this has been removed in -05: > > ==================================================== > 5.2. Appendix B: Interoperability with legacy code > > The rules provided in [10] for interoperating between legacy PIM-SM > routers and new bi-directional capable routers change only slightly to > support this new proposal. The only difference is in the definition of a > boundary between a bi-directional capable area and a legacy area of the > network. In [10], a bidir capable router forwarding upstream, register > encapsulates the data packet to the RP if its RPF neighbor is not bidir > capable. > > In our proposal, since all the routers on a link need to co-operate to > elect the Designated Forwarder, if even one of the routers on the link > is a legacy router, the election cannot take place. As a result register > encapsulation is necessary if one or more routers on the RPF interface > are not bi-directional capable. > > As in [10], a Hello option must be used to differentiate between bi- > directional capable and legacy routers, and (S,G) state must be created > on the router doing the register encapsulation to prevent loops. > ==================================================== > > The newer model seems to be that each multicast group is forwarded > in PIM-SM or PIM-Bidir mode (see below). > > This suggests that a PIM router has to run in PIM-Bidir mode on all > interfaces (or no interfaces), hence it makes more sence to have a > single bidir-mode flag per PIM instance. > It also seems consistent with the Cisco's "ip pim bidir-enable" > configuration per PIM instance: > > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca796.html > > I couldn't find anything about PIM-Bidir in the Juniper > documentation. > > > For bidir mode we have to store only (*,G) entries.So after studying > > the following classes > > > > 1.PimMre (Pim_Mre.hh), > > 2.PimMribtable (Pim_Mrib_table), > > 3.PimMrt. > > > > Now as we are implementing the pim_bidir flag per "vif" then that > > perticular vif can be used for forwarding both type of packets i.e. > > pim sm and bidir. > > > > Pim Bidir uses only (*,G) entries.And also there are (*,G) entries for > the SM > > But as we are using same vif for both we need to know weather these > > entries are same for both? If they differ then How can we > > differentiate between them.? > > Section "4. RP Discovery" in the PIM-Bidir spec > (draft-ietf-pim-bidir-08.txt) says: > > ==================================================== > 4. RP Discovery > > Routers discover that a range of multicast group addresses operates in > bi-directional mode and the address of the Rendezvous-Point address > (RPA) serving the group range either through static configuration or > using an automatic RP discovery mechanism like the PIM Bootstrap > mechanism (BSR) [9] or Auto-RP. > ==================================================== > > Hence, each (*,G) entry needs to have a flag indicating whether it > is in PIM-SM mode or PIM-Bidir mode. > > Regards, > Pavlin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070218/52e6be24/attachment.html From guptalavi at gmail.com Sun Feb 18 13:20:34 2007 From: guptalavi at gmail.com (Pallavi Gupta) Date: Sun, 18 Feb 2007 13:20:34 -0800 Subject: [Xorp-hackers] Hello!, Help needed on RIP module in XORP Message-ID: <22e357c80702181320w3920dbd4q7355ae26c1572095@mail.gmail.com> Hello, I am a 4th year undergraduate student at a university in Canada. I am doing a research project based on RIP and I am using XORP for implementation of the changes that I intend to make in the protocol. I am trying to understand the XORP code and I was wondering if someone could point me out in the right direction. At the moment, I am trying to figure out how XORP processes the routing metrics during path selection, specifically for RIP. I intend to change the metric for RIP into a compound of Hop count and delay, if possible. Thanks soo much, in advance, for your time and help. Sincerely, Pallavi Gupta, -- "Little things make big differences in life" From pavlin at icir.org Sun Feb 18 13:24:27 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 18 Feb 2007 13:24:27 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "shamita pisal" of "Sun, 18 Feb 2007 04:52:52 PST." Message-ID: <200702182124.l1ILORgq092765@possum.icir.org> > As per your reply regarding setting the bidir-bit so as to differentiate > between the PIM-SM and PIM-Bidir (*,G) entries ,we are not very clear about > how the (*,G) entries are stored in PIM_SM as per your implementation.(We > tried searching for those in PIM_MRE.hh ,PIM.h,IPv4.h.)So we are unable to > decide the setting of the Bidir-bit for (*,G) entries. > > Can we use a flag along with the (*,G) entries and store both of them > together in the templates???? The PimMre class is defined in pim_mre.hh. This class is used for any type of multicast routing entries, so you have to add the bidir flag to that class. > 2.)Also as per the PIM-SM RFC (Protocol Independent multicast-Sparse > mode(PIM-SM):Protocol specification(Revised)) > Encoded-Group addresses take the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group multicast Address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... > > [B]idirectional PIM > indicates the group range should use Bidirectional PIM [12]. For > PIM-SM defined in this specification, this bit MUST be zero. > > We have a doubt as how the bidirectional bit is handled in PIM_SM and where > exactly is it handled. The Encoded-Group addresses are encoded/decoded by the PUT_ENCODED_GROUP_ADDR() and GET_ENCODED_GROUP_ADDR() macros defined inside pim_proto.h. Currently those macros don't implement the [B]idirectional PIM flag, so you need to modify them (and their usage). > 3.)Could we use the same templetes(MRT and MRE)as used in PIM-SM for > storing the Tables for PIm-Bidir,or do you feel that writing our own > templates would be easier???? No need to rewrite, just add your modifications incrementally to what is already there. > 4.)Could you also elucidate the implementation of the Packet > headers.(i.eplz tell the files in which we should be looking for it). The handling of PIM Hello messages is done inside pim_proto_hello.cc The handling of PIM Join/Prune messages is done inside pim_proto_join_prune.cc and pim_proto_join_prune_message.cc Regards, Pavlin From shamita1010 at gmail.com Sun Feb 18 16:56:37 2007 From: shamita1010 at gmail.com (shamita pisal) Date: Sun, 18 Feb 2007 16:56:37 -0800 Subject: [Xorp-hackers] Error in main_rtrmgr(PIM_SM) Message-ID: We were able to successfully compile thw PIM-SM code for PIM-Bidir flag per node.But when the scripts were run there was an error in main_rtrmgr.cc,it is as follows: ...'shutting down due to init:due to dunplicate "path" subcommand.' We have made changes in .tp file, as enable_pim_bidir{.... ......}. thanking you in anticipation, shamita -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070218/ad186102/attachment.html From ashishkarpe at gmail.com Mon Feb 19 14:26:02 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Mon, 19 Feb 2007 14:26:02 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: <200702162342.l1GNgjQH080362@possum.icir.org> References: <200702162342.l1GNgjQH080362@possum.icir.org> Message-ID: On 2/16/07, Pavlin Radoslavov wrote: > > > Also, have in mind that the is_bidir flag might be changed on-the-fly > (via xorpsh), so your code needs to take this into account. > > Just same pimsm4.tp with enable-bidir flag in it. Changing this flag > (e.g., via xorpsh) will invoke the appropriate XRL that will change > the "is_bidir" flag inside PimNode. We changed pim.cmds so now we can see pimbidir commands (eg. show pimbidir) but no actions is performed as appropriate XRL is to be associated with it !! So is there any document which will help us in achieving this (via xorpsh) !! or please let us know which which files to be modified ?? ps : is website www.xorp.org down ?? atleast we are facing problem opening it !! Regards, > Pavlin > > > Thank you, > > Ashish > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070219/ba71fd35/attachment.html From oho at acm.org Mon Feb 19 20:17:49 2007 From: oho at acm.org (Orion Hodson) Date: Mon, 19 Feb 2007 20:17:49 -0800 Subject: [Xorp-hackers] Hello!, Help needed on RIP module in XORP In-Reply-To: <22e357c80702181320w3920dbd4q7355ae26c1572095@mail.gmail.com> References: <22e357c80702181320w3920dbd4q7355ae26c1572095@mail.gmail.com> Message-ID: <85B3C7CA-497B-407D-A933-0EDE7DFD1223@acm.org> RIP notifies the RIB of the routes as it updates their state. The RIB arbitrates which of the routes it learns from routing protocols make it into the routing table. The RIB can also redistribute routes, for instance static routes, through RIP. RIP's routing decision code is in rip/route_db.cc. The packet formats are in rip/packets.hh and the packetization is rip/ packet_assembly.hh. The RIB notification code is rip/xrl_rib_notifier.{hh,cc}. The redistributed route information is managed by the *redist* files. For the most part the string "cost" identifies the routing metric at any point in RIP, with a few exceptional places that use "metric". Replacing the type of cost in the RouteEntry (route_entry.hh) with my_metric_t would probably give you the transitive closure of all the places in RIP that would need changing to support a more sophisticated metric (and a tonne of code that doesn't compile for a while :-). Happy Hacking - Orion On Feb 18, 2007, at 1:20 PM, Pallavi Gupta wrote: > Hello, > > I am a 4th year undergraduate student at a university in Canada. I am > doing a research project based on RIP and I am using XORP for > implementation of the changes that I intend to make in the protocol. I > am trying to understand the XORP code and I was wondering if someone > could point me out in the right direction. At the moment, I am trying > to figure out how XORP processes the routing metrics during path > selection, specifically for RIP. > I intend to change the metric for RIP into a compound of Hop count and > delay, if possible. > Thanks soo much, in advance, for your time and help. > > Sincerely, > Pallavi Gupta, > > -- > "Little things make big differences in life" > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Tue Feb 20 08:12:09 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 20 Feb 2007 08:12:09 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "Ashish Karpe" of "Mon, 19 Feb 2007 14:26:02 PST." Message-ID: <200702201612.l1KGC9d5010374@possum.icir.org> > > Also, have in mind that the is_bidir flag might be changed on-the-fly > > (via xorpsh), so your code needs to take this into account. > > > > Just same pimsm4.tp with enable-bidir flag in it. Changing this flag > > (e.g., via xorpsh) will invoke the appropriate XRL that will change > > the "is_bidir" flag inside PimNode. > > > We changed pim.cmds so now we can see pimbidir commands (eg. show > pimbidir) but no actions is performed as appropriate XRL is to be associated > with it !! So is there any document which will help us in achieving > this (via xorpsh) !! or please let us know which which files to be > modified ?? For information about xorpsh see the rtrmgr/xorpsh document that Mark pointed to you. The actions associated with the *.cmds xorpsh templates are executing external commands, not XRLs. Those commands then might invoke various XRLs. > ps : is website www.xorp.org down ?? atleast we are facing problem opening > it !! It seems to work for me right now. Regards, Pavlin From rcascheri at raytheon.com Tue Feb 20 08:21:58 2007 From: rcascheri at raytheon.com (Richard C Ascheri) Date: Tue, 20 Feb 2007 08:21:58 -0800 Subject: [Xorp-hackers] Cross Compiling XORP for MontaVista 4.0.1 ARM Target Message-ID: Hey Guys, Has anyone done any Cross Compiles for MontaVista 4.0.1 onto an ARM Processor? Any information would be greatfully appreciated. Thanks, Rick. Richard C. Ascheri Raytheon Company Principle Software Engineer FU / 675 / K124 Advanced Network Technologies 1801 Hughes Drive Tactical Communications Systems Fullerton, CA. 92834 rcascheri at raytheon.com WWW.RAYTHEON.COM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070220/7e4690f6/attachment.html From pavlin at icir.org Tue Feb 20 09:22:12 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 20 Feb 2007 09:22:12 -0800 Subject: [Xorp-hackers] Error in main_rtrmgr(PIM_SM) In-Reply-To: Message from "shamita pisal" of "Sun, 18 Feb 2007 16:56:37 PST." Message-ID: <200702201722.l1KHMCA1011322@possum.icir.org> shamita pisal wrote: > We were able to successfully compile thw PIM-SM code for PIM-Bidir flag per > node.But when the scripts were run there was an error in main_rtrmgr.cc,it > is as follows: > > ...'shutting down due to init:due to dunplicate "path" subcommand.' > > We have made changes in .tp file, as > enable_pim_bidir{.... > ......}. Did you check your template file(s) for duplicate "modinfo: path" commands (for same module). Regards, Pavlin From pavlin at icir.org Tue Feb 20 09:30:18 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 20 Feb 2007 09:30:18 -0800 Subject: [Xorp-hackers] Cross Compiling XORP for MontaVista 4.0.1 ARM Target In-Reply-To: Message from Richard C Ascheri of "Tue, 20 Feb 2007 08:21:58 PST." Message-ID: <200702201730.l1KHUIpS011486@possum.icir.org> > Has anyone done any Cross Compiles for MontaVista 4.0.1 onto an ARM > Processor? > > Any information would be greatfully appreciated. First you need to get the latest code from XORP CVS, because it contains fixes for various architectures (including ARM). I.e., release 1.3 won't work. Then please check section 3.8 "Cross-compilation" inside file BUILD_NOTES (in the top-level directory). The information there is mostly based on the crosstool toochain http://kegel.com/crosstool/, but the last two bullets (h) and (i) contain information about setting the XORP cross-compilation environment. You should set those variables as appropriate for MontaVista. Please let us know how it goes. Regards, Pavlin From kristian at spritelink.se Thu Feb 22 01:45:53 2007 From: kristian at spritelink.se (Kristian Larsson) Date: Thu, 22 Feb 2007 10:45:53 +0100 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: <200702220936.l1M9ajUd001984@xorpc.icir.org> References: <200702220936.l1M9ajUd001984@xorpc.icir.org> Message-ID: <20070222094553.GK29257@spritelink.se> On Thu, Feb 22, 2007 at 09:36:45AM +0000, Atanu Ghosh wrote: > CVSROOT: /usr/local/www/data/cvs > Module name: xorp > Changes by: atanu at xorpc.icir.org 2007-02-22 09:36:45 UTC > > XORP CVS repository > > > Modified files: > ospf ospf.cc ospf.hh peer_manager.cc peer_manager.hh > vlink.cc vlink.hh > > Log message: > In OSPFv3 hello packets and Router-LSAs carry an interface ID, for > virtual links a unique ID is required that doesn't clash with with > routers real interface IDs. Allocate pseudo interface IDs starting at > 1000 for virtual links. Is this going to be a problem on windows? What is the range of interface IDs? 65k? 4m? Isn't it better to start at the top and descend when allocating IDs for these pseudo interfaces? We have routers with more than 1000 interfaces... Kristian. -- Kristian Larsson KLL-RIPE Network Engineer SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From atanu at ICSI.Berkeley.EDU Thu Feb 22 02:12:42 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 22 Feb 2007 02:12:42 -0800 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: Message from Kristian Larsson of "Thu, 22 Feb 2007 10:45:53 +0100." <20070222094553.GK29257@spritelink.se> Message-ID: <54448.1172139162@tigger.icir.org> >>>>> "Kristian" == Kristian Larsson writes: Kristian> On Thu, Feb 22, 2007 at 09:36:45AM +0000, Atanu Ghosh Kristian> wrote: >> CVSROOT: /usr/local/www/data/cvs Module name: xorp Changes by: >> atanu at xorpc.icir.org 2007-02-22 09:36:45 UTC >> >> XORP CVS repository >> >> >> Modified files: ospf ospf.cc ospf.hh peer_manager.cc >> peer_manager.hh vlink.cc vlink.hh >> >> Log message: In OSPFv3 hello packets and Router-LSAs carry an >> interface ID, for virtual links a unique ID is required that >> doesn't clash with with routers real interface IDs. Allocate >> pseudo interface IDs starting at 1000 for virtual links. Is this >> going to be a problem on windows? Kristian> What is the range of interface IDs? 65k? 4m? Isn't it Kristian> better to start at the top and descend when allocating IDs Kristian> for these pseudo interfaces? We have routers with more Kristian> than 1000 interfaces... Okay - good idea the allocation starts from 0xffffffff and is decremented. Atanu. From hasso at linux.ee Thu Feb 22 02:26:18 2007 From: hasso at linux.ee (Hasso Tepper) Date: Thu, 22 Feb 2007 12:26:18 +0200 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: <20070222094553.GK29257@spritelink.se> References: <200702220936.l1M9ajUd001984@xorpc.icir.org> <20070222094553.GK29257@spritelink.se> Message-ID: <200702221226.18387.hasso@linux.ee> Kristian Larsson wrote: > What is the range of interface IDs? > 65k? 4m? > Isn't it better to start at the top and descend > when allocating IDs for these pseudo interfaces? > We have routers with more than 1000 interfaces... Me too. Btw, is "interface ID" something XORP assigns/maintains or is it ifinde, or ... ? regards, -- Hasso Tepper From atanu at ICSI.Berkeley.EDU Thu Feb 22 02:32:45 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 22 Feb 2007 02:32:45 -0800 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: Message from Hasso Tepper of "Thu, 22 Feb 2007 12:26:18 +0200." <200702221226.18387.hasso@linux.ee> Message-ID: <58463.1172140365@tigger.icir.org> >>>>> "Hasso" == Hasso Tepper writes: Hasso> Kristian Larsson wrote: >> What is the range of interface IDs? 65k? 4m? Isn't it better to >> start at the top and descend when allocating IDs for these pseudo >> interfaces? We have routers with more than 1000 interfaces... Hasso> Me too. Btw, is "interface ID" something XORP Hasso> assigns/maintains or is it ifinde, or ... ? The real interface index comes from the kernel, we are discussing a pseudo index that is generated for virtual links (that shouldn't clash with a real interface index). Atanu. From hasso at linux.ee Thu Feb 22 02:52:05 2007 From: hasso at linux.ee (Hasso Tepper) Date: Thu, 22 Feb 2007 12:52:05 +0200 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: <58463.1172140365@tigger.icir.org> References: <58463.1172140365@tigger.icir.org> Message-ID: <200702221252.05798.hasso@linux.ee> Atanu Ghosh wrote: > >>>>> "Hasso" == Hasso Tepper writes: > > Hasso> Kristian Larsson wrote: > >> What is the range of interface IDs? 65k? 4m? Isn't it better to > >> start at the top and descend when allocating IDs for these pseudo > >> interfaces? We have routers with more than 1000 interfaces... > > Hasso> Me too. Btw, is "interface ID" something XORP > Hasso> assigns/maintains or is it ifinde, or ... ? > > The real interface index comes from the kernel, we are discussing a > pseudo index that is generated for virtual links (that shouldn't clash > with a real interface index). So, interface ID used in OSPFv3 packets is equal to ifindex for real interfaces? In this case I don't think you can avoid potential race with such simple algorithms ;). At least Linux doesn't reuse ifindexes until wrapped. Create vlan (or any dynamic interface) => it has ifindex x; delete it and create again => it has ifindex [x+1]. So, for bulletproof implementation you have to do two things: 1) While assigning pseudo index, check whether it's not use already. 2) Handle the situation when real interface appears with ifindex equal to pseudo index in use. regards, -- Hasso Tepper From atanu at ICSI.Berkeley.EDU Thu Feb 22 16:08:04 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 22 Feb 2007 16:08:04 -0800 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/ospf In-Reply-To: Message from Hasso Tepper of "Thu, 22 Feb 2007 12:52:05 +0200." <200702221252.05798.hasso@linux.ee> Message-ID: <60987.1172189284@tigger.icir.org> >>>>> "Hasso" == Hasso Tepper writes: Hasso> Atanu Ghosh wrote: >> >>>>> "Hasso" == Hasso Tepper writes: >> Hasso> Kristian Larsson wrote: >> >> What is the range of interface IDs? 65k? 4m? Isn't it better >> to >> start at the top and descend when allocating IDs for these >> pseudo >> interfaces? We have routers with more than 1000 >> interfaces... >> Hasso> Me too. Btw, is "interface ID" something XORP Hasso> assigns/maintains or is it ifinde, or ... ? >> The real interface index comes from the kernel, we are >> discussing a pseudo index that is generated for virtual links >> (that shouldn't clash with a real interface index). Hasso> So, interface ID used in OSPFv3 packets is equal to ifindex Hasso> for real interfaces? In this case I don't think you can avoid Hasso> potential race with such simple algorithms ;). Hasso> At least Linux doesn't reuse ifindexes until wrapped. Create Hasso> vlan (or any dynamic interface) => it has ifindex x; delete Hasso> it and create again => it has ifindex [x+1]. So, for Hasso> bulletproof implementation you have to do two things: Hasso> 1) While assigning pseudo index, check whether it's not use Hasso> already. 2) Handle the situation when real interface appears Hasso> with ifindex equal to pseudo index in use. Done. Atanu. From guptalavi at gmail.com Mon Feb 26 01:10:25 2007 From: guptalavi at gmail.com (Pallavi Gupta) Date: Mon, 26 Feb 2007 01:10:25 -0800 Subject: [Xorp-hackers] Quick Question on RIP implementation in XORP Message-ID: <22e357c80702260110h562c0060l9eddd4348d1e558@mail.gmail.com> Hello Just a quick question, RIP was originally designed to send routing updates in a time driven fashion, by default, every 30 secs. In Cisco's implementation, RIP also uses triggerred updates in addition to the timed updates. I was just wondering if RIP implementation in XORP uses just the time driven updates or triggered updates as well. I am curious because if XORP doesnt , then I would like to implement the triggered updates in RIP in XORP as part of my project. Thanks a million. Regards, Pallavi Gupta, University College of the Fraser Valley. www.ucfv.ca On 2/19/07, Orion Hodson wrote: > RIP notifies the RIB of the routes as it updates their state. The > RIB arbitrates which of the routes it learns from routing protocols > make it into the routing table. The RIB can also redistribute > routes, for instance static routes, through RIP. > > RIP's routing decision code is in rip/route_db.cc. The packet > formats are in rip/packets.hh and the packetization is rip/ > packet_assembly.hh. > > The RIB notification code is rip/xrl_rib_notifier.{hh,cc}. The > redistributed route information is managed by the *redist* files. > > For the most part the string "cost" identifies the routing metric at > any point in RIP, with a few exceptional places that use "metric". > Replacing the type of cost in the RouteEntry (route_entry.hh) with > my_metric_t would probably give you the transitive closure of all the > places in RIP that would need changing to support a more > sophisticated metric (and a tonne of code that doesn't compile for a > while :-). > > Happy Hacking > - Orion > > > > > On Feb 18, 2007, at 1:20 PM, Pallavi Gupta wrote: > > > Hello, > > > > I am a 4th year undergraduate student at a university in Canada. I am > > doing a research project based on RIP and I am using XORP for > > implementation of the changes that I intend to make in the protocol. I > > am trying to understand the XORP code and I was wondering if someone > > could point me out in the right direction. At the moment, I am trying > > to figure out how XORP processes the routing metrics during path > > selection, specifically for RIP. > > I intend to change the metric for RIP into a compound of Hop count and > > delay, if possible. > > Thanks soo much, in advance, for your time and help. > > > > Sincerely, > > Pallavi Gupta, > > > > -- > > "Little things make big differences in life" > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > -- "Little things make big differences in life" From kristian at spritelink.se Mon Feb 26 02:55:53 2007 From: kristian at spritelink.se (Kristian Larsson) Date: Mon, 26 Feb 2007 11:55:53 +0100 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/etc/templates In-Reply-To: <200702261031.l1QAVD6S066457@xorpc.icir.org> References: <200702261031.l1QAVD6S066457@xorpc.icir.org> Message-ID: <20070226105553.GH8135@spritelink.se> On Mon, Feb 26, 2007 at 10:31:13AM +0000, Atanu Ghosh wrote: > CVSROOT: /usr/local/www/data/cvs > Module name: xorp > Changes by: atanu at xorpc.icir.org 2007-02-26 10:31:13 UTC > > XORP CVS repository > > > Modified files: > etc/templates rib.cmds > > Log message: > Add OSPFv3 route commands; copy OSPFv2 text and substitute OSPFv2 -> > OSPFv3, ipv4 -> ipv6. I know this has more to it than just this CVS commit, but it triggered a few thoughts. Is it really wise to differentiate OSPFv2 and OSPFv3 with the ospf[46] keywords? >From what I've heard there has been talk about supporting several simultaneous address families within OSPFv3 just as with IS-IS. Now how would you configure that if it's called ospf4 and ospf6 ? With ospf[46] it feels like we're abstracting something that shouldn't have an abstraction layer over it in the first place. ospf[23] or just ospf and ospf3 as juniper calls it is fine imho. Regards, Kristian, -- Kristian Larsson KLL-RIPE Network Engineer SpriteLink [AS39525] +46 704 910401 kristian at spritelink.se From atanu at ICSI.Berkeley.EDU Mon Feb 26 03:17:51 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 26 Feb 2007 03:17:51 -0800 Subject: [Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/etc/templates In-Reply-To: Message from Kristian Larsson of "Mon, 26 Feb 2007 11:55:53 +0100." <20070226105553.GH8135@spritelink.se> Message-ID: <19490.1172488671@tigger.icir.org> >>>>> "Kristian" == Kristian Larsson writes: Kristian> On Mon, Feb 26, 2007 at 10:31:13AM +0000, Atanu Ghosh Kristian> wrote: >> CVSROOT: /usr/local/www/data/cvs Module name: xorp Changes by: >> atanu at xorpc.icir.org 2007-02-26 10:31:13 UTC >> >> XORP CVS repository >> >> >> Modified files: etc/templates rib.cmds >> >> Log message: Add OSPFv3 route commands; copy OSPFv2 text and >> substitute OSPFv2 -> OSPFv3, ipv4 -> ipv6. Kristian> I know this has more to it than just this CVS commit, but Kristian> it triggered a few thoughts. Kristian> Is it really wise to differentiate OSPFv2 and OSPFv3 with Kristian> the ospf[46] keywords? From what I've heard there has Kristian> been talk about supporting several simultaneous address Kristian> families within OSPFv3 just as with IS-IS. Now how would Kristian> you configure that if it's called ospf4 and ospf6 ? Kristian> With ospf[46] it feels like we're abstracting something Kristian> that shouldn't have an abstraction layer over it in the Kristian> first place. ospf[23] or just ospf and ospf3 as juniper Kristian> calls it is fine imho. Kristian> Regards, Kristian, Hi, My preference would have been to do as you suggested, but it was felt that for consistency we should use the address family as the suffix. As you point out if carrying IPv4 addresses in OSPFv3 is ever standardised the naming should get interesting:-). Atanu. From oho at acm.org Mon Feb 26 06:58:56 2007 From: oho at acm.org (Orion Hodson) Date: Mon, 26 Feb 2007 06:58:56 -0800 Subject: [Xorp-hackers] Quick Question on RIP implementation in XORP In-Reply-To: <22e357c80702260110h562c0060l9eddd4348d1e558@mail.gmail.com> References: <22e357c80702260110h562c0060l9eddd4348d1e558@mail.gmail.com> Message-ID: <1FDE9FB0-1CB9-42CA-AEF4-EDDCAAF952C1@acm.org> Triggered updates are part of the RIP rfc. Xorp implements them. cd xorp/rip && grep -i triggered - Orion On Feb 26, 2007, at 1:10 AM, Pallavi Gupta wrote: > Hello > > Just a quick question, RIP was originally designed to send routing > updates in a time driven fashion, by default, every 30 secs. In > Cisco's implementation, RIP also uses triggerred updates in addition > to the timed updates. I was just wondering if RIP implementation in > XORP uses just the time driven updates or triggered updates as well. I > am curious because if XORP doesnt , then I would like to implement the > triggered updates in RIP in XORP as part of my project. Thanks a > million. > > Regards, > Pallavi Gupta, > University College of the Fraser Valley. > www.ucfv.ca > > On 2/19/07, Orion Hodson wrote: >> RIP notifies the RIB of the routes as it updates their state. The >> RIB arbitrates which of the routes it learns from routing protocols >> make it into the routing table. The RIB can also redistribute >> routes, for instance static routes, through RIP. >> >> RIP's routing decision code is in rip/route_db.cc. The packet >> formats are in rip/packets.hh and the packetization is rip/ >> packet_assembly.hh. >> >> The RIB notification code is rip/xrl_rib_notifier.{hh,cc}. The >> redistributed route information is managed by the *redist* files. >> >> For the most part the string "cost" identifies the routing metric at >> any point in RIP, with a few exceptional places that use "metric". >> Replacing the type of cost in the RouteEntry (route_entry.hh) with >> my_metric_t would probably give you the transitive closure of all the >> places in RIP that would need changing to support a more >> sophisticated metric (and a tonne of code that doesn't compile for a >> while :-). >> >> Happy Hacking >> - Orion >> >> >> >> >> On Feb 18, 2007, at 1:20 PM, Pallavi Gupta wrote: >> >>> Hello, >>> >>> I am a 4th year undergraduate student at a university in Canada. >>> I am >>> doing a research project based on RIP and I am using XORP for >>> implementation of the changes that I intend to make in the >>> protocol. I >>> am trying to understand the XORP code and I was wondering if someone >>> could point me out in the right direction. At the moment, I am >>> trying >>> to figure out how XORP processes the routing metrics during path >>> selection, specifically for RIP. >>> I intend to change the metric for RIP into a compound of Hop >>> count and >>> delay, if possible. >>> Thanks soo much, in advance, for your time and help. >>> >>> Sincerely, >>> Pallavi Gupta, >>> >>> -- >>> "Little things make big differences in life" >>> >>> _______________________________________________ >>> Xorp-hackers mailing list >>> Xorp-hackers at icir.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> >> > > > -- > "Little things make big differences in life" > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From ashishkarpe at gmail.com Mon Feb 26 13:21:08 2007 From: ashishkarpe at gmail.com (Ashish Karpe) Date: Tue, 27 Feb 2007 02:51:08 +0530 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: <200702201612.l1KGC9d5010374@possum.icir.org> References: <200702201612.l1KGC9d5010374@possum.icir.org> Message-ID: On 2/20/07, Pavlin Radoslavov wrote: > > > > We changed pim.cmds so now we can see pimbidir commands (eg. show > > pimbidir) but no actions is performed as appropriate XRL is to be > associated > > with it !! So is there any document which will help us in achieving > > this (via xorpsh) !! or please let us know which which files to be > > modified ?? > > The actions associated with the *.cmds xorpsh templates are > executing external commands, not XRLs. Those commands then might > invoke various XRLs. There is some problem in invoking various XRLs through commands !! ************************************************************************************************************** We modified pim.cmds as follows : /* $XORP: xorp/etc/templates/pim.cmds,v 1.4 2004/06/02 02:38:41 pavlin Exp $ */ show pim { %command: "" %help: HELP; %module: pimsm4; %tag: HELP "Display information about IPv4 PIM"; } show pim bootstrap { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 bootstrap routers"; } show pim bootstrap rps { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 bootstrap RPs"; } show pim interface { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 interfaces"; } show pim interface address { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about addresses of PIM IPv4 interfaces"; } show pim join { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 groups"; } show pim join all { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about all PIM IPv4 groups"; } show pim mfc { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM Multicast Forwarding Cache"; } show pim mrib { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display MRIB IPv4 information inside PIM"; } show pim neighbors { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 neighbors"; } show pim rps { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 RPs"; } show pim scope { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM IPv4 scope zones"; } show pimbidir { %command: "" %help: HELP; %module: pimsm4; %tag: HELP "Display information about IPv4 PIM-BIDIR"; } show pimbidir bootstrap { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap routers"; } show pimbidir bootstrap rpas { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap RPAs"; } show pimbidir interface { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 interfaces"; } show pimbidir interface address { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about addresses of PIM-BIDIR IPv4 interfaces"; } show pimbidir join { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 groups"; } show pimbidir join all { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about all PIM-BIDIR IPv4 groups"; } show pimbidir mfc { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR Multicast Forwarding Cache"; } show pimbidir mrib { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display MRIB IPv4 information inside PIM-BIDIR"; } show pimbidir neighbors { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 neighbors"; } show pimbidir rpas { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 RPAs"; } show pimbidir scope { %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; %module: pimsm4; %tag: HELP "Display information about PIM-BIDIR IPv4 scope zones"; } ************************************************************************************************************ Output of XORPSH : root at chintamani> show `show' is ambiguous. Possible completions: host Display information about the host igmp Display information about IGMP interfaces Show network interface information mfea Display information about IPv4 MFEA pim Display information about IPv4 PIM pimbidir Display information about IPv4 PIM-BIDIR route Show routes root at chintamani> show pimbidir interface address <[Enter]> Execute this command | Pipe through a command root at chintamani> show pimbidir interface address root at chintamani> ************************************************************************************************************* Now it should be showing interfaces but there is no action at all !!!! what is going wrong here ?? Thank you, Ashish Regards, > Pavlin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070227/a53a4f0e/attachment.html From pavlin at icir.org Mon Feb 26 17:03:15 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 26 Feb 2007 17:03:15 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "Ashish Karpe" of "Tue, 27 Feb 2007 02:51:08 +0530." Message-ID: <200702270103.l1R13FWr082516@possum.icir.org> Ashish Karpe wrote: > On 2/20/07, Pavlin Radoslavov wrote: > > > > > > > We changed pim.cmds so now we can see pimbidir commands (eg. show > > > pimbidir) but no actions is performed as appropriate XRL is to be > > associated > > > with it !! So is there any document which will help us in achieving > > > this (via xorpsh) !! or please let us know which which files to be > > > modified ?? > > > > The actions associated with the *.cmds xorpsh templates are > > executing external commands, not XRLs. Those commands then might > > invoke various XRLs. > > > There is some problem in invoking various XRLs through commands !! Did you add/implement the new commands to pim/pim_node_cli.cc? E.g., see method PimNodeCli::add_all_cli_commands() in that file. Regards, Pavlin > > ************************************************************************************************************** > We modified pim.cmds as follows : > > > /* $XORP: xorp/etc/templates/pim.cmds,v 1.4 2004/06/02 02:38:41 pavlin Exp $ > */ > > show pim { > %command: "" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about IPv4 PIM"; > } > > show pim bootstrap { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 bootstrap routers"; > } > > show pim bootstrap rps { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 bootstrap RPs"; > } > > show pim interface { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 interfaces"; > } > > show pim interface address { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about addresses of PIM IPv4 interfaces"; > } > > show pim join { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 groups"; > } > > show pim join all { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about all PIM IPv4 groups"; > } > > show pim mfc { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM Multicast Forwarding Cache"; > } > > show pim mrib { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display MRIB IPv4 information inside PIM"; > } > > show pim neighbors { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 neighbors"; > } > > show pim rps { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 RPs"; > } > > show pim scope { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM IPv4 scope zones"; > } > > show pimbidir { > %command: "" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about IPv4 PIM-BIDIR"; > } > > show pimbidir bootstrap { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap routers"; > } > > show pimbidir bootstrap rpas { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap RPAs"; > } > > show pimbidir interface { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 interfaces"; > } > > show pimbidir interface address { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about addresses of PIM-BIDIR IPv4 > interfaces"; > } > > show pimbidir join { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 groups"; > } > > show pimbidir join all { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about all PIM-BIDIR IPv4 groups"; > } > > show pimbidir mfc { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR Multicast Forwarding Cache"; > } > > show pimbidir mrib { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display MRIB IPv4 information inside PIM-BIDIR"; > } > > show pimbidir neighbors { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 neighbors"; > } > > show pimbidir rpas { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 RPAs"; > } > > show pimbidir scope { > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: HELP; > %module: pimsm4; > %tag: HELP "Display information about PIM-BIDIR IPv4 scope zones"; > } > > > ************************************************************************************************************ > Output of XORPSH : > > > root at chintamani> show > `show' is ambiguous. > Possible completions: > host Display information about the host > igmp Display information about IGMP > interfaces Show network interface information > mfea Display information about IPv4 MFEA > pim Display information about IPv4 PIM > pimbidir Display information about IPv4 PIM-BIDIR > route Show routes > root at chintamani> show pimbidir interface address > <[Enter]> Execute this command > | Pipe through a command > root at chintamani> show pimbidir interface address > root at chintamani> > > > ************************************************************************************************************* > Now it should be showing interfaces but there is no action at all !!!! what > is going wrong here ?? > > Thank you, > Ashish > > > > > Regards, > > Pavlin > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From chintamanisw at gmail.com Mon Feb 26 21:41:00 2007 From: chintamanisw at gmail.com (chintamani wandhre) Date: Tue, 27 Feb 2007 11:11:00 +0530 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: <200702270103.l1R13FWr082516@possum.icir.org> References: <200702270103.l1R13FWr082516@possum.icir.org> Message-ID: <8385815b0702262141l415280b5t38351fd16b4e663f@mail.gmail.com> On 2/27/07, Pavlin Radoslavov wrote: > > Ashish Karpe wrote: > > > On 2/20/07, Pavlin Radoslavov wrote: > > > > > > > > > > We changed pim.cmds so now we can see pimbidir commands (eg. show > > > > pimbidir) but no actions is performed as appropriate XRL is to be > > > associated > > > > with it !! So is there any document which will help us in > achieving > > > > this (via xorpsh) !! or please let us know which which files to be > > > > modified ?? > > > > > > The actions associated with the *.cmds xorpsh templates are > > > executing external commands, not XRLs. Those commands then might > > > invoke various XRLs. > > > > > > There is some problem in invoking various XRLs through commands !! > > Did you add/implement the new commands to pim/pim_node_cli.cc? > E.g., see method PimNodeCli::add_all_cli_commands() in that file. But we haven't added any new command !! Initially we just want to execute same commands those of PIM-SM for Bidir (eg. show pim interface address & show pimbidir interface address should execute same command !! ). Regards, > Pavlin > > > > > > ************************************************************************************************************** > > We modified pim.cmds as follows : > > > > > > /* $XORP: xorp/etc/templates/pim.cmds,v 1.4 2004/06/02 02:38:41 pavlin > Exp $ > > */ > > > > show pim { > > %command: "" %help: HELP; > > %module: pimsm4; > > %tag: HELP "Display information about IPv4 PIM"; > > } > > > > show pim bootstrap { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 bootstrap routers"; > > } > > > > show pim bootstrap rps { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 bootstrap RPs"; > > } > > > > show pim interface { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 interfaces"; > > } > > > > show pim interface address { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about addresses of PIM IPv4 > interfaces"; > > } > > > > show pim join { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 groups"; > > } > > > > show pim join all { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about all PIM IPv4 groups"; > > } > > > > show pim mfc { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM Multicast Forwarding > Cache"; > > } > > > > show pim mrib { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display MRIB IPv4 information inside PIM"; > > } > > > > show pim neighbors { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 neighbors"; > > } > > > > show pim rps { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 RPs"; > > } > > > > show pim scope { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM IPv4 scope zones"; > > } > > > > show pimbidir { > > %command: "" %help: HELP; > > %module: pimsm4; > > %tag: HELP "Display information about IPv4 PIM-BIDIR"; > > } > > > > show pimbidir bootstrap { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap > routers"; > > } > > > > show pimbidir bootstrap rpas { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap > RPAs"; > > } > > > > show pimbidir interface { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 interfaces"; > > } > > > > show pimbidir interface address { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about addresses of PIM-BIDIR IPv4 > > interfaces"; > > } > > > > show pimbidir join { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 groups"; > > } > > > > show pimbidir join all { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about all PIM-BIDIR IPv4 groups"; > > } > > > > show pimbidir mfc { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR Multicast Forwarding > Cache"; > > } > > > > show pimbidir mrib { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display MRIB IPv4 information inside PIM-BIDIR"; > > } > > > > show pimbidir neighbors { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 neighbors"; > > } > > > > show pimbidir rpas { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 RPAs"; > > } > > > > show pimbidir scope { > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > HELP; > > %module: pimsm4; > > %tag: HELP "Display information about PIM-BIDIR IPv4 scope zones"; > > } > > > > > > > ************************************************************************************************************ > > Output of XORPSH : > > > > > > root at chintamani> show > > `show' is ambiguous. > > Possible completions: > > host Display information about the host > > igmp Display information about IGMP > > interfaces Show network interface information > > mfea Display information about IPv4 MFEA > > pim Display information about IPv4 PIM > > pimbidir Display information about IPv4 PIM-BIDIR > > route Show routes > > root at chintamani> show pimbidir interface address > > <[Enter]> Execute this command > > | Pipe through a command > > root at chintamani> show pimbidir interface address > > root at chintamani> > > > > > > > ************************************************************************************************************* > > Now it should be showing interfaces but there is no action at all !!!! > what > > is going wrong here ?? > > > > Thank you, > > Ashish > > > > > > > > > > Regards, > > > Pavlin > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070227/ecb70820/attachment-0001.html From pavlin at icir.org Tue Feb 27 09:48:59 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 27 Feb 2007 09:48:59 -0800 Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries. In-Reply-To: Message from "chintamani wandhre" of "Tue, 27 Feb 2007 11:11:00 +0530." <8385815b0702262141l415280b5t38351fd16b4e663f@mail.gmail.com> Message-ID: <200702271748.l1RHmxcS090040@possum.icir.org> > > > There is some problem in invoking various XRLs through commands !! > > > > Did you add/implement the new commands to pim/pim_node_cli.cc? > > E.g., see method PimNodeCli::add_all_cli_commands() in that file. > > > But we haven't added any new command !! Initially we just want to > execute same commands those of PIM-SM for Bidir (eg. show pim interface > address & show pimbidir interface address should execute same command !! ). > > > show pimbidir bootstrap { > > > %command: "cli/tools/send_cli_processor_xrl -t PIMSM_4 $0" %help: > > HELP; > > > %module: pimsm4; > > > %tag: HELP "Display information about PIM-BIDIR IPv4 bootstrap > > routers"; > > > } If you use the $0 argument, then you are passing the original command as typed (i.e., "show pimbidir bootstrap" in the above example) for interpretation and processing. Hence you must have have it implemented if you want the above entry to work. However, if you replace "$0" with "show pim bootstrap" then you will invoke the processing mechanism for that command. Regards, Pavlin From atanu at ICSI.Berkeley.EDU Wed Feb 28 13:54:31 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 28 Feb 2007 13:54:31 -0800 Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.4 Message-ID: <89366.1172699671@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.4 Release Candidate, which is now available from . The major feature of this release is the addition of OSPFv3 (OSPF for IPv6). Once the release candidate has proven to be stable, the actual 1.4 release will be prepared. This is planned to occur in the next two weeks. In the intervening period we will be fixing minor problems and updating the documentation. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users at xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback at xorp.org. - The XORP Team P.S. Release notes included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.4-RC (2006/02/28) ========================= ALL: - XORP now builds on DragonFlyBSD-1.8, FreeBSD-6.2, Linux Fedora Core6, Linux Debian-3.1 (sarge), NetBSD-3.1 and OpenBSD-4.0. - XORP now can be compiled with the Intel C/C++ compiler 9.* on Linux. - XORP now can be cross-compiled for IA-64, MIPS (Broadcom for Linksys WRT54G), PowerPC-603, Sparc64, and XScale processors. - Implementation of OSPFv3 (draft-ietf-ospf-ospfv3-update-14.txt). - Implementation of floating static routes (i.e., static routes for the same prefix with different next hop and metrics). CONFIGURATION: - Allow static routes to have "nexthop4" and "nexthop6" policy matching conditions in the "from" block. - Addition of new FEA configuration statements to retain XORP unicast forwarding entries on startup or shutdown: fea { unicast-forwarding4 { forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } unicast-forwarding6 { forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } The default value for each statement is false. Note that those statements prevent the FEA itself from deleting the forwarding entries and does not prevent the RIB or any of the unicast routing protocols from deleting the entries on shutdown. - The "elements" policy statements for configuring sets of network routes have been deprecated: policy { network4-list foo { elements: "1.2.0.0/16,3.4.0.0/16" } network6-list bar { elements: "2222::/64,3333::/64" } } The new replacement statement is "network" and can be used to specify one element per line: policy { network4-list foo { network 1.2.0.0/16 network 3.4.0.0/16 } network6-list bar { network 2222::/64 network 3333::/64 } } - The following keywords are supported inside the policy configuration when comparing IPv4 or IPv6 network prefixes: exact, longer, orlonger, shorter, orshorter, not. For example: "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8" "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8" "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8" "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8" "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8" "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8" The original operators are supported as well. - A floating static route (also called "qualified" by some router vendors) can be added with a configuration like: protocols { static { route 10.10.0.0/16 { next-hop: 172.16.0.1 metric: 1 qualified-next-hop 172.17.0.2 { metric: 10 } } interface-route 10.30.30.0/24 { next-hop-interface: "rl0" next-hop-vif: "rl0" next-hop-router: 172.16.0.1 metric: 1 qualified-next-hop-interface rl1 { qualified-next-hop-vif rl1 { next-hop-router: 172.17.0.2 metric: 10 } } } } } LIBXORP: - The XORP scheduler now has support for priority-based tasks. LIBXIPC: - No significant changes. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Bug fix in the semantics of the rtrmgr template %activate keyword. XORPSH: - No significant changes. POLICY: - Bug fix related to creating export policies that match protocol's its own routes (e.g., a policy that modifies the BGP routes exported to its peers). - Various other bug fixes. FEA/MFEA: - Fix the routing socket based mechanism (used by BSD-derived systems) for obtaining the interface name (toward the destination) for a routing entry. - Apply a performance improvement when configuring a large number of interfaces/VIFs, each of them with the "default-system-config" configuration statement. - Bug fix related to atomically modifying the IP address of an interface. RIB: - Bug fix related to (not) installing redundant host-specific entries for the other side of a point-to-point interface if the netmask for the interface covers the host-specific entry. RIP: - No significant changes. OSPF: - OSPFv3 is now available. - The OSPFv3 protocol requires that link-local addresses are used, therefore it is necessary to configure a link-local address for each interface, this restriction will be removed in the future. - The OSPFv3 configuration allows multiple instances to be configured however only one instance will be created. - For OSPFv3 only one global address can be set on an interface, multiple addresses will be allowed in the final release. Please note that the configuration will change when multiple addresses are supported. - The OSPFv3 specification requires that unknown LSAs should be processed, currently unknown LSAs are incorrectly considered an error. Unknown LSAs will be handled in the final release. - OSPFv3 has support for virtual links but adjacencies are not always correctly formed. - Bug fix related to the processing of previously generated LSAs on startup has been fixed. Restarting a router that was the designated router could exhibit this problem. - Bug fix on a broadcast interface if the router was not the designated router then the nexthop was incorrectly unconditionally set to the designated router; introducing an unnecessary extra hop. BGP: - BGP has taken advantage of the priority-based tasks in the XORP scheduler and background tasks are run at a low priority; leading to improved performance. STATIC_ROUTES: - Bug fix related to declaring some of the policy matching conditions in the "from" block. MLD/IGMP: - Bug fix related to atomically modifying the IP address of an interface. - Bug fix related to ignoring protocol messages that are not recognized by the configured protocol version on an interface. - Ignore control messages if the source address is not directly connected. - Don't send the periodic Group-Specific or Group-and-Source-Specific Queries for entries that are in IGMPv1 mode. PIM-SM: - Bug fix related to atomically modifying the IP address of an interface. - The PIM-SM control messages do not include the IP Router Alert option anymore, because it has been included from the newer revisions of the PIM-SM protocol specification (RFC 4601 and draft-ietf-pim-sm-bsr-09.txt,.ps). - Don't send PIM Hello message with DR Priority of 0 when shutting down an interface, because this is not part of the protocol specification. FIB2MRIB: - Bug fix related to updating the interface and vif name of a forwarding entry received from the FEA. CLI: - Performance improvement if the CLI is processing a large amount of data. E.g., if xorpsh is used in a pipe like: cat commands.txt | xorpsh SNMP: - Bug fix with the snmpd arguments when sampling whether snmpd can start and its version is >= 5.2. ------------------------------------------------------------------