From michael.fox at vyatta.com Wed May 2 11:10:08 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Wed, 2 May 2007 11:10:08 -0700 (PDT) Subject: [Xorp-users] ospf4 rfc1583-compatibility option Message-ID: <01ce01c78ce5$1df392d0$9300000a@FoxDellLatD620> Can someone explain the specific function/behavior of the rfc1583-compatibility option in ospf4? I don't see it mentioned in the XORP User Manual version 1.4 dated March 20, 2007. My understand is that this option has to do with how external routes are handled. But reading when I read RFC 2178 and 2328 which superseded 1583, both RFCs indicate that their respective changes are backward compatible and interoperable with prior versions. So I'm left wondering what exactly this option does. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070502/c2d30f0a/attachment.html From michael.fox at vyatta.com Wed May 2 12:07:19 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Wed, 2 May 2007 12:07:19 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option Message-ID: <01fc01c78ced$1b9c3bb0$9300000a@FoxDellLatD620> Can someone explain the specific function/behavior of the "ip-router-alert option" in ospf4? The XORP v1.4 User Manual mentions that setting this to TRUE will put the IP router alert option in all transmitted packets. (Since this is an OSPF configuration parameter, I presume that the documentation really means to say ".in all transmitted OSPF packets"). RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of the option with RSVP and IGMP. I can find no mention elsewhere of the use of the IP router alert option with OSPF and OSPF doesn't seem to need this option. So, the question is: what specifically does this option do and under what circumstances does this option need to be enabled in the OSPF4 configuration? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070502/1de0f7cf/attachment.html From vkaul at research.telcordia.com Thu May 3 08:56:26 2007 From: vkaul at research.telcordia.com (Vikram Kaul) Date: Thu, 03 May 2007 11:56:26 -0400 Subject: [Xorp-users] GRE for multicast (but no PIM-SM on the tunnel) Message-ID: <463A062A.8070104@research.telcordia.com> Folks A few question about the details of GRE tunnels between two disjoint multicast enabled (using PIM-SM) domains in XORP. Firstly, I understand that GRE tunnels can be created between two gateway routers (each one taking care of its own "domain"). I refer to http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-February/001660.html which dealt with a xorp router interacting with a cisco box with PIM-SM enabled on the tunnel on both ends so that the end-points see each other as PIM neighbors. Given that, the need for static rp-address configuration (same at both ends) pointing to the same RP and default mroute (on cisco) and mrib-route (on xorp) My situation is different. Those differences lie in: - I need to have individual separate RPs for each domain for the same group. The gateway routers could be the RPs. I am ok with static configurations on all routers on each "domain" pointing to the respective gateway router as the RP. - The above creates the need for disabling PIM-SM on the tunnels. I want them to be pure tunnels for multicast traffic alone. No PIM hellos or Join/Prunes are exchanged between these RP/gateway routers - I am ok with disabling RPT-to-SPT switchover so that the RP is always the root of the tree in each domain. I merely want to "tunnel" the data from this RP/gateway to the other side and be disseminated \ / \ / \ / \ / \ / \ / / / / / / GRE Tunnel / RP/GW----------------------------------------RP/GW \ \ \ \ \ \ ------ First, I want to implement this purely for two gateway XORP routers. Essentially, the questions are : 1. Can I have a multicast tunnel in XORP without enabling PIM on it ? 2. How do I configure the an mrib-route like / mrib-route 224.0.0.0/4 { // next-hop: 200.x.x.153 /* tunnel */ } / which acts in addition to the multicast forwarding caches that might have been established in the RP. 3. For PIM Register packets that arrive at the RP, I want them to be forwarded on the tunnel after they have been decapsulated. Does XORP configuration allow for forwarding on an interface which is not "PIM capable" ? Will "mrib-route" do the trick if the next hop is on an interface which is not PIM capable ? Any pointers on feasibility/alternatives/gaping holes in approach are welcome. Any ideas on if this were possible in XORP, how well could it fit into interoperability with a cisco box ? regards.. Vikram From pavlin at icir.org Thu May 3 11:00:12 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 03 May 2007 11:00:12 -0700 Subject: [Xorp-users] GRE for multicast (but no PIM-SM on the tunnel) In-Reply-To: Message from Vikram Kaul of "Thu, 03 May 2007 11:56:26 EDT." <463A062A.8070104@research.telcordia.com> Message-ID: <200705031800.l43I0COC066089@possum.icir.org> Vikram Kaul wrote: > Folks > > A few question about the details of GRE tunnels between two disjoint > multicast enabled (using PIM-SM) domains in XORP. > > Firstly, I understand that GRE tunnels can be created between two > gateway routers (each one taking care of its own "domain"). I refer to > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-February/001660.html > > which dealt with a xorp router interacting with a cisco box with PIM-SM > enabled on the tunnel on both ends so that the end-points see each other > as PIM neighbors. > Given that, the need for static rp-address configuration (same at both > ends) pointing to the same RP and default mroute (on cisco) and > mrib-route (on xorp) > > My situation is different. Those differences lie in: > > - I need to have individual separate RPs for each domain for the same > group. The gateway routers could be the RPs. > I am ok with static configurations on all routers on each "domain" > pointing to the respective gateway router as the RP. In general, if you want have separate RPs for the same multicast group, then you need to use something between them like MSDP (RFC 3618) or Anycast-RP (RFC 4610). Currently XORP doesn't implement either one, and for several reasons we do not plan to implement MSDP. We do plan to implement Anycast-RP, but unfortunately currently it is very low priority on our TODO list. > - The above creates the need for disabling PIM-SM on the tunnels. > I want them to be pure tunnels for multicast traffic alone. No PIM > hellos or Join/Prunes are exchanged between these > RP/gateway routers > - I am ok with disabling RPT-to-SPT switchover so that the RP is always > the root of the tree in each domain. > I merely want to "tunnel" the data from this RP/gateway to the other > side and be disseminated Do you always want to tunnel the data or only when there is a receiver on the other side? Obviously, the solution (if exists given the limitations) eventually will be simpler if you always tunnel the data, but then you will be wasting bandwidth if there are no receivers on the other side. > > \ / > \ / > \ / > \ / > \ / > \ / > / > / > / > / > / GRE Tunnel / > RP/GW----------------------------------------RP/GW > \ > \ > \ > \ > \ > \ > ------ > > First, I want to implement this purely for two gateway XORP routers. > Essentially, the questions are : > > 1. Can I have a multicast tunnel in XORP without enabling PIM on it ? In XORP there is no explicit support for multicast tunnels. In fact, the GRE tunnels for example look like any other interface to XORP (from MFEA, IGMP, PIM-SM, etc. point of view), except that you need to configure them in advance before starting XORP. > 2. How do I configure the an mrib-route like > > / mrib-route 224.0.0.0/4 { > // next-hop: 200.x.x.153 /* tunnel */ > } > / > > which acts in addition to the multicast forwarding caches that might > have been established in the RP. You can't. The purpose of the mrib-route statements is to add static RPF entries to the MRIB: those entries are used by PIM-SM to check the RPF information. In other words, those entries cannot manipulate the multicast forwarding caches. In general you cannot (and shouldn't) manipulate the multicast forwarding using static configuration, because if you ever create a multicast loop this will be a disaster. > 3. For PIM Register packets that arrive at the RP, I want them to be > forwarded on the tunnel after they have been decapsulated. Does XORP > configuration allow for forwarding on an interface which is not "PIM > capable" ? Will "mrib-route" do the trick if the next hop is on an > interface which is not PIM capable ? No (see above). > Any pointers on feasibility/alternatives/gaping holes in approach are > welcome. > Any ideas on if this were possible in XORP, how well could it fit into > interoperability with a cisco box ? The cleaner solution would be to use Anycast-RP for example which is relatively simple, but it has its gotchas (see the RFC for details). However, there is one ugly hack that just came to mind. It assumes that all the routers on the path between the two RPs have implemented the (*,*,RP) PIM-SM mechanism as specified in the PIM-SM spec: this is true for XORP, but I don't know whether Cisco actually implemented that part of the spec. My guess is they didn't so if this is the case then you would have to replace your Cisco with XORP :) [To be fair, the alternative is to replace XORP with Cisco that implements MSDP or Anycast-RP :)] Anyway, here is the basic idea of this ugly hack just to give you some feeling what you could do without Anycast-RP. The purpose of the (*,*,RP) PIM-SM Join messages is to "pull" all multicast traffic that is rooted in a particular RP. FYI, the (*,*,RP) mechanism was originally added to PIM-SM for interoperability purpose: e.g., to facilitate connecting PIM-SM domains with other domains that might even run different multicast routing protocols. Hence, if forwarding all multicast traffic from one RP to the other is not an issue (even if there are no receivers in the other domain), then you could have each RP to send (*,*,RP) PIM-SM Join toward the other RP. Eventually, this will pull-down the traffic from one RP toward the other using existing PIM-SM mechanisms. The uglier part of the hack is how to tell the RP to originate those (*,*,RP) Joins, because the PIM-SM spec describes how to handle the Joins, but doesn't describe when they are originated (simply because the "originator" is some other mechanism that uses PIM-SM). In XORP you can actually do it by sending special XRLs to the PIM-SM module to tell PIM-SM to originate various PIM-SM control messages (including (*,*,RP) Join/Prune messages). Those XRLs were originally added for testing purpose, but in your case you can have an external program (e.g., a shell script) that periodically sends them to the XORP router. However, it is important to note that those XRLs will trigger the Join messages, but will NOT create the necessary (*,*,RP) forwarding entry in the XORP router that originates them. To get around this problem you could simply have a PIM-SM XORP router N that is a neighbor of RP1 sends them to RP1 with content (*,*,RP2) Join: thus RP1 will have internal (*,*,RP2) routing entry and will forward the (*,*,RP2) Join toward the other RP (RP2). The downside is that all multicast traffic from RP2 will reach not only RP1, but N as well. If this extra hop overhead is an issue then we can think about an alternative. Such alternative is to use the "alternative-subnet" configuration statement on the RP1 PIM-SM interface toward RP2. FYI, there are variations of this scheme such like generating (*,G) Joins instead, but then you need extra monitoring of the (*,G) routing state inside each RP to know when to generate those messages. Please let me know if you want to give a try of the above hack (or some of its variations), and I can provide you the details how to use those special XRLs to tell XORP to originate the (*,*,RP) or (*,G) Joins. Regards, Pavlin > regards.. > Vikram > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ms_arvindkumar at yahoo.co.in Mon May 7 05:07:45 2007 From: ms_arvindkumar at yahoo.co.in (arvind kumar) Date: Mon, 7 May 2007 13:07:45 +0100 (BST) Subject: [Xorp-users] can you help me Message-ID: <884968.58670.qm@web8609.mail.in.yahoo.com> Hi I am Arvind, I have started to work on XORP project but I am not able to get how its working. I searched document for Xrl in xorp.org but it was not there If any one have document for Xrl please mail me(ms_arvindkumar at yahoo.co.in). If you didnt have document then try to mail me what you understand about "Xrl". In xorp, I run the xorp_rtrmgr and xorp_rib. After that i add a route from ./add_route from rib directory.It was working but if I tried to delete that route it was not possible.Also i cant able get the routes what I have added. If you know about how to delete and get the routes which was added then mail me Regards Arvindkumar.S Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php From a.greenhalgh at cs.ucl.ac.uk Mon May 7 06:06:11 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Mon, 7 May 2007 14:06:11 +0100 Subject: [Xorp-users] can you help me In-Reply-To: <884968.58670.qm@web8609.mail.in.yahoo.com> References: <884968.58670.qm@web8609.mail.in.yahoo.com> Message-ID: <4769af410705070606w163a6d9by7a9b341dd7ccf5bc@mail.gmail.com> Arvind, You probably need to read this document http://www.xorp.org/getting_started.html#running and if you are wanting to work with the xrl rpc mechanism then this document will help http://www.xorp.org/releases/1.4/docs/libxipc/libxipc_overview.pdf (linked from http://www.xorp.org/design_docs.html ) these documents might also be of use to you http://www.xorp.org/releases/1.4/docs/user_manual/user_manual.pdf http://www.xorp.org/releases/1.4/docs/xorpdev_101/xorpdev_101.pdf Adam On 5/7/07, arvind kumar wrote: > Hi > I am Arvind, I have started to work on XORP project > but I am not able to get how its working. > > I searched document for Xrl in xorp.org but it was > not there If any one have document for Xrl please mail > me(ms_arvindkumar at yahoo.co.in). > If you didnt have document then try to mail me what > you understand about "Xrl". > > In xorp, I run the xorp_rtrmgr and xorp_rib. After > that i add a route from ./add_route from rib > directory.It was working but if I tried to delete that > route it was not possible.Also i cant able get the > routes what I have added. > > If you know about how to delete and get the routes > which was added then mail me > > Regards > Arvindkumar.S > > > Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From ms_arvindkumar at yahoo.co.in Mon May 7 21:51:42 2007 From: ms_arvindkumar at yahoo.co.in (arvind kumar) Date: Tue, 8 May 2007 05:51:42 +0100 (BST) Subject: [Xorp-users] help me Message-ID: <183718.62952.qm@web8614.mail.in.yahoo.com> how to monitor the status of internal tables in RIB Regards Arvindkumar.S Office firewalls, cyber cafes, college labs, don't allow you to download CHAT? Click here: http://in.messenger.yahoo.com/webmessengerpromo.php From pavlin at icir.org Mon May 7 23:40:38 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 07 May 2007 23:40:38 -0700 Subject: [Xorp-users] help me In-Reply-To: Message from arvind kumar of "Tue, 08 May 2007 05:51:42 BST." <183718.62952.qm@web8614.mail.in.yahoo.com> Message-ID: <200705080640.l486ecON030082@possum.icir.org> arvind kumar wrote: > how to monitor the status of internal tables in RIB You could use the xorpsh "show route table ..." and "show route admin ..." commands to show the routes and admin distances inside the RIB. If you want to continuously receive the routes modifications from the RIB, then you can write a program that uses the redist_enable4 and redist_enable6 XRLs for example to register interest with the RIB. That program needs to implement the redist4.xif and redist6.xif XRL target interface to receive the route modifications. This is actually the mechanism used by the rib/tools/show_routes.cc program, so you can use it as a starting point. Hope that helps, Pavlin > Regards > Arvindkumar.S From hasso at estpak.ee Tue May 8 05:43:48 2007 From: hasso at estpak.ee (Hasso Tepper) Date: Tue, 8 May 2007 15:43:48 +0300 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <01fc01c78ced$1b9c3bb0$9300000a@FoxDellLatD620> References: <01fc01c78ced$1b9c3bb0$9300000a@FoxDellLatD620> Message-ID: <200705081543.48722.hasso@estpak.ee> Michael Fox wrote: > Can someone explain the specific function/behavior of the "ip-router-alert > option" in ospf4? > > The XORP v1.4 User Manual mentions that setting this to TRUE will put the > IP router alert option in all transmitted packets. (Since this is an OSPF > configuration parameter, I presume that the documentation really means to > say ".in all transmitted OSPF packets"). > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of the > option with RSVP and IGMP. > > I can find no mention elsewhere of the use of the IP router alert option > with OSPF and OSPF doesn't seem to need this option. Me neither and I don't need any need as well. IP router alert is for cases where routers need to inspect packets not addressed for them directly. I don't see any need for that in OSPF. > So, the question is: what specifically does this option do and under what > circumstances does this option need to be enabled in the OSPF4 > configuration? Note that there is one point to enable it with current code though - if router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set (see RawSocket::proto_socket_write()). But I fail to see logic in this as well - IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols regardless of any settings. I don't see any reason not to do that. And if you don't, it makes your network very likely vulnerable to dos attacks. regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] IP & Data Networking Expert From pavlin at icir.org Tue May 8 12:39:50 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 08 May 2007 12:39:50 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from Hasso Tepper of "Tue, 08 May 2007 15:43:48 +0300." <200705081543.48722.hasso@estpak.ee> Message-ID: <200705081939.l48JdoYG036359@possum.icir.org> Hasso Tepper wrote: > Michael Fox wrote: > > Can someone explain the specific function/behavior of the "ip-router-alert > > option" in ospf4? > > > > The XORP v1.4 User Manual mentions that setting this to TRUE will put the > > IP router alert option in all transmitted packets. (Since this is an OSPF > > configuration parameter, I presume that the documentation really means to > > say ".in all transmitted OSPF packets"). > > > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of the > > option with RSVP and IGMP. > > > > I can find no mention elsewhere of the use of the IP router alert option > > with OSPF and OSPF doesn't seem to need this option. > > Me neither and I don't need any need as well. IP router alert is for cases > where routers need to inspect packets not addressed for them directly. I > don't see any need for that in OSPF. > > > So, the question is: what specifically does this option do and under what > > circumstances does this option need to be enabled in the OSPF4 > > configuration? > > Note that there is one point to enable it with current code though - if > router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set (see > RawSocket::proto_socket_write()). But I fail to see logic in this as well - > IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols regardless > of any settings. I don't see any reason not to do that. And if you don't, > it makes your network very likely vulnerable to dos attacks. I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. I just committed a fix to CVS so now there is a separate flag that is used as appropriate to set ip_tos in the IPv4 header to IPTOS_PREC_INTERNETCONTROL. About the usage of Router Alert in OSPF (which BTW is disabled by default), my guess is that it is leftover from earlier versions of the transmission code. I will leave it to Atanu to confirm that we really don't need it and should be removed. Thanks, Pavlin > > regards, > > -- > Hasso Tepper > Elion Enterprises Ltd. [AS3249] > IP & Data Networking Expert > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From michael.fox at vyatta.com Tue May 8 19:27:12 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Tue, 8 May 2007 19:27:12 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705081939.l48JdoYG036359@possum.icir.org> References: Message from Hasso Tepper of "Tue, 08 May 2007 15:43:48 +0300." <200705081543.48722.hasso@estpak.ee> <200705081939.l48JdoYG036359@possum.icir.org> Message-ID: <041001c791e1$8d294630$9300000a@FoxDellLatD620> Thanks. So, to make sure I understand the situation properly, it sounds like: 1) OSPF was NOT setting IPTOS_PREC_INTERNETCONTROL unless the ip-router-alert option in the OSPF configuration was set. This was NOT correct behavior and Pavlin has committed a fix to correct this situation. 2) If that is true, then, in the interim, users SHOULD ENABLE the ip-router-alert option for OSPF (default is disabled). Please correct if I got it wrong. Thanks, Michael -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: Tuesday, May 08, 2007 12:40 PM To: Hasso Tepper Cc: xorp-users at xorp.org; Michael Fox Subject: Re: [Xorp-users] ospf4 ip-router-alert option Hasso Tepper wrote: > Michael Fox wrote: > > Can someone explain the specific function/behavior of the > > "ip-router-alert > > option" in ospf4? > > > > The XORP v1.4 User Manual mentions that setting this to TRUE will put > > the > > IP router alert option in all transmitted packets. (Since this is an > > OSPF > > configuration parameter, I presume that the documentation really means > > to > > say ".in all transmitted OSPF packets"). > > > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of the > > option with RSVP and IGMP. > > > > I can find no mention elsewhere of the use of the IP router alert option > > with OSPF and OSPF doesn't seem to need this option. > > Me neither and I don't need any need as well. IP router alert is for cases > where routers need to inspect packets not addressed for them directly. I > don't see any need for that in OSPF. > > > So, the question is: what specifically does this option do and under > > what > > circumstances does this option need to be enabled in the OSPF4 > > configuration? > > Note that there is one point to enable it with current code though - if > router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set > (see > RawSocket::proto_socket_write()). But I fail to see logic in this as > well - > IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols > regardless > of any settings. I don't see any reason not to do that. And if you don't, > it makes your network very likely vulnerable to dos attacks. I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. I just committed a fix to CVS so now there is a separate flag that is used as appropriate to set ip_tos in the IPv4 header to IPTOS_PREC_INTERNETCONTROL. About the usage of Router Alert in OSPF (which BTW is disabled by default), my guess is that it is leftover from earlier versions of the transmission code. I will leave it to Atanu to confirm that we really don't need it and should be removed. Thanks, Pavlin > > regards, > > -- > Hasso Tepper > Elion Enterprises Ltd. [AS3249] > IP & Data Networking Expert > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hasso at linux.ee Tue May 8 23:03:37 2007 From: hasso at linux.ee (Hasso Tepper) Date: Wed, 9 May 2007 09:03:37 +0300 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705081939.l48JdoYG036359@possum.icir.org> References: <200705081939.l48JdoYG036359@possum.icir.org> Message-ID: <200705090903.37292.hasso@linux.ee> Pavlin Radoslavov wrote: > I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. > I just committed a fix to CVS so now there is a separate flag that > is used as appropriate to set ip_tos in the IPv4 header to > IPTOS_PREC_INTERNETCONTROL. Btw, AFAICS it only affects protocols using raw socket abstraction in FEA. What about protocols like RIP and BGP? regards, -- Hasso Tepper From pavlin at icir.org Wed May 9 15:30:43 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 May 2007 15:30:43 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from "Michael Fox" of "Tue, 08 May 2007 19:27:12 PDT." <041001c791e1$8d294630$9300000a@FoxDellLatD620> Message-ID: <200705092230.l49MUhAP047108@possum.icir.org> Michael Fox wrote: > Thanks. > > So, to make sure I understand the situation properly, it sounds like: > > 1) OSPF was NOT setting IPTOS_PREC_INTERNETCONTROL unless the > ip-router-alert option in the OSPF configuration was set. This was NOT > correct behavior and Pavlin has committed a fix to correct this situation. > > 2) If that is true, then, in the interim, users SHOULD ENABLE the > ip-router-alert option for OSPF (default is disabled). > > Please correct if I got it wrong. Yes, OSPF was not setting IPTOS_PREC_INTERNETCONTROL unless the ip-router-alert option was set. However, for most practical purpose there is no need to enable the ip-router-alert option just to get the IP TOS bits set. The TOS bits would matter only if you have diffserv or something like that and even then you would need them only in certain circumstances. Regards, Pavlin > > Thanks, > Michael > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > Sent: Tuesday, May 08, 2007 12:40 PM > To: Hasso Tepper > Cc: xorp-users at xorp.org; Michael Fox > Subject: Re: [Xorp-users] ospf4 ip-router-alert option > > Hasso Tepper wrote: > > > Michael Fox wrote: > > > Can someone explain the specific function/behavior of the > > > "ip-router-alert > > > option" in ospf4? > > > > > > The XORP v1.4 User Manual mentions that setting this to TRUE will put > > > the > > > IP router alert option in all transmitted packets. (Since this is an > > > OSPF > > > configuration parameter, I presume that the documentation really means > > > to > > > say ".in all transmitted OSPF packets"). > > > > > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of the > > > option with RSVP and IGMP. > > > > > > I can find no mention elsewhere of the use of the IP router alert option > > > with OSPF and OSPF doesn't seem to need this option. > > > > Me neither and I don't need any need as well. IP router alert is for cases > > where routers need to inspect packets not addressed for them directly. I > > don't see any need for that in OSPF. > > > > > So, the question is: what specifically does this option do and under > > > what > > > circumstances does this option need to be enabled in the OSPF4 > > > configuration? > > > > Note that there is one point to enable it with current code though - if > > router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set > > (see > > RawSocket::proto_socket_write()). But I fail to see logic in this as > > well - > > IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols > > regardless > > of any settings. I don't see any reason not to do that. And if you don't, > > it makes your network very likely vulnerable to dos attacks. > > I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. > I just committed a fix to CVS so now there is a separate flag that > is used as appropriate to set ip_tos in the IPv4 header to > IPTOS_PREC_INTERNETCONTROL. > > About the usage of Router Alert in OSPF (which BTW is disabled by > default), my guess is that it is leftover from earlier versions of > the transmission code. > I will leave it to Atanu to confirm that we really don't need it and > should be removed. > > Thanks, > Pavlin > > > > > regards, > > > > -- > > Hasso Tepper > > Elion Enterprises Ltd. [AS3249] > > IP & Data Networking Expert > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Wed May 9 15:43:50 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 May 2007 15:43:50 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from Hasso Tepper of "Wed, 09 May 2007 09:03:37 +0300." <200705090903.37292.hasso@linux.ee> Message-ID: <200705092243.l49MhoVe047229@possum.icir.org> Hasso Tepper wrote: > Pavlin Radoslavov wrote: > > I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. > > I just committed a fix to CVS so now there is a separate flag that > > is used as appropriate to set ip_tos in the IPv4 header to > > IPTOS_PREC_INTERNETCONTROL. > > Btw, AFAICS it only affects protocols using raw socket abstraction in > FEA. What about protocols like RIP and BGP? Yes, the above change only affects protocols that use the raw sockets. The XRL API used to send TCP/UDP via the FEA doesn't have the support for setting the TOS bits. I just added a Bugzilla entry for that so it is not forgotten: http://www.xorp.org/bugzilla/show_bug.cgi?id=716 Thanks, Pavlin > > regards, > > -- > Hasso Tepper > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From michael.fox at vyatta.com Wed May 9 15:45:58 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Wed, 9 May 2007 15:45:58 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705092230.l49MUhAP047108@possum.icir.org> References: Message from "Michael Fox" of "Tue, 08 May 2007 19:27:12 PDT." <041001c791e1$8d294630$9300000a@FoxDellLatD620> <200705092230.l49MUhAP047108@possum.icir.org> Message-ID: <023e01c7928b$d3daa6a0$9300000a@FoxDellLatD620> Pavlin, Thanks for the clarification. Follow-up question: Since, going forward, your fix will set the IP TOS bits correctly (IPTOS_PREC_INTERNETCONTROL ) for all OSPF packets, then is there a purpose for the ip-router-alert option in the OSPF configuration (ospf4 and ospf6)? If not, then will this option be deprecated in future versions? Michael -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: Wednesday, May 09, 2007 3:31 PM To: Michael Fox Cc: 'Pavlin Radoslavov'; 'Hasso Tepper'; xorp-users at xorp.org Subject: Re: [Xorp-users] ospf4 ip-router-alert option Michael Fox wrote: > Thanks. > > So, to make sure I understand the situation properly, it sounds like: > > 1) OSPF was NOT setting IPTOS_PREC_INTERNETCONTROL unless the > ip-router-alert option in the OSPF configuration was set. This was NOT > correct behavior and Pavlin has committed a fix to correct this situation. > > 2) If that is true, then, in the interim, users SHOULD ENABLE the > ip-router-alert option for OSPF (default is disabled). > > Please correct if I got it wrong. Yes, OSPF was not setting IPTOS_PREC_INTERNETCONTROL unless the ip-router-alert option was set. However, for most practical purpose there is no need to enable the ip-router-alert option just to get the IP TOS bits set. The TOS bits would matter only if you have diffserv or something like that and even then you would need them only in certain circumstances. Regards, Pavlin > > Thanks, > Michael > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > Sent: Tuesday, May 08, 2007 12:40 PM > To: Hasso Tepper > Cc: xorp-users at xorp.org; Michael Fox > Subject: Re: [Xorp-users] ospf4 ip-router-alert option > > Hasso Tepper wrote: > > > Michael Fox wrote: > > > Can someone explain the specific function/behavior of the > > > "ip-router-alert > > > option" in ospf4? > > > > > > The XORP v1.4 User Manual mentions that setting this to TRUE will put > > > the > > > IP router alert option in all transmitted packets. (Since this is an > > > OSPF > > > configuration parameter, I presume that the documentation really means > > > to > > > say ".in all transmitted OSPF packets"). > > > > > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of > > > the > > > option with RSVP and IGMP. > > > > > > I can find no mention elsewhere of the use of the IP router alert > > > option > > > with OSPF and OSPF doesn't seem to need this option. > > > > Me neither and I don't need any need as well. IP router alert is for > > cases > > where routers need to inspect packets not addressed for them directly. I > > don't see any need for that in OSPF. > > > > > So, the question is: what specifically does this option do and under > > > what > > > circumstances does this option need to be enabled in the OSPF4 > > > configuration? > > > > Note that there is one point to enable it with current code though - if > > router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set > > (see > > RawSocket::proto_socket_write()). But I fail to see logic in this as > > well - > > IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols > > regardless > > of any settings. I don't see any reason not to do that. And if you > > don't, > > it makes your network very likely vulnerable to dos attacks. > > I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. > I just committed a fix to CVS so now there is a separate flag that > is used as appropriate to set ip_tos in the IPv4 header to > IPTOS_PREC_INTERNETCONTROL. > > About the usage of Router Alert in OSPF (which BTW is disabled by > default), my guess is that it is leftover from earlier versions of > the transmission code. > I will leave it to Atanu to confirm that we really don't need it and > should be removed. > > Thanks, > Pavlin > > > > > regards, > > > > -- > > Hasso Tepper > > Elion Enterprises Ltd. [AS3249] > > IP & Data Networking Expert > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Wed May 9 16:03:58 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 May 2007 16:03:58 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from "Michael Fox" of "Wed, 09 May 2007 15:45:58 PDT." <023e01c7928b$d3daa6a0$9300000a@FoxDellLatD620> Message-ID: <200705092303.l49N3w2w047558@possum.icir.org> Michael Fox wrote: > Pavlin, > > Thanks for the clarification. > > Follow-up question: > > Since, going forward, your fix will set the IP TOS bits correctly > (IPTOS_PREC_INTERNETCONTROL ) for all OSPF packets, then is there a purpose > for the ip-router-alert option in the OSPF configuration (ospf4 and ospf6)? > If not, then will this option be deprecated in future versions? Accidentally, we just talked with Atanu about this and he is going to deprecate the ip-router-alert configuration option for OSPF. Pavlin > Michael > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > Sent: Wednesday, May 09, 2007 3:31 PM > To: Michael Fox > Cc: 'Pavlin Radoslavov'; 'Hasso Tepper'; xorp-users at xorp.org > Subject: Re: [Xorp-users] ospf4 ip-router-alert option > > Michael Fox wrote: > > > Thanks. > > > > So, to make sure I understand the situation properly, it sounds like: > > > > 1) OSPF was NOT setting IPTOS_PREC_INTERNETCONTROL unless the > > ip-router-alert option in the OSPF configuration was set. This was NOT > > correct behavior and Pavlin has committed a fix to correct this situation. > > > > 2) If that is true, then, in the interim, users SHOULD ENABLE the > > ip-router-alert option for OSPF (default is disabled). > > > > Please correct if I got it wrong. > > Yes, OSPF was not setting IPTOS_PREC_INTERNETCONTROL unless the > ip-router-alert option was set. > > However, for most practical purpose there is no need to enable > the ip-router-alert option just to get the IP TOS bits set. > The TOS bits would matter only if you have diffserv or something > like that and even then you would need them only in certain > circumstances. > > Regards, > Pavlin > > > > > Thanks, > > Michael > > > > > > -----Original Message----- > > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > > Sent: Tuesday, May 08, 2007 12:40 PM > > To: Hasso Tepper > > Cc: xorp-users at xorp.org; Michael Fox > > Subject: Re: [Xorp-users] ospf4 ip-router-alert option > > > > Hasso Tepper wrote: > > > > > Michael Fox wrote: > > > > Can someone explain the specific function/behavior of the > > > > "ip-router-alert > > > > option" in ospf4? > > > > > > > > The XORP v1.4 User Manual mentions that setting this to TRUE will put > > > > the > > > > IP router alert option in all transmitted packets. (Since this is an > > > > OSPF > > > > configuration parameter, I presume that the documentation really means > > > > to > > > > say ".in all transmitted OSPF packets"). > > > > > > > > RFC 2113 (IP Router Alert Option RFC) mentions examples of usage of > > > > the > > > > option with RSVP and IGMP. > > > > > > > > I can find no mention elsewhere of the use of the IP router alert > > > > option > > > > with OSPF and OSPF doesn't seem to need this option. > > > > > > Me neither and I don't need any need as well. IP router alert is for > > > cases > > > where routers need to inspect packets not addressed for them directly. I > > > don't see any need for that in OSPF. > > > > > > > So, the question is: what specifically does this option do and under > > > > what > > > > circumstances does this option need to be enabled in the OSPF4 > > > > configuration? > > > > > > Note that there is one point to enable it with current code though - if > > > router alert option is enabled, IPTOS_PREC_INTERNETCONTROL is also set > > > (see > > > RawSocket::proto_socket_write()). But I fail to see logic in this as > > > well - > > > IPTOS_PREC_INTERNETCONTROL MUST be used for all routing protocols > > > regardless > > > of any settings. I don't see any reason not to do that. And if you > > > don't, > > > it makes your network very likely vulnerable to dos attacks. > > > > I think you are right about the usage of IPTOS_PREC_INTERNETCONTROL. > > I just committed a fix to CVS so now there is a separate flag that > > is used as appropriate to set ip_tos in the IPv4 header to > > IPTOS_PREC_INTERNETCONTROL. > > > > About the usage of Router Alert in OSPF (which BTW is disabled by > > default), my guess is that it is leftover from earlier versions of > > the transmission code. > > I will leave it to Atanu to confirm that we really don't need it and > > should be removed. > > > > Thanks, > > Pavlin > > > > > > > > regards, > > > > > > -- > > > Hasso Tepper > > > Elion Enterprises Ltd. [AS3249] > > > IP & Data Networking Expert > > > > > > _______________________________________________ > > > Xorp-users mailing list > > > Xorp-users at xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hasso at linux.ee Wed May 9 16:18:06 2007 From: hasso at linux.ee (Hasso Tepper) Date: Thu, 10 May 2007 02:18:06 +0300 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705092230.l49MUhAP047108@possum.icir.org> References: <200705092230.l49MUhAP047108@possum.icir.org> Message-ID: <200705100218.06462.hasso@linux.ee> Pavlin Radoslavov wrote: > The TOS bits would matter only if you have diffserv or something > like that and even then you would need them only in certain > circumstances. Nope. Most of nowadays routers use QoS by default anyway. They reserve some percentage from every link for network control and they have QoS between forwarding plane and control plane (often even not configurable). Don't set IPTOS_PREC_INTERNETCONTROL for routing protocols and you can be sure that your routing protocol sessions will be dropped even during very small attacks not having any operational impact to any other router or traffic in general. -- Hasso Tepper From michael.fox at vyatta.com Wed May 9 19:00:13 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Wed, 9 May 2007 19:00:13 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705100218.06462.hasso@linux.ee> References: <200705092230.l49MUhAP047108@possum.icir.org> <200705100218.06462.hasso@linux.ee> Message-ID: <029001c792a6$f6c68420$9300000a@FoxDellLatD620> Thank you both. Now, could you tackle my similar question regarding the ospf4 rfc1583-compatibility option? Thanks, Michael -----Original Message----- From: Hasso Tepper [mailto:hasso at linux.ee] Sent: Wednesday, May 09, 2007 4:18 PM To: xorp-users at xorp.org Cc: Pavlin Radoslavov; Michael Fox Subject: Re: [Xorp-users] ospf4 ip-router-alert option Pavlin Radoslavov wrote: > The TOS bits would matter only if you have diffserv or something > like that and even then you would need them only in certain > circumstances. Nope. Most of nowadays routers use QoS by default anyway. They reserve some percentage from every link for network control and they have QoS between forwarding plane and control plane (often even not configurable). Don't set IPTOS_PREC_INTERNETCONTROL for routing protocols and you can be sure that your routing protocol sessions will be dropped even during very small attacks not having any operational impact to any other router or traffic in general. -- Hasso Tepper From atanu at ICSI.Berkeley.EDU Wed May 9 19:10:00 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 09 May 2007 19:10:00 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from "Michael Fox" of "Wed, 09 May 2007 19:00:13 PDT." <029001c792a6$f6c68420$9300000a@FoxDellLatD620> Message-ID: <57729.1178763000@tigger.icir.org> Hi, Take a look at section 16.4 in RFC 2328. Atanu. >>>>> "Michael" == Michael Fox writes: Michael> Thank you both. Now, could you tackle my similar question Michael> regarding the ospf4 rfc1583-compatibility option? Michael> Thanks, Michael Michael> -----Original Message----- From: Hasso Tepper Michael> [mailto:hasso at linux.ee] Sent: Wednesday, May 09, 2007 4:18 Michael> PM To: xorp-users at xorp.org Cc: Pavlin Radoslavov; Michael Michael> Fox Subject: Re: [Xorp-users] ospf4 ip-router-alert option Michael> Pavlin Radoslavov wrote: >> The TOS bits would matter only if you have diffserv or something >> like that and even then you would need them only in certain >> circumstances. Michael> Nope. Most of nowadays routers use QoS by default Michael> anyway. They reserve some percentage from every link for Michael> network control and they have QoS between forwarding plane Michael> and control plane (often even not configurable). Don't set Michael> IPTOS_PREC_INTERNETCONTROL for routing protocols and you Michael> can be sure that your routing protocol sessions will be Michael> dropped even during very small attacks not having any Michael> operational impact to any other router or traffic in Michael> general. Michael> -- Hasso Tepper Michael> _______________________________________________ Xorp-users Michael> mailing list Xorp-users at xorp.org Michael> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From michael.fox at vyatta.com Wed May 9 19:15:45 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Wed, 9 May 2007 19:15:45 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <57729.1178763000@tigger.icir.org> References: Message from "Michael Fox" of "Wed, 09 May 2007 19:00:13 PDT." <029001c792a6$f6c68420$9300000a@FoxDellLatD620> <57729.1178763000@tigger.icir.org> Message-ID: <02a001c792a9$2264ace0$9300000a@FoxDellLatD620> Ahh. Thank you very much. I had looked and looked and couldn't find the reference. Michael -----Original Message----- From: atanu at icir.org [mailto:atanu at icir.org] On Behalf Of Atanu Ghosh Sent: Wednesday, May 09, 2007 7:10 PM To: Michael Fox Cc: 'Hasso Tepper'; xorp-users at xorp.org; 'Pavlin Radoslavov' Subject: Re: [Xorp-users] ospf4 ip-router-alert option Hi, Take a look at section 16.4 in RFC 2328. Atanu. >>>>> "Michael" == Michael Fox writes: Michael> Thank you both. Now, could you tackle my similar question Michael> regarding the ospf4 rfc1583-compatibility option? Michael> Thanks, Michael Michael> -----Original Message----- From: Hasso Tepper Michael> [mailto:hasso at linux.ee] Sent: Wednesday, May 09, 2007 4:18 Michael> PM To: xorp-users at xorp.org Cc: Pavlin Radoslavov; Michael Michael> Fox Subject: Re: [Xorp-users] ospf4 ip-router-alert option Michael> Pavlin Radoslavov wrote: >> The TOS bits would matter only if you have diffserv or something >> like that and even then you would need them only in certain >> circumstances. Michael> Nope. Most of nowadays routers use QoS by default Michael> anyway. They reserve some percentage from every link for Michael> network control and they have QoS between forwarding plane Michael> and control plane (often even not configurable). Don't set Michael> IPTOS_PREC_INTERNETCONTROL for routing protocols and you Michael> can be sure that your routing protocol sessions will be Michael> dropped even during very small attacks not having any Michael> operational impact to any other router or traffic in Michael> general. Michael> -- Hasso Tepper Michael> _______________________________________________ Xorp-users Michael> mailing list Xorp-users at xorp.org Michael> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From michael.fox at vyatta.com Thu May 10 06:50:39 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Thu, 10 May 2007 06:50:39 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option Message-ID: <001c01c7930a$314e7590$9300000a@FoxDellLatD620> One final question on the ip-router-alert option. What is the status of RIP and BGP? Do they need to be updated to properly set IPTOS_PREC_INTERNETCONTROL or are they already setting it? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070510/a8b51462/attachment.html From pavlin at icir.org Thu May 10 14:17:08 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 10 May 2007 14:17:08 -0700 Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: Message from "Michael Fox" of "Thu, 10 May 2007 06:50:39 PDT." <001c01c7930a$314e7590$9300000a@FoxDellLatD620> Message-ID: <200705102117.l4ALH8fj017697@possum.icir.org> Michael Fox wrote: > One final question on the ip-router-alert option. > > > > What is the status of RIP and BGP? Do they need to be updated to properly > set IPTOS_PREC_INTERNETCONTROL or are they already setting it? They need to be updated: http://www.xorp.org/bugzilla/show_bug.cgi?id=716 Pavlin > > > > Michael > > > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From michael.fox at vyatta.com Thu May 10 14:49:23 2007 From: michael.fox at vyatta.com (Michael Fox) Date: Thu, 10 May 2007 14:49:23 -0700 (PDT) Subject: [Xorp-users] ospf4 ip-router-alert option In-Reply-To: <200705102117.l4ALH8fj017697@possum.icir.org> References: Message from "Michael Fox" of "Thu, 10 May 2007 06:50:39 PDT." <001c01c7930a$314e7590$9300000a@FoxDellLatD620> <200705102117.l4ALH8fj017697@possum.icir.org> Message-ID: <01d201c7934d$14b6fd10$9300000a@FoxDellLatD620> Thanks much! -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: Thursday, May 10, 2007 2:17 PM To: Michael Fox Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] ospf4 ip-router-alert option Michael Fox wrote: > One final question on the ip-router-alert option. > > > > What is the status of RIP and BGP? Do they need to be updated to properly > set IPTOS_PREC_INTERNETCONTROL or are they already setting it? They need to be updated: http://www.xorp.org/bugzilla/show_bug.cgi?id=716 Pavlin > > > > Michael > > > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From czajnik at czajsoft.pl Mon May 21 17:03:23 2007 From: czajnik at czajsoft.pl (Przemyslaw Wegrzyn) Date: Tue, 22 May 2007 02:03:23 +0200 Subject: [Xorp-users] Problems with multicast routing on Linux Message-ID: <4652334B.1070604@czajsoft.pl> Hi! I need a very simple multicast routing setup. I'm totally new to all multicast and IGMP, and Xorp actually, so forgive me if I'm asking silly questions. I have one double-homed router, one local network (192.168.1.x) contains a multicast server, streaming to 3 multicast groups. Another local network (10.1.1.x), contains a stream receiver which selectively attaches to one of these 3 groups. I don't need any PIM functionality, just a basic IGMP. Router IPs: 192.168.1.254 on eth1, 10.1.1.254 on eth0 Streamer IP: 192.168.1.2 Receiver's IP: 10.1.1.2 There are 3 groups: 239.252.100.8, 239.252.200.10, and 239.252.200.11 At this point I can see IGMP dialogue that looks valid, yet there are no multicast routes being set up (e.g. join/leave for 239.252.200.10 below). [ 2007/05/21 18:36:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.2 to 239.252.200.10 on vif eth0 [ 2007/05/21 18:36:16 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0, 239.252.200.10) on vif eth0 [ 2007/05/21 18:36:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.1.254 to 224.0.0.2 on vif eth1 [ 2007/05/21 18:36:18 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.254 to 224.0.0.22 on vif eth0 [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.200.11 [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.200.10 [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.10.8 [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 10.1.1.2 to 224.0.0.2 on vif eth0 [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 on vif eth0 [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.2 to 239.252.10.8 on vif eth0 [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 on vif eth0 [ 2007/05/21 18:36:24 TRACE xorp_igmp MLD6IGMP ] Notify routing delete membership for (0.0.0.0, 239.252.200.10) on vif eth0 I'd expect that "Notify routing add membership for (0.0.0.0, 239.252.200.10) on vif eth0" is a log of creating a multicast route, however multicast route table (as shown by 'ip mroute') is empty all the time. Please note that if I run pimd on that host, it works! Kernel version is 2.6.16. Any help appreciated. Below is my config. interfaces { interface eth0 { description: "Client-side" default-system-config } interface eth1 { description: "Server-side" default-system-config } } fea { unicast-forwarding4 { forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false version: 2 } } interface eth1 { vif eth1 { disable: false version: 2 } } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } Best Regards, Przemyslaw From pavlin at icir.org Mon May 21 20:24:10 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 21 May 2007 20:24:10 -0700 Subject: [Xorp-users] Problems with multicast routing on Linux In-Reply-To: Message from Przemyslaw Wegrzyn of "Tue, 22 May 2007 02:03:23 +0200." <4652334B.1070604@czajsoft.pl> Message-ID: <200705220324.l4M3OAbW010808@possum.icir.org> Przemyslaw Wegrzyn wrote: > Hi! > > I need a very simple multicast routing setup. I'm totally new to all > multicast and IGMP, and Xorp actually, so forgive me if I'm asking silly > questions. > > I have one double-homed router, one local network (192.168.1.x) contains > a multicast server, streaming to 3 multicast groups. Another local > network (10.1.1.x), contains a stream receiver which selectively > attaches to one of these 3 groups. I don't need any PIM functionality, > just a basic IGMP. If you want multicast forwarding between two segments, you MUST use a multicast routing protocol like PIM-SM. The purpose of IGMP is to inform the multicast routing protocol about directly connected receivers. Then it is up to the multicast routing protocol to modify the multicast forwarding entries in the kernel. BTW, it is perfectly legal to run single PIM-SM instance on the host that is between the server and the receiver. Though, that host should be configured as Cand-RP so eventually it will become the RP. Regards, Pavlin > Router IPs: 192.168.1.254 on eth1, 10.1.1.254 on eth0 > Streamer IP: 192.168.1.2 > Receiver's IP: 10.1.1.2 > > There are 3 groups: 239.252.100.8, 239.252.200.10, and 239.252.200.11 > > At this point I can see IGMP dialogue that looks valid, yet there are no > multicast routes being set up (e.g. join/leave for 239.252.200.10 below). > > [ 2007/05/21 18:36:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.2 to 239.252.200.10 on vif eth0 > [ 2007/05/21 18:36:16 TRACE xorp_igmp MLD6IGMP ] Notify routing add > membership for (0.0.0.0, 239.252.200.10) on vif eth0 > [ 2007/05/21 18:36:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 192.168.1.254 to 224.0.0.2 on vif eth1 > [ 2007/05/21 18:36:18 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.254 to 224.0.0.22 on vif eth0 > [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: > message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.200.11 > [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: > message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.200.10 > [ 2007/05/21 18:36:20 TRACE xorp_fea MFEA ] RX kernel signal: > message_type = 1 vif_index = 1 src = 192.168.1.1 dst = 239.252.10.8 > [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP > from 10.1.1.2 to 224.0.0.2 on vif eth0 > [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] TX > IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 > [ 2007/05/21 18:36:22 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 on vif eth0 > [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 10.1.1.2 to 239.252.10.8 on vif eth0 > [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] TX > IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 > [ 2007/05/21 18:36:23 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_MEMBERSHIP_QUERY from 10.1.1.254 to 239.252.200.10 on vif eth0 > [ 2007/05/21 18:36:24 TRACE xorp_igmp MLD6IGMP ] Notify routing delete > membership for (0.0.0.0, 239.252.200.10) on vif eth0 > > I'd expect that "Notify routing add membership for (0.0.0.0, > 239.252.200.10) on vif eth0" is a log of creating a multicast route, > however multicast route table (as shown by 'ip mroute') is empty all the > time. > > Please note that if I run pimd on that host, it works! Kernel version is > 2.6.16. > > Any help appreciated. Below is my config. > > interfaces { > interface eth0 { > description: "Client-side" > default-system-config > } > > interface eth1 { > description: "Server-side" > default-system-config > } > } > > fea { > unicast-forwarding4 { > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 2 > } > } > interface eth1 { > vif eth1 { > disable: false > version: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > fib2mrib { > disable: false > } > } > > > Best Regards, > Przemyslaw > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jon-olov at ontimenet.com Thu May 24 00:30:15 2007 From: jon-olov at ontimenet.com (Jon-Olov Vatn) Date: Thu, 24 May 2007 09:30:15 +0200 Subject: [Xorp-users] Problems with multicast routing on Linux In-Reply-To: <200705220324.l4M3OAbW010808@possum.icir.org> References: <200705220324.l4M3OAbW010808@possum.icir.org> Message-ID: <46553F07.1010205@ontimenet.com> Pavlin Radoslavov skrev: > If you want multicast forwarding between two segments, you MUST use > a multicast routing protocol like PIM-SM. > The purpose of IGMP is to inform the multicast routing protocol > about directly connected receivers. Then it is up to the multicast > routing protocol to modify the multicast forwarding entries in the > kernel. > Is it really necessary to use a multicast routing protocol, or could the forwarding tables be configured statically, e.g., with "route add ..."? I understand that it useful to use a routing protocol, but for a small network with one or two routers it may be of interest to support multicast routing without deploying, e.g., PIM-SM or DVMRP. When googling I found smcroute (http://www.cschill.de/smcroute/) which seems adequate for such situations, but I have not tried it and since the last release is from 2002 I'm a bit suspicious ... Anyone out there with experience of smcroute or setting up static multicast forward entries in Linux in general? Mvh J-O From pavlin at icir.org Thu May 24 04:56:40 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 24 May 2007 04:56:40 -0700 Subject: [Xorp-users] Problems with multicast routing on Linux In-Reply-To: Message from Jon-Olov Vatn of "Thu, 24 May 2007 09:30:15 +0200." <46553F07.1010205@ontimenet.com> Message-ID: <200705241156.l4OBuerD039900@possum.icir.org> Jon-Olov Vatn wrote: > Pavlin Radoslavov skrev: > > If you want multicast forwarding between two segments, you MUST use > > a multicast routing protocol like PIM-SM. > > The purpose of IGMP is to inform the multicast routing protocol > > about directly connected receivers. Then it is up to the multicast > > routing protocol to modify the multicast forwarding entries in the > > kernel. > > > Is it really necessary to use a multicast routing protocol, or could the > forwarding tables be configured statically, e.g., with "route add ..."? In general you can't use commands like "route add" to install multicast forwarding entries in the kernel. Unlike unicast static routes, multicast static routes shouldn't be used primarily for the following two reasons: (a) multicast receiver membership is dynamic in nature and this can't be tracked by (multicast) static routes. (b) If you create a multicast routing loop (which can easily happen with static routes), then you can easily bring down your network due to the exponential amplification of the looping packets. I haven't used smcroute, but if you use it you need to understand the above two issues. Regards, Pavlin > I understand that it useful to use a routing protocol, but for a small > network with one or two routers it may be of interest to support > multicast routing without deploying, e.g., PIM-SM or DVMRP. When > googling I found smcroute (http://www.cschill.de/smcroute/) which seems > adequate for such situations, but I have not tried it and since the last > release is from 2002 I'm a bit suspicious ... Anyone out there with > experience of smcroute or setting up static multicast forward entries in > Linux in general? > > Mvh J-O > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jon-olov at ontimenet.com Thu May 24 06:56:35 2007 From: jon-olov at ontimenet.com (Jon-Olov Vatn) Date: Thu, 24 May 2007 15:56:35 +0200 Subject: [Xorp-users] Problems with multicast routing on Linux In-Reply-To: <200705241156.l4OBuerD039900@possum.icir.org> References: <200705241156.l4OBuerD039900@possum.icir.org> Message-ID: <46559993.80403@ontimenet.com> Hi Pavlin, Thanks for the quick response! I am aware about the issues you list, and I should have been clearer about the situations when static multicast routing could be of interest. As you point out static multicast routing won't handle situations where the multicast group address(es), senders and group membership are neither static nor known in advance. Regards, J-O Pavlin Radoslavov skrev: > Jon-Olov Vatn wrote: > > >> Pavlin Radoslavov skrev: >> >>> If you want multicast forwarding between two segments, you MUST use >>> a multicast routing protocol like PIM-SM. >>> The purpose of IGMP is to inform the multicast routing protocol >>> about directly connected receivers. Then it is up to the multicast >>> routing protocol to modify the multicast forwarding entries in the >>> kernel. >>> >>> >> Is it really necessary to use a multicast routing protocol, or could the >> forwarding tables be configured statically, e.g., with "route add ..."? >> > > In general you can't use commands like "route add" to install > multicast forwarding entries in the kernel. > > Unlike unicast static routes, multicast static routes shouldn't be > used primarily for the following two reasons: > > (a) multicast receiver membership is dynamic in nature and this > can't be tracked by (multicast) static routes. > (b) If you create a multicast routing loop (which can easily happen > with static routes), then you can easily bring down your network > due to the exponential amplification of the looping > packets. > > I haven't used smcroute, but if you use it you need to understand > the above two issues. > > Regards, > Pavlin > > >> I understand that it useful to use a routing protocol, but for a small >> network with one or two routers it may be of interest to support >> multicast routing without deploying, e.g., PIM-SM or DVMRP. When >> googling I found smcroute (http://www.cschill.de/smcroute/) which seems >> adequate for such situations, but I have not tried it and since the last >> release is from 2002 I'm a bit suspicious ... Anyone out there with >> experience of smcroute or setting up static multicast forward entries in >> Linux in general? >> >> Mvh J-O >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > >