From james.dutton@gmail.com Tue Oct 11 13:54:03 2005 From: james.dutton@gmail.com (James Courtier-Dutton) Date: Tue, 11 Oct 2005 13:54:03 +0100 Subject: [Xorp-users] IGMP Proxy Message-ID: Hi, I have a need for a box that can do the following. [ The Box ] IGMPv2 Host -> [ IGMPv2 Router -> IGMPv3 Host ] -> IGMPv3 Router. Essentially, I have a IGMPv3 Router can cannot do IGMPv2, and I need to link this with an IGMPv2 only capable Host. Would a stand alone xorp box be able to do this, or would it not be able to perform the upstream side IGMP messages, but instead try to do PIM-SM over the upstream interface. James From pavlin@icir.org Tue Oct 11 17:55:11 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 11 Oct 2005 09:55:11 -0700 Subject: [Xorp-users] IGMP Proxy In-Reply-To: Message from James Courtier-Dutton of "Tue, 11 Oct 2005 13:54:03 BST." Message-ID: <200510111655.j9BGtBc7007901@possum.icir.org> > Hi, > > I have a need for a box that can do the following. > [ The Box ] > IGMPv2 Host -> [ IGMPv2 Router -> IGMPv3 Host ] -> IGMPv3 Router. > > Essentially, I have a IGMPv3 Router can cannot do IGMPv2, and I need > to link this with an IGMPv2 only capable Host. > > Would a stand alone xorp box be able to do this, or would it not be > able to perform the upstream side IGMP messages, but instead try to do > PIM-SM over the upstream interface. No, unfortunately you cannot use XORP as an IGMP proxy. You could use it only as a PIM-SM router. Are you sure that your IGMPv3 router doesn't support IGMPv2? By definition (see RFC-3376) IGMPv2 is a subset of IGMPv3 so probably it is a question of just configuring that router? Pavlin From bms@spc.org Wed Oct 12 00:10:00 2005 From: bms@spc.org (Bruce M Simpson) Date: Wed, 12 Oct 2005 00:10:00 +0100 Subject: [Xorp-users] IGMP Proxy In-Reply-To: References: Message-ID: <20051011231000.GE76582@empiric.icir.org> On Tue, Oct 11, 2005 at 01:54:03PM +0100, James Courtier-Dutton wrote: > Would a stand alone xorp box be able to do this, or would it not be > able to perform the upstream side IGMP messages, but instead try to do > PIM-SM over the upstream interface. [IGMP proxy] After a brief intergurgulation with Bill Fenner: You could implement an IGMP proxy using the XORP class libraries. You'd need to do IGMP downstream, with an IGMP client half on the upstream. See: http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-06.txt XORP doesn't do this out of the box; a new process e.g. xorp_igmp_proxy would need to be written in order to do it. BMS From feamster@lcs.mit.edu Wed Oct 12 23:56:05 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 12 Oct 2005 18:56:05 -0400 Subject: [Xorp-users] problem with configure script in CVS? Message-ID: <20051012225605.GC10196@lcs.mit.edu> Is anyone else seeing this problem with the current CVS version of XORP? "./configure" fails at the following: config.status: error: cannot find input file: ospf/tools/Makefile.in -Nick From pavlin@icir.org Thu Oct 13 00:04:15 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 12 Oct 2005 16:04:15 -0700 Subject: [Xorp-users] problem with configure script in CVS? In-Reply-To: Message from Nick Feamster of "Wed, 12 Oct 2005 18:56:05 EDT." <20051012225605.GC10196@lcs.mit.edu> Message-ID: <200510122304.j9CN4F5i059753@possum.icir.org> > > Is anyone else seeing this problem with the current CVS version of XORP? > "./configure" fails at the following: > > config.status: error: cannot find input file: ospf/tools/Makefile.in Do you have that file in your tree? It should be there because it was committed to CVS two days ago. Pavlin From feamster@lcs.mit.edu Thu Oct 13 00:14:12 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 12 Oct 2005 19:14:12 -0400 Subject: [Xorp-users] problem with configure script in CVS? In-Reply-To: <200510122304.j9CN4F5i059753@possum.icir.org> References: <20051012225605.GC10196@lcs.mit.edu> <200510122304.j9CN4F5i059753@possum.icir.org> Message-ID: <20051012231412.GD10196@lcs.mit.edu> On Wed, Oct 12, 2005 at 04:04:15PM -0700, Pavlin Radoslavov wrote: > > > > Is anyone else seeing this problem with the current CVS version of XORP? > > "./configure" fails at the following: > > > > config.status: error: cannot find input file: ospf/tools/Makefile.in > > Do you have that file in your tree? > It should be there because it was committed to CVS two days ago. No, the file wasn't there; the directory was present but empty. For whatever reason, I tried another cvs update (with '-d') just now, which did the trick. From kristian@juniks.net Thu Oct 13 23:23:51 2005 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 14 Oct 2005 00:23:51 +0200 Subject: [Xorp-users] BGP connection stays up!? Message-ID: <20051013222351.GA3828@juniks.net> Am I the only one having trouble with my BGP sessions remaining despite the fact that I remove them from my configuration? Kristian From feamster@lcs.mit.edu Fri Oct 14 04:23:39 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 13 Oct 2005 23:23:39 -0400 Subject: [Xorp-users] invalid mandatory variable targetname Message-ID: <20051014032339.GB29504@lcs.mit.edu> Has anyone else received said error or know what it means? Even when supplying totally empty configuration file, or a minimal default, I am getting the following: [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Templates directory := /usr/local/xorp/etc/templates [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Xrl targets directory := /usr/local/xorp/xrl/targets [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Execute Xrls := true [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Restart failed processes := false [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Print verbose information := true [ 2005/10/13 23:22:36 ERROR xorp_rtrmgr:31215 RTRMGR +240 main_rtrmgr.cc run ] Shutting down due to an init error: Invalid mandatory variable targetname From pavlin@icir.org Fri Oct 14 05:37:53 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 13 Oct 2005 21:37:53 -0700 Subject: [Xorp-users] invalid mandatory variable targetname In-Reply-To: Message from Nick Feamster of "Thu, 13 Oct 2005 23:23:39 EDT." <20051014032339.GB29504@lcs.mit.edu> Message-ID: <200510140437.j9E4brF6092853@possum.icir.org> > Has anyone else received said error or know what it means? Even when > supplying totally empty configuration file, or a minimal default, I am > getting the following: > > [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Templates directory := > /usr/local/xorp/etc/templates > [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Xrl targets directory > := /usr/local/xorp/xrl/targets > [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Execute Xrls := true > [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Restart failed > processes := false > [ 2005/10/13 23:22:35 TRACE xorp_rtrmgr RTRMGR ] Print verbose > information := true > [ 2005/10/13 23:22:36 ERROR xorp_rtrmgr:31215 RTRMGR +240 > main_rtrmgr.cc run ] Shutting down due to an init error: Invalid mandatory variable targetname It looks like there is some problem with your template files. My guess is that you have installed in /usr/local/xorp an older version of XORP that uses slightly different template format (or maybe you have old leftover template files). Now when you start the most recent XORP instance, it doesn't like something inside those obsolete template files (e.g., probably because of some changes in the syntax for referring mandatory variables). I'd recommend to remove everything under /usr/local/xorp and to try again (e.g., either reinstall XORP or just run it from the compilation directory). Pavlin From atanu@ICSI.Berkeley.EDU Fri Oct 14 16:54:15 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 14 Oct 2005 08:54:15 -0700 Subject: [Xorp-users] BGP connection stays up!? In-Reply-To: Message from Kristian Larsson of "Fri, 14 Oct 2005 00:23:51 +0200." <20051013222351.GA3828@juniks.net> Message-ID: <51217.1129305255@tigger.icir.org> Hi, I have just checked in a fix, thanks for the report. Atanu. >>>>> "Kristian" == Kristian Larsson writes: Kristian> Am I the only one having trouble with my BGP sessions Kristian> remaining despite the fact that I remove them from my Kristian> configuration? Kristian> Kristian Kristian> _______________________________________________ Xorp-users Kristian> mailing list Xorp-users@xorp.org Kristian> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian@juniks.net Sat Oct 15 01:45:30 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sat, 15 Oct 2005 02:45:30 +0200 Subject: [Xorp-users] Policy... Message-ID: <20051015004530.GA2824@juniks.net> How do I add several elements to a network4-list? and why is it called "network4-list", every other router implementation I know call them "prefix-list". And the "elements: " part is superflous, is it not? JunOS prefix-list: policy-options { prefix-list test { 192.168.0.0/24; 192.168.1.0/24; } } nice and clean without the elements part. :) Kristian. From caddisconsulting@yahoo.com Sat Oct 15 02:04:38 2005 From: caddisconsulting@yahoo.com (Mike Horn) Date: Fri, 14 Oct 2005 19:04:38 -0600 Subject: [Bulk] [Xorp-users] Policy... In-Reply-To: <20051015004530.GA2824@juniks.net> Message-ID: <200510150105.j9F156O5080280@wyvern.icir.org> Kristian, You need to separate each element with a comma, so a list would be entered: network4-list 192.168.1.0/24,192.168.2.0/24 -mike -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Kristian Larsson Sent: Friday, October 14, 2005 6:46 PM To: xorp-users@xorp.org Subject: [Bulk] [Xorp-users] Policy... How do I add several elements to a network4-list? and why is it called "network4-list", every other router implementation I know call them "prefix-list". And the "elements: " part is superflous, is it not? JunOS prefix-list: policy-options { prefix-list test { 192.168.0.0/24; 192.168.1.0/24; } } nice and clean without the elements part. :) Kristian. _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian@juniks.net Sat Oct 15 09:59:51 2005 From: kristian@juniks.net ('Kristian Larsson') Date: Sat, 15 Oct 2005 10:59:51 +0200 Subject: [Bulk] [Xorp-users] Policy... In-Reply-To: <200510150105.j9F156O5080280@wyvern.icir.org> References: <20051015004530.GA2824@juniks.net> <200510150105.j9F156O5080280@wyvern.icir.org> Message-ID: <20051015085951.GB7368@juniks.net> Ah, I see. It's a icky bit of a pain editing a network4-list with say 100 prefixes this way. Another reason xorp should utilize juniper style set/rename/delete commands... Kristian. On Fri, Oct 14, 2005 at 07:04:38PM -0600, Mike Horn wrote: > Kristian, > > You need to separate each element with a comma, so a list would be entered: > > network4-list 192.168.1.0/24,192.168.2.0/24 > > -mike > > -----Original Message----- > From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf > Of Kristian Larsson > Sent: Friday, October 14, 2005 6:46 PM > To: xorp-users@xorp.org > Subject: [Bulk] [Xorp-users] Policy... > > How do I add several elements to a network4-list? > and why is it called "network4-list", every other router implementation I > know call them "prefix-list". > And the "elements: " part is superflous, is it not? > > JunOS prefix-list: > policy-options { > prefix-list test { > 192.168.0.0/24; > 192.168.1.0/24; > } > } > nice and clean without the elements part. :) > > Kristian. > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From feamster@lcs.mit.edu Mon Oct 17 18:43:26 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 13:43:26 -0400 Subject: [Xorp-users] help establishing OSPF adjacencies Message-ID: <20051017174326.GB21551@lcs.mit.edu> Hi, I can't seem to find much documentation on configuring OSPF in XORP, which is understandable since it is quite new. btw, thanks for implementing this! I am trying to get an adjacency established between two nodes. Standard error/xorpsh shows me this on the two machines. Both of the eth0 interfaces below are configured with a prefix-length of /24 so they should, in theory, be in the same subnet. I'm wondering why the LSA databases below don't show the adjacency. Any potential hangups I should know about? Thanks, Nick Machine 1: ---------- Standard error (LSA announcements) ... [ 22201 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = 128.31.1.14, dst = 224.0.0.5, payload_size = 44 ... xorpsh Xorp> show ospf4 database 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.14 128.31.1.14 0x80000001 326 0x2 0x3e12 36 interface eth0 { description "ethernet adapter" disable: false discard: true vif eth0 { disable: false address 128.31.1.14 { prefix-length: 24 disable: false } } } .... ospf4 { router-id: 128.31.1.14 area 0.0.0.0 { interface eth0 { vif eth0 { address 128.31.1.14 { interface-cost: 5 } } } } } Machine 2: ---------- [ 18333 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = 128.31.1.15, dst = 224.0.0.5, payload_size = 44 xorpsh Xorp> show ospf4 database 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.15 128.31.1.15 0x80000001 326 0x2 0x3e12 36 From feamster@lcs.mit.edu Mon Oct 17 21:26:08 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 16:26:08 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <20051017174326.GB21551@lcs.mit.edu> References: <20051017174326.GB21551@lcs.mit.edu> Message-ID: <20051017202608.GA23056@lcs.mit.edu> Just to follow up with some more information: I see messages such as: [ 4251 +430 xrl_io.cc join_multicast_group ] Join Interface eth0 Vif eth0 mcast 224.0.0.5 ] in the logs. I don't understand what's going on here, but I can't help but wonder if this has anything to do with these messages: [ 4251 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = 128.31.1.14, dst = 224.0.0.5, payload_size = 44 I'm puzzled, since I didn't configure anything having to do with multicast. Since these messages seem to disappear when I disable OSPF, I'm wondering if XORP's OSPF somehow relies on multicast to distribute LSAs, and, if so, how I should be configuring multicast to get these adjacencies exchanged properly? The only other clue I see in the logs is: [ 2005/10/17 16:20:52 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(eth0/eth0) State(Down) which I'm not certain how to interpret. Could "State(Down)" be the reason I don't see anything in other OSPF LSA databases, for example? thanks, Nick p.s. I also see the following error message when starting up: [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] User-level Click command (~/demo/click) failed. I did not see this problem when running XORP 1.1, but now it seems I'm having to start click manually because XORP does not fire it up properly. Has the mechanism for starting up click in XORP changed since version 1.1? On Mon, Oct 17, 2005 at 01:43:26PM -0400, Nick Feamster wrote: > Hi, > > I can't seem to find much documentation on configuring OSPF in XORP, > which is understandable since it is quite new. btw, thanks for > implementing this! > > I am trying to get an adjacency established between two nodes. Standard > error/xorpsh shows me this on the two machines. Both of the eth0 > interfaces below are configured with a prefix-length of /24 so they > should, in theory, be in the same subnet. > > I'm wondering why the LSA databases below don't show the adjacency. Any > potential hangups I should know about? > > Thanks, > Nick > > > Machine 1: > ---------- > Standard error (LSA announcements) > ... > [ 22201 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = > 128.31.1.14, dst = 224.0.0.5, payload_size = 44 > ... > > > xorpsh > Xorp> show ospf4 database 0.0.0.0 > Type ID Adv Rtr Seq Age Opt Cksum Len > Router *128.31.1.14 128.31.1.14 0x80000001 326 0x2 0x3e12 36 > > interface eth0 { > description "ethernet adapter" > disable: false > discard: true > vif eth0 { > disable: false > address 128.31.1.14 { > prefix-length: 24 > disable: false > } > } > } > > .... > > ospf4 { > router-id: 128.31.1.14 > > area 0.0.0.0 { > interface eth0 { > vif eth0 { > address 128.31.1.14 { > interface-cost: 5 > } > } > } > } > } > > > Machine 2: > ---------- > [ 18333 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = > 128.31.1.15, dst = 224.0.0.5, payload_size = 44 > > xorpsh > Xorp> show ospf4 database 0.0.0.0 > Type ID Adv Rtr Seq Age Opt Cksum Len > Router *128.31.1.15 128.31.1.15 0x80000001 326 0x2 0x3e12 36 > > > From pavlin@icir.org Mon Oct 17 22:10:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 14:10:27 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 16:26:08 EDT." <20051017202608.GA23056@lcs.mit.edu> Message-ID: <200510172110.j9HLARaM027960@possum.icir.org> > p.s. I also see the following error message when starting up: > [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] User-level Click command (~/demo/click) failed. > > I did not see this problem when running XORP 1.1, but now it seems I'm > having to start click manually because XORP does not fire it up > properly. Has the mechanism for starting up click in XORP changed since > version 1.1? Yes, the mechanism has changed. Please send me your fea+click configuration. Pavlin From atanu@ICSI.Berkeley.EDU Mon Oct 17 22:11:25 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Oct 2005 14:11:25 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 16:26:08 EDT." <20051017202608.GA23056@lcs.mit.edu> Message-ID: <51283.1129583485@tigger.icir.org> Hi, The messages of the form '[ 4251 +430 xrl_io.cc ...' are debugging output from OSPF. One of the things that they show are packets being sent and received by OSPF. OSPF uses multicast on broadcast media to distribute LSAs (with a TTL of 1), so this behaviour is correct. The TRACE messages are typically at the top of methods so they show the state on entry to the method. It is therefore correct that when a InterFaceUp event occurs that the state of the interface was down. Could you try disabling Click and see if an adjacency is still not formed. In order for an adjacency to be formed routers have to see each others hello packets. A hello packet contains a hello interval, a router dead interval and a list of other routers that have been seen on this interface. The hello interval and router dead interval have to match for an adjacency attempt to be made. As an optimisation on broadcast networks rather than forming an adjacency with every other router on the subnet a designated router and backup designated router are elected. The DR and BDR routers form adjacencies with all the routers and the routers in the other set form only two adjacencies. Two routers with the default configuration should try and form an adjacency. You should see TRACE messages of this form: [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) [ . TRACE .] Event(2-WayReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) I have replaced some of the output with '.'s. If you are not seeing Event(HelloReceived) then they are not seeing each others hello messages. Note the state is Full in this example. After I saw you original message I went back and checked that adjancencies are still being formed and they are. I found one thing a little puzzling the checksum for both routers for different LSAs is the same, is this the actual output? Atanu. >>>>> "Nick" == Nick Feamster writes: Nick> Just to follow up with some more information: I see messages Nick> such as: [ 4251 +430 xrl_io.cc join_multicast_group ] Join Nick> Interface eth0 Vif eth0 mcast 224.0.0.5 ] Nick> in the logs. I don't understand what's going on here, but I Nick> can't help but wonder if this has anything to do with these Nick> messages: [ 4251 +92 xrl_io.cc send ] send(interface = eth0, Nick> vif = eth0, src = 128.31.1.14, dst = 224.0.0.5, payload_size = Nick> 44 Nick> I'm puzzled, since I didn't configure anything having to do Nick> with multicast. Since these messages seem to disappear when I Nick> disable OSPF, I'm wondering if XORP's OSPF somehow relies on Nick> multicast to distribute LSAs, and, if so, how I should be Nick> configuring multicast to get these adjacencies exchanged Nick> properly? Nick> The only other clue I see in the logs is: [ 2005/10/17 Nick> 16:20:52 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Nick> Interface(eth0/eth0) State(Down) Nick> which I'm not certain how to interpret. Could "State(Down)" Nick> be the reason I don't see anything in other OSPF LSA Nick> databases, for example? Nick> thanks, Nick Nick> p.s. I also see the following error message when starting up: Nick> [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 Nick> module_manager.cc run ] Running module: fea Nick> (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] Nick> User-level Click command (~/demo/click) failed. Nick> I did not see this problem when running XORP 1.1, but now it Nick> seems I'm having to start click manually because XORP does not Nick> fire it up properly. Has the mechanism for starting up click Nick> in XORP changed since version 1.1? Nick> On Mon, Oct 17, 2005 at 01:43:26PM -0400, Nick Feamster wrote: >> Hi, >> >> I can't seem to find much documentation on configuring OSPF in >> XORP, which is understandable since it is quite new. btw, thanks >> for implementing this! >> >> I am trying to get an adjacency established between two nodes. >> Standard error/xorpsh shows me this on the two machines. Both of >> the eth0 interfaces below are configured with a prefix-length of >> /24 so they should, in theory, be in the same subnet. >> >> I'm wondering why the LSA databases below don't show the >> adjacency. Any potential hangups I should know about? >> >> Thanks, Nick >> >> >> Machine 1: >> ---------- >> Standard error (LSA announcements) ... [ 22201 +92 xrl_io.cc >> send ] send(interface = eth0, vif = eth0, src = 128.31.1.14, dst >> = 224.0.0.5, payload_size = 44 ... >> >> >> xorpsh Xorp> show ospf4 database 0.0.0.0 >> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.14 >> 128.31.1.14 0x80000001 326 0x2 0x3e12 36 >> >> interface eth0 { description "ethernet adapter" disable: false >> discard: true vif eth0 { disable: false address 128.31.1.14 { >> prefix-length: 24 disable: false } } } >> >> .... >> >> ospf4 { router-id: 128.31.1.14 >> >> area 0.0.0.0 { interface eth0 { vif eth0 { address 128.31.1.14 { >> interface-cost: 5 } } } } } >> >> >> Machine 2: >> ---------- >> [ 18333 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, >> src = 128.31.1.15, dst = 224.0.0.5, payload_size = 44 >> >> xorpsh Xorp> show ospf4 database 0.0.0.0 >> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.15 >> 128.31.1.15 0x80000001 326 0x2 0x3e12 36 >> >> >> Nick> _______________________________________________ Xorp-users Nick> mailing list Xorp-users@xorp.org Nick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Mon Oct 17 22:28:01 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 14:28:01 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Pavlin Radoslavov of "Mon, 17 Oct 2005 14:10:27 PDT." <200510172110.j9HLARaM027960@possum.icir.org> Message-ID: <200510172128.j9HLS1sq028169@possum.icir.org> > > p.s. I also see the following error message when starting up: > > [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] User-level Click command (~/demo/click) failed. > > > > I did not see this problem when running XORP 1.1, but now it seems I'm > > having to start click manually because XORP does not fire it up > > properly. Has the mechanism for starting up click in XORP changed since > > version 1.1? > > Yes, the mechanism has changed. Please send me your fea+click > configuration. A quick suggestion. Please use the full path name to the click binary instead of using "~". Previously the click binary and its arguments were executed via "sh -c" (and execve()). Now it is executed directly via execve() without "sh -c" and the "~" in the path name is not expanded. Pavlin From feamster@lcs.mit.edu Mon Oct 17 23:43:15 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 18:43:15 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510172110.j9HLARaM027960@possum.icir.org> References: <20051017202608.GA23056@lcs.mit.edu> <200510172110.j9HLARaM027960@possum.icir.org> Message-ID: <20051017224315.GB24605@lcs.mit.edu> Pavlin, On Mon, Oct 17, 2005 at 02:10:27PM -0700, Pavlin Radoslavov wrote: > > p.s. I also see the following error message when starting up: > > [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] User-level Click command (~/demo/click) failed. > > > > I did not see this problem when running XORP 1.1, but now it seems I'm > > having to start click manually because XORP does not fire it up > > properly. Has the mechanism for starting up click in XORP changed since > > version 1.1? > > Yes, the mechanism has changed. Please send me your fea+click > configuration. Thanks! Here's my current configuration. -Nick fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "~/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" user-click-config-generator-file: "~/demo/static_config" } } } From pavlin@icir.org Tue Oct 18 00:20:45 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 16:20:45 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 18:43:15 EDT." <20051017224315.GB24605@lcs.mit.edu> Message-ID: <200510172320.j9HNKjlv054086@possum.icir.org> > Pavlin, > > On Mon, Oct 17, 2005 at 02:10:27PM -0700, Pavlin Radoslavov wrote: > > > p.s. I also see the following error message when starting up: > > > [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485 module_manager.cc run ] Running module: fea (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ] User-level Click command (~/demo/click) failed. > > > > > > I did not see this problem when running XORP 1.1, but now it seems I'm > > > having to start click manually because XORP does not fire it up > > > properly. Has the mechanism for starting up click in XORP changed since > > > version 1.1? > > > > Yes, the mechanism has changed. Please send me your fea+click > > configuration. > > Thanks! Here's my current configuration. > > -Nick > > > fea { > unicast-forwarding4 { > disable: true > } > > click { > disable: false > > user-click { > disable: false > command-file: "~/demo/click" > command-extra-arguments: "-R" > command-execute-on-startup: true > control-address: 127.0.0.1 > control-socket-port: 13000 > startup-config-file: "/dev/null" > user-click-config-generator-file: "~/demo/static_config" > } > } > } I just did some tests, and it looks like that indeed the "~" as part of the file name is the problem. Please replace all path names in the Click configuration that contain "~" in the beginning with the absolute path name. Pavlin P.S. I just committed a Click-related bug fix to fea/ifconfig_set_click.cc rev. 1.30 so you may want to get the lastest CVS code, though that fix has nothing to do with your original error. From feamster@lcs.mit.edu Tue Oct 18 00:21:22 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 19:21:22 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <51283.1129583485@tigger.icir.org> References: <20051017202608.GA23056@lcs.mit.edu> <51283.1129583485@tigger.icir.org> Message-ID: <20051017232122.GH24605@lcs.mit.edu> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: > Hi, > > The messages of the form '[ 4251 +430 xrl_io.cc ...' are debugging > output from OSPF. One of the things that they show are packets being > sent and received by OSPF. > > OSPF uses multicast on broadcast media to distribute LSAs (with a TTL of > 1), so this behaviour is correct. OK. Thanks for the clarification. > The TRACE messages are typically at the top of methods so they show the > state on entry to the method. It is therefore correct that when a > InterFaceUp event occurs that the state of the interface was down. > > Could you try disabling Click and see if an adjacency is still not > formed. Yes, I think I did actually try that. I removed it from the XORP configuration, at least. What should I configure in the FEA instead? Do I need to configure multicast? Also, when you say "broadcast media", what do you mean? I'd think that would mean the broadcast address of the subnet, 128.31.1.255. What's this 224... multicast address, and do I need to configure something in XORP to make certain it's reachable? > In order for an adjacency to be formed routers have to see each others > hello packets. A hello packet contains a hello interval, a router dead > interval and a list of other routers that have been seen on this > interface. The hello interval and router dead interval have to match for > an adjacency attempt to be made. As an optimisation on broadcast > networks rather than forming an adjacency with every other router on the > subnet a designated router and backup designated router are elected. > The DR and BDR routers form adjacencies with all the routers and the > routers in the other set form only two adjacencies. > > Two routers with the default configuration should try and form an > adjacency. You should see TRACE messages of this form: > > [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) > [ . TRACE .] Event(2-WayReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) > > I have replaced some of the output with '.'s. > > If you are not seeing Event(HelloReceived) then they are not seeing each > others hello messages. Note the state is Full in this example. I definitely don't see these. > After I saw you original message I went back and checked that > adjancencies are still being formed and they are. > > I found one thing a little puzzling the checksum for both routers for > different LSAs is the same, is this the actual output? No, I had a copy/paste error. The checksums are different. -Nick From feamster@lcs.mit.edu Tue Oct 18 00:32:12 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 19:32:12 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510172320.j9HNKjlv054086@possum.icir.org> References: <20051017224315.GB24605@lcs.mit.edu> <200510172320.j9HNKjlv054086@possum.icir.org> Message-ID: <20051017233212.GL24605@lcs.mit.edu> On Mon, Oct 17, 2005 at 04:20:45PM -0700, Pavlin Radoslavov wrote: > I just did some tests, and it looks like that indeed the "~" as part > of the file name is the problem. Please replace all path names in > the Click configuration that contain "~" in the beginning with the > absolute path name. Yes, that also fixed my problems. Thanks! -Nick > P.S. I just committed a Click-related bug fix to > fea/ifconfig_set_click.cc rev. 1.30 so you may want to get the > lastest CVS code, though that fix has nothing to do with your > original error. ok, I'll grab it. thanks very much. From feamster@lcs.mit.edu Tue Oct 18 01:02:17 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 20:02:17 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510172128.j9HLS1sq028169@possum.icir.org> References: <200510172110.j9HLARaM027960@possum.icir.org> <200510172128.j9HLS1sq028169@possum.icir.org> Message-ID: <20051018000217.GN24605@lcs.mit.edu> Hi Pavlin, On Mon, Oct 17, 2005 at 02:28:01PM -0700, Pavlin Radoslavov wrote: > A quick suggestion. Please use the full path name to the click > binary instead of using "~". Previously the click binary and its > arguments were executed via "sh -c" (and execve()). > Now it is executed directly via execve() without "sh -c" and the "~" > in the path name is not expanded. I spoke a little too soon, perhaps. It's true now that I don't have errors on click startup, and the click control socket appears to be running, but it's not reading the configuration correctly, I don't think. So, ps shows me this: click -f /dev/null -p 13000 -R and the control socket shows me this (no configuration...huh?): % telnet planetlab4.csail.mit.edu 13000 Trying 128.31.1.14... Connected to planetlab4.csail.mit.edu (128.31.1.14). Escape character is '^]'. Click::ControlSocket/1.1 read config 200 Read handler 'config' OK DATA 0 For reference, here's the fea/click config I'm running: fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "/home/mit_rcp/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/dev/null" user-click-config-generator-file: "/home/mit_rcp/demo/static_config" } } } -Nick From pavlin@icir.org Tue Oct 18 01:21:13 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 17:21:13 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 20:02:17 EDT." <20051018000217.GN24605@lcs.mit.edu> Message-ID: <200510180021.j9I0LDaQ054662@possum.icir.org> > Hi Pavlin, > > On Mon, Oct 17, 2005 at 02:28:01PM -0700, Pavlin Radoslavov wrote: > > A quick suggestion. Please use the full path name to the click > > binary instead of using "~". Previously the click binary and its > > arguments were executed via "sh -c" (and execve()). > > Now it is executed directly via execve() without "sh -c" and the "~" > > in the path name is not expanded. > > I spoke a little too soon, perhaps. It's true now that I don't have > errors on click startup, and the click control socket appears to be > running, but it's not reading the configuration correctly, I don't > think. So, ps shows me this: > > click -f /dev/null -p 13000 -R > > and the control socket shows me this (no configuration...huh?): > > % telnet planetlab4.csail.mit.edu 13000 > Trying 128.31.1.14... > Connected to planetlab4.csail.mit.edu (128.31.1.14). > Escape character is '^]'. > Click::ControlSocket/1.1 > read config > 200 Read handler 'config' OK > DATA 0 Did you apply the fix in the CVS? That fix eventually should take care of the above problem. Pavlin > > > For reference, here's the fea/click config I'm running: > > fea { > unicast-forwarding4 { > disable: true > } > > click { > disable: false > > user-click { > disable: false > command-file: "/home/mit_rcp/demo/click" > command-extra-arguments: "-R" > command-execute-on-startup: true > control-address: 127.0.0.1 > control-socket-port: 13000 > startup-config-file: "/dev/null" > user-click-config-generator-file: "/home/mit_rcp/demo/static_config" > } > } > } > > -Nick > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Tue Oct 18 01:22:21 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Oct 2005 17:22:21 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 19:21:22 EDT." <20051017232122.GH24605@lcs.mit.edu> Message-ID: <12689.1129594941@tigger.icir.org> Hi, Responses inline. Nick> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: >> Hi, >> >> The messages of the form '[ 4251 +430 xrl_io.cc ...' are >> debugging output from OSPF. One of the things that they show are >> packets being sent and received by OSPF. >> >> OSPF uses multicast on broadcast media to distribute LSAs (with a >> TTL of 1), so this behaviour is correct. Nick> OK. Thanks for the clarification. >> The TRACE messages are typically at the top of methods so they >> show the state on entry to the method. It is therefore correct >> that when a InterFaceUp event occurs that the state of the >> interface was down. >> >> Could you try disabling Click and see if an adjacency is still >> not formed. Nick> Yes, I think I did actually try that. I removed it from the Nick> XORP configuration, at least. What should I configure in the Nick> FEA instead? Do I need to configure multicast? Also, when Nick> you say "broadcast media", what do you mean? I'd think that Nick> would mean the broadcast address of the subnet, 128.31.1.255. Nick> What's this 224... multicast address, and do I need to Nick> configure something in XORP to make certain it's reachable? OSPF supports a number of different network types one of them is Broadcast the definition from the RFC is below. The XORP configuration defaults to broadcast (point-2-point and point-to-multipoint are also supported). You shouldn't need to configure anything in order to support the sending of the multicast packets. I have included a complete config that I am using below. ---------------------------------------- RFC 2328 Broadcast networks Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these nets using OSPF's Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The OSPF protocol makes further use of multicast capabilities, if they exist. Each pair of routers on a broadcast network is assumed to be able to communicate directly. An ethernet is an example of a broadcast network. ---------------------------------------- ---------------------------------------- interfaces { interface en1 { vif en1 { address 10.0.1.6 { prefix-length: 16 } } } } protocols { ospf4 { router-id: 10.0.1.6 area 0.0.0.0 { interface en1 { vif en1 { address 10.0.1.6 { } } } } } } ---------------------------------------- >> In order for an adjacency to be formed routers have to see each >> others hello packets. A hello packet contains a hello interval, a >> router dead interval and a list of other routers that have been >> seen on this interface. The hello interval and router dead >> interval have to match for an adjacency attempt to be made. As an >> optimisation on broadcast networks rather than forming an >> adjacency with every other router on the subnet a designated >> router and backup designated router are elected. The DR and BDR >> routers form adjacencies with all the routers and the routers in >> the other set form only two adjacencies. >> >> Two routers with the default configuration should try and form an >> adjacency. You should see TRACE messages of this form: >> >> [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) N.(128.31.1.14) >> State(Full) [ . TRACE .] Event(2-WayReceived) I.(fxp0/fxp0) >> N.(128.31.1.14) State(Full) >> >> I have replaced some of the output with '.'s. >> >> If you are not seeing Event(HelloReceived) then they are not >> seeing each others hello messages. Note the state is Full in this >> example. Nick> I definitely don't see these. Then the routers are not seeing each others packets. >> After I saw you original message I went back and checked that >> adjancencies are still being formed and they are. >> >> I found one thing a little puzzling the checksum for both routers >> for different LSAs is the same, is this the actual output? Nick> No, I had a copy/paste error. The checksums are different. Good - thats what I guessed:-). Atanu. From feamster@lcs.mit.edu Tue Oct 18 01:28:59 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 20:28:59 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510180021.j9I0LDaQ054662@possum.icir.org> References: <20051018000217.GN24605@lcs.mit.edu> <200510180021.j9I0LDaQ054662@possum.icir.org> Message-ID: <20051018002859.GQ24605@lcs.mit.edu> On Mon, Oct 17, 2005 at 05:21:13PM -0700, Pavlin Radoslavov wrote: > > % telnet planetlab4.csail.mit.edu 13000 > > Trying 128.31.1.14... > > Connected to planetlab4.csail.mit.edu (128.31.1.14). > > Escape character is '^]'. > > Click::ControlSocket/1.1 > > read config > > 200 Read handler 'config' OK > > DATA 0 > > Did you apply the fix in the CVS? > That fix eventually should take care of the above problem. I am building the new code right now. :) Just to note, when I do: startup-config-file: "/home/mit_rcp/demo/planetlab4.csail.mit.edu.click" things work fine. It's only when I use xorp to invoke a generator script (which is doing nothing but cat-ing a file at this point) that I run into problems. -Nick From feamster@lcs.mit.edu Tue Oct 18 02:55:42 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 21:55:42 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <51283.1129583485@tigger.icir.org> References: <20051017202608.GA23056@lcs.mit.edu> <51283.1129583485@tigger.icir.org> Message-ID: <20051018015542.GT24605@lcs.mit.edu> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: > The messages of the form '[ 4251 +430 xrl_io.cc ...' are debugging > output from OSPF. One of the things that they show are packets being > sent and received by OSPF. > > OSPF uses multicast on broadcast media to distribute LSAs (with a TTL of > 1), so this behaviour is correct. I'm wondering how I can debug connectivity to membership in the multicast group 224.0.0.5, to where the LSAs are being sent? ping doesn't seem to work, for example. > The TRACE messages are typically at the top of methods so they show the > state on entry to the method. It is therefore correct that when a > InterFaceUp event occurs that the state of the interface was down. > > Could you try disabling Click and see if an adjacency is still not > formed. I disabled click. The only thing I have in the fea is : fea { unicast-forwarding4 { disable: true } } should the fea have something else? > Two routers with the default configuration should try and form an > adjacency. You should see TRACE messages of this form: > > [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) > [ . TRACE .] Event(2-WayReceived) I.(fxp0/fxp0) N.(128.31.1.14) State(Full) > > I have replaced some of the output with '.'s. The last thing I see is: [ 2005/10/17 21:36:00 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(eth0/eth0) State(Down) I don't see any attempts to send a hello packet, even. Is that a problem? -Nick > If you are not seeing Event(HelloReceived) then they are not seeing each > others hello messages. Note the state is Full in this example. From pavlin@icir.org Tue Oct 18 03:25:59 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 19:25:59 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 21:55:42 EDT." <20051018015542.GT24605@lcs.mit.edu> Message-ID: <200510180225.j9I2PxVd057172@possum.icir.org> > On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: > > The messages of the form '[ 4251 +430 xrl_io.cc ...' are debugging > > output from OSPF. One of the things that they show are packets being > > sent and received by OSPF. > > > > OSPF uses multicast on broadcast media to distribute LSAs (with a TTL of > > 1), so this behaviour is correct. > > I'm wondering how I can debug connectivity to membership in the > multicast group 224.0.0.5, to where the LSAs are being sent? ping > doesn't seem to work, for example. First, can you confirm whether you still have the same problem even without using Click? I'd recommend to check whether there are any firewall rules in your kernel that may be preventing you from receiving the traffic (e.g., rules that throw away the multicast packets, etc). To debug the problem you can try to use the nemesis-ospf program from the Nemesis project (http://nemesis.sourceforge.net/). You can use that program to generate your own OSPF packets. > > The TRACE messages are typically at the top of methods so they show the > > state on entry to the method. It is therefore correct that when a > > InterFaceUp event occurs that the state of the interface was down. > > > > Could you try disabling Click and see if an adjacency is still not > > formed. > > I disabled click. The only thing I have in the fea is : > > fea { > unicast-forwarding4 { > disable: true > } > } > > should the fea have something else? You don't need anything else in the fea, but "disable: true" should be "disable: false". Pavlin From feamster@lcs.mit.edu Tue Oct 18 04:59:35 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Mon, 17 Oct 2005 23:59:35 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510180225.j9I2PxVd057172@possum.icir.org> References: <20051018015542.GT24605@lcs.mit.edu> <200510180225.j9I2PxVd057172@possum.icir.org> Message-ID: <20051018035935.GA24605@lcs.mit.edu> On Mon, Oct 17, 2005 at 07:25:59PM -0700, Pavlin Radoslavov wrote: > First, can you confirm whether you still have the same problem even > without using Click? Yes, I do. > I'd recommend to check whether there are any firewall rules in your > kernel that may be preventing you from receiving the traffic (e.g., > rules that throw away the multicast packets, etc). > > To debug the problem you can try to use the nemesis-ospf program > from the Nemesis project (http://nemesis.sourceforge.net/). > You can use that program to generate your own OSPF packets. OK, will do. there may be something blocking the multicast packets or something. I'll have a look with tcpdump, too. > > fea { > > unicast-forwarding4 { > > disable: true > > } > > } > > > > should the fea have something else? > > You don't need anything else in the fea, but "disable: true" should > be "disable: false". In that case, I get: [ 2005/10/17 23:54:52 ERROR xorp_rtrmgr:2460 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot open file /proc/sys/net/ipv4/ip_forward for writing: Operation not permitted Even when running as root, which may be a problem with planetlab. Hmm. -Nick From pavlin@icir.org Tue Oct 18 05:09:00 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 17 Oct 2005 21:09:00 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Mon, 17 Oct 2005 23:59:35 EDT." <20051018035935.GA24605@lcs.mit.edu> Message-ID: <200510180409.j9I490wd060340@possum.icir.org> > > > fea { > > > unicast-forwarding4 { > > > disable: true > > > } > > > } > > > > > > should the fea have something else? > > > > You don't need anything else in the fea, but "disable: true" should > > be "disable: false". > > In that case, I get: > > [ 2005/10/17 23:54:52 ERROR xorp_rtrmgr:2460 RTRMGR +671 > master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command > failed Cannot open file /proc/sys/net/ipv4/ip_forward for writing: > Operation not permitted > > Even when running as root, which may be a problem with planetlab. Hmm. Yes, to enable the unicast forwarding on the system you have to be a root. In fact, you have to be root for other operations including sending the OSPF raw packets. To track-down the above error, the first thing to check is whether the above file (/proc/sys/net/ipv4/ip_forward) really exists and whether it is writeable (by root). In any case, I believe the problem you are having with OSPF is not related to the IP forwarding flag, but it is better to fix the above problem first. Pavlin From riccardo.sciaccaluga@tin.it" I think i just did a sintax mistake in my config.boot file! I simply tried to manage two static route on my network interfaces with the following config file: interfaces { interface eth6 { description:"data interface" disable:false vif eth6 { disable:false address 192.168.1.6 { prefix-length: 24 broadcast: 192.168.1.255 disable:false } } } interface eth7 { description:"data interface" disable:false vif eth7 { disable:false address 192.168.1.7 { prefix-length: 24 broadcast: 192.168.1.255 disable:false } } } interface eth8 { description:"data interface" disable:false vif eth8 { disable:false address 192.168.1.8 { prefix-length: 24 } } interface eth9 { description:"data interface" disable: false vif eth9 { disable:false address 192.168.1.9 { prefix-length: 24 broadcast: 192.168.1.255 disable:false } } } } fea { unicast-forwarding4 { disable:false } } protocols { static { route4 192.168.7.0/24 { next-hop: 192.168.1.9 metric:1 } } static { route4 192.168.8.0/24 { next-hop: 192.168.1.8 metric:1 } } } The problem i had is this:monitoring the unicast static routes i set i found that the device both of them are matched with eth6!how can i do to match for example 192.168.7.0/24 subnet with the net interface eth9 and 192.168.8.0/24 subnet with the net interface ath8? Thanks in advance From pavlin@icir.org Tue Oct 18 19:20:00 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Oct 2005 11:20:00 -0700 Subject: [Xorp-users] How can i match a static route with the right interface? In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Tue, 18 Oct 2005 16:52:14 BST." <3892247.1129650734889.JavaMail.root@pswm12.cp.tin.it> Message-ID: <200510181820.j9IIK0Kp068156@possum.icir.org> > Return-Path: xorp-users-admin@xorp.org > Delivery-Date: Tue Oct 18 08:53:49 2005 > Delivery-Date: Tue, 18 Oct 2005 08:53:48 -0700 > Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) > by possum.icir.org (8.12.11/8.12.11) with ESMTP id j9IFrmUn066652 > for ; Tue, 18 Oct 2005 08:53:48 -0700 (PDT) > (envelope-from xorp-users-admin@xorp.org) > Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) > by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j9IFriJV045862; > Tue, 18 Oct 2005 08:53:44 -0700 (PDT) > (envelope-from xorp-users-admin@xorp.org) > Received: from fruitcake.ICSI.Berkeley.EDU (localhost [127.0.0.1]) > by fruitcake.ICSI.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id j9IFr5YS018160; > Tue, 18 Oct 2005 08:53:05 -0700 (PDT) > Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) > by fruitcake.ICSI.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id j9IFqMYS018032 > for ; Tue, 18 Oct 2005 08:52:23 -0700 (PDT) > Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) > by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id j9IFqLTq045838 > for ; Tue, 18 Oct 2005 08:52:22 -0700 (PDT) > (envelope-from riccardo.sciaccaluga@tin.it) > Received: from pswm12.cp.tin.it (212.216.176.78) by vsmtp2.tin.it (7.2.060.1) > id 435500ED000131E4; Tue, 18 Oct 2005 17:52:12 +0200 > Message-ID: <3892247.1129650734889.JavaMail.root@pswm12.cp.tin.it> > From: "riccardo.sciaccaluga@tin.it" > Reply-To: "riccardo.sciaccaluga@tin.it" > To: xorp-users@xorp.org > Cc: roberto@reti.dist.unige.it > Mime-Version: 1.0 > Content-Type: text/plain;charset="UTF-8" > Content-Transfer-Encoding: 7bit > X-Originating-IP: 130.251.17.165 > Subject: [Xorp-users] How can i match a static route with the right interface? > Sender: xorp-users-admin@xorp.org > Errors-To: xorp-users-admin@xorp.org > X-BeenThere: xorp-users@xorp.org > X-Mailman-Version: 2.0 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: Mailing list for general XORP router discussion. > List-Unsubscribe: , > > List-Archive: > Date: Tue, 18 Oct 2005 16:52:14 +0100 (GMT+01:00) > > I think i just did a sintax mistake in my config.boot file! > I simply > tried to manage two static route on my network interfaces with the > following config file: > > > interfaces { > interface eth6 { > > description:"data interface" > disable:false > vif eth6 { > disable:false > address 192.168.1.6 { > prefix-length: 24 > > broadcast: 192.168.1.255 > disable:false > } > } > } > interface eth7 { > description:"data interface" > disable:false > vif > eth7 { > disable:false > address > 192.168.1.7 { > prefix-length: 24 > broadcast: 192.168.1.255 > disable:false > } > } > } > interface eth8 { > description:"data > interface" > disable:false > vif eth8 { > > disable:false > address 192.168.1.8 { > prefix-length: 24 > } > > } > interface eth9 { > description:"data interface" > disable: > false > vif eth9 { > disable:false > > address 192.168.1.9 { > prefix-length: 24 > broadcast: 192.168.1.255 > disable:false > } > } > } > } > fea { > unicast-forwarding4 { > > disable:false > } > } > protocols { > static { > route4 > 192.168.7.0/24 { > next-hop: 192.168.1.9 > > metric:1 > } > } > static { > route4 > 192.168.8.0/24 { > next-hop: 192.168.1.8 > > metric:1 > } > } > } > > > The > problem i had is this:monitoring the unicast static routes i set i > found that the device both of them are matched with eth6!how can i do The unusual thing about the above configuration is that all network interfaces have IP addresses that belong to the same subnet. This implies all of them are connected to the same LAN. Try to use interface-route4 instead of route4 to add the static routes. However, note that with interface-route4 you specify the next-hop by using the name of the interface/vif rather the next-hop router address. Pavlin From riccardo.sciaccaluga@tin.it" Does anybody know when the xorp new release will be available(with ospf protocol support) to download? From feamster@lcs.mit.edu Wed Oct 19 17:59:55 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 19 Oct 2005 12:59:55 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <12689.1129594941@tigger.icir.org> References: <20051017232122.GH24605@lcs.mit.edu> <12689.1129594941@tigger.icir.org> Message-ID: <20051019165955.GI10851@lcs.mit.edu> On Mon, Oct 17, 2005 at 05:22:21PM -0700, Atanu Ghosh wrote: > ---------------------------------------- RFC 2328 > Broadcast networks > Networks supporting many (more than two) attached routers, > together with the capability to address a single physical > message to all of the attached routers (broadcast). > Neighboring routers are discovered dynamically on these nets > using OSPF's Hello Protocol. The Hello Protocol itself > takes advantage of the broadcast capability. The OSPF > protocol makes further use of multicast capabilities, if > they exist. Each pair of routers on a broadcast network is > assumed to be able to communicate directly. An ethernet is > an example of a broadcast network. > ---------------------------------------- Why not just use ethernet as the broadcast medium, then? > Then the routers are not seeing each others packets. Yep. I suspect that the routers are not joining the multicast group properly. tcpdump shows : 12:58:16.282879 IP planetlab4.csail.mit.edu > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 44 and 12:55:03.896093 IP planetlab5.csail.mit.edu > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 44 but, for some reason, they aren't hearing each other's hellos. I suspect it's a problem with multicast. I see the attemt to join the multicast group in the XORP debug: [ 1068 +430 xrl_io.cc join_multicast_group ] Join Interface eth0 Vif eth0 mcast 224.0.0.5 But I suspect that it is not succeeding for some reason. -Nick > > >> After I saw you original message I went back and checked that > >> adjancencies are still being formed and they are. > >> > >> I found one thing a little puzzling the checksum for both routers > >> for different LSAs is the same, is this the actual output? > > Nick> No, I had a copy/paste error. The checksums are different. > > Good - thats what I guessed:-). > > Atanu. From pavlin@icir.org Wed Oct 19 19:01:18 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 19 Oct 2005 11:01:18 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Wed, 19 Oct 2005 12:59:55 EDT." <20051019165955.GI10851@lcs.mit.edu> Message-ID: <200510191801.j9JI1IZO079284@possum.icir.org> > > Then the routers are not seeing each others packets. > > > Yep. I suspect that the routers are not joining the multicast group > properly. tcpdump shows : > > 12:58:16.282879 IP planetlab4.csail.mit.edu > OSPF-ALL.MCAST.NET: > OSPFv2, Hello (1), length: 44 > > and > > 12:55:03.896093 IP planetlab5.csail.mit.edu > OSPF-ALL.MCAST.NET: > OSPFv2, Hello (1), length: 44 > > but, for some reason, they aren't hearing each other's hellos. I > suspect it's a problem with multicast. I see the attemt to join the > multicast group in the XORP debug: > > [ 1068 +430 xrl_io.cc join_multicast_group ] Join Interface eth0 Vif > eth0 mcast 224.0.0.5 > > But I suspect that it is not succeeding for some reason. What is the output of "netstat -g"? It will show the multicast groups joined on each interface. If the group is joined, then I suspect there are some firewall filters on the receiver side that prevent the multicast packets from reaching the receiver. Pavlin From feamster@lcs.mit.edu Wed Oct 19 19:26:46 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 19 Oct 2005 14:26:46 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510191801.j9JI1IZO079284@possum.icir.org> References: <20051019165955.GI10851@lcs.mit.edu> <200510191801.j9JI1IZO079284@possum.icir.org> Message-ID: <20051019182646.GM10851@lcs.mit.edu> On Wed, Oct 19, 2005 at 11:01:18AM -0700, Pavlin Radoslavov wrote: > > multicast group in the XORP debug: > > > > [ 1068 +430 xrl_io.cc join_multicast_group ] Join Interface eth0 Vif > > eth0 mcast 224.0.0.5 > > > > But I suspect that it is not succeeding for some reason. > > What is the output of "netstat -g"? It will show the multicast > groups joined on each interface. > If the group is joined, then I suspect there are some firewall > filters on the receiver side that prevent the multicast packets from > reaching the receiver. yep, it appears that way: [mit_rcp@planetlab4 mit_rcp]$ netstat -g IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- netstat: no support for `AF INET (igmp)' on this system. From pavlin@icir.org Wed Oct 19 19:41:31 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 19 Oct 2005 11:41:31 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Wed, 19 Oct 2005 14:26:46 EDT." <20051019182646.GM10851@lcs.mit.edu> Message-ID: <200510191841.j9JIfVC1079696@possum.icir.org> > On Wed, Oct 19, 2005 at 11:01:18AM -0700, Pavlin Radoslavov wrote: > > > multicast group in the XORP debug: > > > > > > [ 1068 +430 xrl_io.cc join_multicast_group ] Join Interface eth0 Vif > > > eth0 mcast 224.0.0.5 > > > > > > But I suspect that it is not succeeding for some reason. > > > > What is the output of "netstat -g"? It will show the multicast > > groups joined on each interface. > > If the group is joined, then I suspect there are some firewall > > filters on the receiver side that prevent the multicast packets from > > reaching the receiver. > > yep, it appears that way: > > [mit_rcp@planetlab4 mit_rcp]$ netstat -g > IPv6/IPv4 Group Memberships > Interface RefCnt Group > --------------- ------ --------------------- > netstat: no support for `AF INET (igmp)' on this system. Even if you are not running XORP, you should see that the ALL-SYSTEMS.MCAST.NET group has been joined on each interface: pavlin@koala[9] netstat -g IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 ALL-SYSTEMS.MCAST.NET eth0 1 ALL-SYSTEMS.MCAST.NET Can you check that the CONFIG_IP_MULTICAST kernel option is enabled. Pavlin From feamster@lcs.mit.edu Wed Oct 19 20:22:34 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 19 Oct 2005 15:22:34 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <200510191841.j9JIfVC1079696@possum.icir.org> References: <20051019182646.GM10851@lcs.mit.edu> <200510191841.j9JIfVC1079696@possum.icir.org> Message-ID: <20051019192234.GW10851@lcs.mit.edu> On Wed, Oct 19, 2005 at 11:41:31AM -0700, Pavlin Radoslavov wrote: > Can you check that the CONFIG_IP_MULTICAST kernel option is enabled. It doesn't appear that the box supports multicast. p2m should work. One other question: what does this error mean? [ 2005/10/17 13:21:17 ERROR xorp_ospfv2:15095 XRL +510 xrl_router.cc send ] NO FINDER From pavlin@icir.org Wed Oct 19 20:33:50 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 19 Oct 2005 12:33:50 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Wed, 19 Oct 2005 15:22:34 EDT." <20051019192234.GW10851@lcs.mit.edu> Message-ID: <200510191933.j9JJXoVh080326@possum.icir.org> > On Wed, Oct 19, 2005 at 11:41:31AM -0700, Pavlin Radoslavov wrote: > > Can you check that the CONFIG_IP_MULTICAST kernel option is enabled. > > It doesn't appear that the box supports multicast. p2m should work. "It doesn't appear" because the kernel indeed doesn't have the CONFIG_IP_MULTICAST kernel option enabled, or because there is an issue with receiving the multicast packets? If the latter, then it is better to find the real issue because it may affect other OSPF operations later and then it will be much difficult to debug the problem. > One other question: what does this error mean? > > [ 2005/10/17 13:21:17 ERROR xorp_ospfv2:15095 XRL +510 xrl_router.cc > send ] NO FINDER When does it happen, on startup/shutdown or during normal operation? In any case it means that the XORP XRL finder (that is part of the rtrmgr) is probably gone. If the rtrmgr is running, then the finder should also be running. Pavlin From feamster@lcs.mit.edu Wed Oct 19 22:18:44 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Wed, 19 Oct 2005 17:18:44 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <12689.1129594941@tigger.icir.org> References: <20051017232122.GH24605@lcs.mit.edu> <12689.1129594941@tigger.icir.org> Message-ID: <20051019211843.GR10851@lcs.mit.edu> Hi Atanu, What does this error message mean? [ 2005/10/19 17:05:51 FATAL xorp_ospfv2:10666 OSPF +914 peer.cc is_neighbour_DR_or_BDR ] Assertion (do_dr_or_bdr()) failed I see adjacencies in my ospf database, but nothing in the RIB, and I suspect this error may have something to do with it? Thanks a lot! Xorp> show ospf4 database 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.13 128.31.1.13 0x80000003 68 0x2 0x6771 48 Router 128.31.1.14 128.31.1.14 0x80000002 700 0x2 0x9341 48 Router 128.31.1.15 128.31.1.15 0x80000002 860 0x2 0x9140 48 Xorp> show route table ipv4 unicast ospf Xorp> -Nick On Mon, Oct 17, 2005 at 05:22:21PM -0700, Atanu Ghosh wrote: > Hi, > > Responses inline. > > Nick> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: > >> Hi, > >> > >> The messages of the form '[ 4251 +430 xrl_io.cc ...' are > >> debugging output from OSPF. One of the things that they show are > >> packets being sent and received by OSPF. > >> > >> OSPF uses multicast on broadcast media to distribute LSAs (with a > >> TTL of 1), so this behaviour is correct. > > Nick> OK. Thanks for the clarification. > > >> The TRACE messages are typically at the top of methods so they > >> show the state on entry to the method. It is therefore correct > >> that when a InterFaceUp event occurs that the state of the > >> interface was down. > >> > >> Could you try disabling Click and see if an adjacency is still > >> not formed. > > Nick> Yes, I think I did actually try that. I removed it from the > Nick> XORP configuration, at least. What should I configure in the > Nick> FEA instead? Do I need to configure multicast? Also, when > Nick> you say "broadcast media", what do you mean? I'd think that > Nick> would mean the broadcast address of the subnet, 128.31.1.255. > Nick> What's this 224... multicast address, and do I need to > Nick> configure something in XORP to make certain it's reachable? > > OSPF supports a number of different network types one of them is > Broadcast the definition from the RFC is below. The XORP configuration > defaults to broadcast (point-2-point and point-to-multipoint are also > supported). You shouldn't need to configure anything in order to support > the sending of the multicast packets. I have included a complete config > that I am using below. > > ---------------------------------------- RFC 2328 > Broadcast networks > Networks supporting many (more than two) attached routers, > together with the capability to address a single physical > message to all of the attached routers (broadcast). > Neighboring routers are discovered dynamically on these nets > using OSPF's Hello Protocol. The Hello Protocol itself > takes advantage of the broadcast capability. The OSPF > protocol makes further use of multicast capabilities, if > they exist. Each pair of routers on a broadcast network is > assumed to be able to communicate directly. An ethernet is > an example of a broadcast network. > ---------------------------------------- > > ---------------------------------------- > interfaces { > interface en1 { > vif en1 { > address 10.0.1.6 { > prefix-length: 16 > } > } > } > } > > protocols { > ospf4 { > router-id: 10.0.1.6 > > area 0.0.0.0 { > interface en1 { > vif en1 { > address 10.0.1.6 { > } > } > } > } > } > } > ---------------------------------------- > > >> In order for an adjacency to be formed routers have to see each > >> others hello packets. A hello packet contains a hello interval, a > >> router dead interval and a list of other routers that have been > >> seen on this interface. The hello interval and router dead > >> interval have to match for an adjacency attempt to be made. As an > >> optimisation on broadcast networks rather than forming an > >> adjacency with every other router on the subnet a designated > >> router and backup designated router are elected. The DR and BDR > >> routers form adjacencies with all the routers and the routers in > >> the other set form only two adjacencies. > >> > >> Two routers with the default configuration should try and form an > >> adjacency. You should see TRACE messages of this form: > >> > >> [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) N.(128.31.1.14) > >> State(Full) [ . TRACE .] Event(2-WayReceived) I.(fxp0/fxp0) > >> N.(128.31.1.14) State(Full) > >> > >> I have replaced some of the output with '.'s. > >> > >> If you are not seeing Event(HelloReceived) then they are not > >> seeing each others hello messages. Note the state is Full in this > >> example. > > Nick> I definitely don't see these. > > Then the routers are not seeing each others packets. > > >> After I saw you original message I went back and checked that > >> adjancencies are still being formed and they are. > >> > >> I found one thing a little puzzling the checksum for both routers > >> for different LSAs is the same, is this the actual output? > > Nick> No, I had a copy/paste error. The checksums are different. > > Good - thats what I guessed:-). > > Atanu. From atanu@ICSI.Berkeley.EDU Wed Oct 19 23:27:03 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 19 Oct 2005 15:27:03 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Wed, 19 Oct 2005 17:18:44 EDT." <20051019211843.GR10851@lcs.mit.edu> Message-ID: <44842.1129760823@tigger.icir.org> Nick> Hi Atanu, What does this error message mean? Nick> [ 2005/10/19 17:05:51 FATAL xorp_ospfv2:10666 OSPF +914 Nick> peer.cc is_neighbour_DR_or_BDR ] Assertion (do_dr_or_bdr()) Nick> failed The method is_neighbour_DR_or_BDR() has been called to determine if any of the routers neighbours are the designated router or backup designated router. This method should only be called if the the link type is Broadcast or NBMA, as these are the only link types that perform DR election. I assume that the link-type is set to point-to-multipoint (p2m), in when case the assert is signalling a programming error. The OSPF process will have exited. A stack backtrace might yield some clues. If the problem is reproducible with the latest code from CVS then the configuration files and some information about the topology would be useful. Nick> I see adjacencies in my ospf database, but nothing in the RIB, Nick> and I suspect this error may have something to do with it? Nick> Thanks a lot! If an attempt was made to add a route to the RIB and it failed you should error messages in the log. Xorp> show ospf4 database 0.0.0.0 Nick> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.13 Nick> 128.31.1.13 0x80000003 68 0x2 0x6771 48 Router 128.31.1.14 Nick> 128.31.1.14 0x80000002 700 0x2 0x9341 48 Router 128.31.1.15 Nick> 128.31.1.15 0x80000002 860 0x2 0x9140 48 Xorp> show route table ipv4 unicast ospf Xorp> Nick> -Nick Nick> On Mon, Oct 17, 2005 at 05:22:21PM -0700, Atanu Ghosh wrote: >> Hi, >> >> Responses inline. >> Nick> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: >> >> Hi, >> >> >> >> The messages of the form '[ 4251 +430 xrl_io.cc ...' are >> >> debugging output from OSPF. One of the things that they show are >> >> packets being sent and received by OSPF. >> >> >> >> OSPF uses multicast on broadcast media to distribute LSAs >> (with a >> TTL of 1), so this behaviour is correct. >> Nick> OK. Thanks for the clarification. >> >> The TRACE messages are typically at the top of methods so >> they >> show the state on entry to the method. It is therefore >> correct >> that when a InterFaceUp event occurs that the state of >> the >> interface was down. >> >> >> >> Could you try disabling Click and see if an adjacency is still >> >> not formed. >> Nick> Yes, I think I did actually try that. I removed it from the Nick> XORP configuration, at least. What should I configure in the Nick> FEA instead? Do I need to configure multicast? Also, when Nick> you say "broadcast media", what do you mean? I'd think that Nick> would mean the broadcast address of the subnet, 128.31.1.255. Nick> What's this 224... multicast address, and do I need to Nick> configure something in XORP to make certain it's reachable? >> OSPF supports a number of different network types one of them is >> Broadcast the definition from the RFC is below. The XORP >> configuration defaults to broadcast (point-2-point and >> point-to-multipoint are also supported). You shouldn't need to >> configure anything in order to support the sending of the >> multicast packets. I have included a complete config that I am >> using below. >> >> ---------------------------------------- RFC 2328 Broadcast >> networks Networks supporting many (more than two) attached >> routers, together with the capability to address a single >> physical message to all of the attached routers (broadcast). >> Neighboring routers are discovered dynamically on these nets >> using OSPF's Hello Protocol. The Hello Protocol itself takes >> advantage of the broadcast capability. The OSPF protocol makes >> further use of multicast capabilities, if they exist. Each pair >> of routers on a broadcast network is assumed to be able to >> communicate directly. An ethernet is an example of a broadcast >> network. >> ---------------------------------------- >> >> ---------------------------------------- >> interfaces { interface en1 { vif en1 { address 10.0.1.6 { >> prefix-length: 16 } } } } >> >> protocols { ospf4 { router-id: 10.0.1.6 >> >> area 0.0.0.0 { interface en1 { vif en1 { address 10.0.1.6 { } } } >> } } } >> ---------------------------------------- >> >> >> In order for an adjacency to be formed routers have to see >> each >> others hello packets. A hello packet contains a hello >> interval, a >> router dead interval and a list of other routers >> that have been >> seen on this interface. The hello interval and >> router dead >> interval have to match for an adjacency attempt to >> be made. As an >> optimisation on broadcast networks rather than >> forming an >> adjacency with every other router on the subnet a >> designated >> router and backup designated router are elected. >> The DR and BDR >> routers form adjacencies with all the routers >> and the routers in >> the other set form only two adjacencies. >> >> >> >> Two routers with the default configuration should try and form >> an >> adjacency. You should see TRACE messages of this form: >> >> >> >> [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) >> N.(128.31.1.14) >> State(Full) [ . TRACE .] Event(2-WayReceived) >> I.(fxp0/fxp0) >> N.(128.31.1.14) State(Full) >> >> >> >> I have replaced some of the output with '.'s. >> >> >> >> If you are not seeing Event(HelloReceived) then they are not >> >> seeing each others hello messages. Note the state is Full in >> this >> example. >> Nick> I definitely don't see these. >> Then the routers are not seeing each others packets. >> >> >> After I saw you original message I went back and checked that >> >> adjancencies are still being formed and they are. >> >> >> >> I found one thing a little puzzling the checksum for both >> routers >> for different LSAs is the same, is this the actual >> output? >> Nick> No, I had a copy/paste error. The checksums are different. >> Good - thats what I guessed:-). >> >> Atanu. From feamster@lcs.mit.edu Thu Oct 20 17:45:09 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Thu, 20 Oct 2005 12:45:09 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <44842.1129760823@tigger.icir.org> References: <20051019211843.GR10851@lcs.mit.edu> <44842.1129760823@tigger.icir.org> Message-ID: <20051020164509.GA16606@lcs.mit.edu> --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote: > of the routers neighbours are the designated router or backup designated > router. This method should only be called if the the link type is > Broadcast or NBMA, as these are the only link types that perform DR > election. I assume that the link-type is set to point-to-multipoint > (p2m), in when case the assert is signalling a programming error. The > OSPF process will have exited. A stack backtrace might yield some clues. Yes, the link-type is p2m in our case, so perhaps this method should not be called? It appears that the OSPF process dies completely as a result. Sure, I will send along a backtrace. > If the problem is reproducible with the latest code from CVS then the > configuration files and some information about the topology would be useful. Simple topology: A <-> B <-> C, where both links are p2m links. I've attached the configuration files. > If an attempt was made to add a route to the RIB and it failed you > should error messages in the log. How do I ensure that routes are in the RIB, then? Here's what I see in the log. [ 2005/10/20 12:38:38 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Down) [ 2005/10/20 12:38:38 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Init) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Init) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Init) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(eth0/eth0) Neighbour(128.31.1.14) State(ExStart) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) Interface(eth0/eth0) Neighbour(128.31.1.14) State(ExStart) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Exchange) [ 2005/10/20 12:38:41 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Exchange) [ 2005/10/20 12:38:46 TRACE xorp_ospfv2 OSPF ] Event(LinkStateRequestReceived-pseudo-event) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Loading) [ 2005/10/20 12:38:46 ERROR xorp_ospfv2:13595 OSPF +1003 xrl_io.cc route_command_done ] callback: delete_route: ribname rib net 128.31.1.14/32 102 Command failed Could not delete IPv4 route from unicast RIB [ 2005/10/20 12:39:18 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) Interface(eth0/eth0) Neighbour(128.31.1.14) State(Loading) > > Xorp> show ospf4 database 0.0.0.0 > Nick> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.13 > Nick> 128.31.1.13 0x80000003 68 0x2 0x6771 48 Router 128.31.1.14 > Nick> 128.31.1.14 0x80000002 700 0x2 0x9341 48 Router 128.31.1.15 > Nick> 128.31.1.15 0x80000002 860 0x2 0x9140 48 > Xorp> show route table ipv4 unicast ospf > Xorp> > > Nick> -Nick > > Nick> On Mon, Oct 17, 2005 at 05:22:21PM -0700, Atanu Ghosh wrote: > >> Hi, > >> > >> Responses inline. > >> > Nick> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote: > >> >> Hi, > >> >> > >> >> The messages of the form '[ 4251 +430 xrl_io.cc ...' are >> > >> debugging output from OSPF. One of the things that they show are > >> >> packets being sent and received by OSPF. > >> >> > >> >> OSPF uses multicast on broadcast media to distribute LSAs > >> (with a >> TTL of 1), so this behaviour is correct. > >> > Nick> OK. Thanks for the clarification. > >> >> The TRACE messages are typically at the top of methods so > >> they >> show the state on entry to the method. It is therefore > >> correct >> that when a InterFaceUp event occurs that the state of > >> the >> interface was down. > >> >> > >> >> Could you try disabling Click and see if an adjacency is still > >> >> not formed. > >> > Nick> Yes, I think I did actually try that. I removed it from the > Nick> XORP configuration, at least. What should I configure in the > Nick> FEA instead? Do I need to configure multicast? Also, when > Nick> you say "broadcast media", what do you mean? I'd think that > Nick> would mean the broadcast address of the subnet, 128.31.1.255. > Nick> What's this 224... multicast address, and do I need to > Nick> configure something in XORP to make certain it's reachable? > >> OSPF supports a number of different network types one of them is > >> Broadcast the definition from the RFC is below. The XORP > >> configuration defaults to broadcast (point-2-point and > >> point-to-multipoint are also supported). You shouldn't need to > >> configure anything in order to support the sending of the > >> multicast packets. I have included a complete config that I am > >> using below. > >> > >> ---------------------------------------- RFC 2328 Broadcast > >> networks Networks supporting many (more than two) attached > >> routers, together with the capability to address a single > >> physical message to all of the attached routers (broadcast). > >> Neighboring routers are discovered dynamically on these nets > >> using OSPF's Hello Protocol. The Hello Protocol itself takes > >> advantage of the broadcast capability. The OSPF protocol makes > >> further use of multicast capabilities, if they exist. Each pair > >> of routers on a broadcast network is assumed to be able to > >> communicate directly. An ethernet is an example of a broadcast > >> network. > >> ---------------------------------------- > >> > >> ---------------------------------------- > >> interfaces { interface en1 { vif en1 { address 10.0.1.6 { > >> prefix-length: 16 } } } } > >> > >> protocols { ospf4 { router-id: 10.0.1.6 > >> > >> area 0.0.0.0 { interface en1 { vif en1 { address 10.0.1.6 { } } } > >> } } } > >> ---------------------------------------- > >> > >> >> In order for an adjacency to be formed routers have to see > >> each >> others hello packets. A hello packet contains a hello > >> interval, a >> router dead interval and a list of other routers > >> that have been >> seen on this interface. The hello interval and > >> router dead >> interval have to match for an adjacency attempt to > >> be made. As an >> optimisation on broadcast networks rather than > >> forming an >> adjacency with every other router on the subnet a > >> designated >> router and backup designated router are elected. > >> The DR and BDR >> routers form adjacencies with all the routers > >> and the routers in >> the other set form only two adjacencies. > >> >> > >> >> Two routers with the default configuration should try and form > >> an >> adjacency. You should see TRACE messages of this form: > >> >> > >> >> [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0) > >> N.(128.31.1.14) >> State(Full) [ . TRACE .] Event(2-WayReceived) > >> I.(fxp0/fxp0) >> N.(128.31.1.14) State(Full) > >> >> > >> >> I have replaced some of the output with '.'s. > >> >> > >> >> If you are not seeing Event(HelloReceived) then they are not > >> >> seeing each others hello messages. Note the state is Full in > >> this >> example. > >> > Nick> I definitely don't see these. > >> Then the routers are not seeing each others packets. > >> > >> >> After I saw you original message I went back and checked that > >> >> adjancencies are still being formed and they are. > >> >> > >> >> I found one thing a little puzzling the checksum for both > >> routers >> for different LSAs is the same, is this the actual > >> output? > >> > Nick> No, I had a copy/paste error. The checksums are different. > >> Good - thats what I guessed:-). > >> > >> Atanu. --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="planetlab3.csail.mit.edu.xorp" /* XORP configuration automatically generated by build_configs.pl */ interfaces { interface lo { description: "loopback interface" disable: false discard: true mac: 00:00:00:00:00:00 mtu: 1500 vif lo { disable: false address 127.0.0.1 { prefix-length: 32 disable: false } } } interface eth0 { description "ethernet adapter" disable: false discard: true vif eth0 { disable: false address 128.31.1.13 { prefix-length: 32 disable: false } } } } fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "/home/mit_rcp/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/home/mit_rcp/demo/planetlab3.csail.mit.edu.click" user-click-config-generator-file: "/home/mit_rcp/demo/static_config" } } } protocols { static { route4 10.0.2.0/24 { /* This node's OpenVPN clients */ next-hop: 127.255.255.255 metric: 1 } /* planetlab5.csail.mit.edu -> planetlab4.csail.mit.edu */ route4 128.31.1.15/32 { next-hop: 127.0.3.1 metric: 1 } route4 10.0.1.0/24 { next-hop: 127.0.3.1 metric: 1 } route4 10.0.3.0/24 { next-hop: 127.0.3.1 metric: 1 } } ospf4 { router-id: 128.31.1.13 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 { router-id: 128.31.1.14 } } } } } } } --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="planetlab4.csail.mit.edu.xorp" /* XORP configuration automatically generated by build_configs.pl */ interfaces { interface lo { description: "loopback interface" disable: false discard: true mac: 00:00:00:00:00:00 mtu: 1500 vif lo { disable: false address 127.0.0.1 { prefix-length: 32 disable: false } } } interface eth0 { description "ethernet adapter" disable: false discard: true vif eth0 { disable: false address 128.31.1.14 { prefix-length: 24 disable: false } } } } fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "/home/mit_rcp/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13000 startup-config-file: "/home/mit_rcp/demo/planetlab4.csail.mit.edu.click" user-click-config-generator-file: "/home/mit_rcp/demo/static_config" } } } protocols { static { route4 10.0.3.0/24 { /* This node's OpenVPN clients */ next-hop: 127.255.255.255 metric: 1 } /* planetlab5.csail.mit.edu -> planetlab5.csail.mit.edu */ route4 128.31.1.15/32 { next-hop: 127.0.1.1 metric: 1 } route4 10.0.1.0/24 { next-hop: 127.0.1.1 metric: 1 } /* planetlab3.csail.mit.edu -> planetlab3.csail.mit.edu */ route4 128.31.1.13/32 { next-hop: 127.0.2.1 metric: 1 } route4 10.0.2.0/24 { next-hop: 127.0.2.1 metric: 1 } } ospf4 { router-id: 128.31.1.14 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 { router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id: 128.31.1.15 } } } } } } } --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="planetlab5.csail.mit.edu.xorp" /* XORP configuration automatically generated by build_configs.pl */ interfaces { interface lo { description: "loopback interface" disable: false discard: true mac: 00:00:00:00:00:00 mtu: 1500 vif lo { disable: false address 127.0.0.1 { prefix-length: 32 disable: false } } } interface eth0 { description "ethernet adapter" disable: false discard: true vif eth0 { disable: false address 128.31.1.15 { prefix-length: 24 disable: false } } } } fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "/home/mit_rcp/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13654 startup-config-file: "/home/mit_rcp/demo/planetlab5.csail.mit.edu.click" user-click-config-generator-file: "/home/mit_rcp/demo/static_config" } } } protocols { static { route4 10.0.1.0/24 { /* This node's OpenVPN clients */ next-hop: 127.255.255.255 metric: 1 } /* planetlab3.csail.mit.edu -> planetlab4.csail.mit.edu */ route4 128.31.1.13/32 { next-hop: 127.0.3.1 metric: 1 } route4 10.0.2.0/24 { next-hop: 127.0.3.1 metric: 1 } /* planetlab4.csail.mit.edu -> planetlab4.csail.mit.edu */ route4 128.31.1.14/32 { next-hop: 127.0.3.1 metric: 1 } route4 10.0.3.0/24 { next-hop: 127.0.3.1 metric: 1 } } ospf4 { router-id: 128.31.1.15 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.14 { router-id: 128.31.1.14 } } } } } } } --7JfCtLOvnd9MIVvH-- From riccardo.sciaccaluga@tin.it" i did a configuration file matching a static route with an interface following some suggestion on the sintax i had to use. My problem is that with this file i am able to specify the interface to use to forward packets through but i don't know the right sintaz to specify also the next-hop address! Could somebody help me? protocols { static { interface-route4 192.168.10.0/24 { next-hop-interface: "eth9" next-hop-vif: "eth9" metric:7 } } I have also a second question! I am trying to configure a 4 interfaces network adapter. One of this interface is configured with a static route by xorp. Because all these interfaces are located on the same pc,do i need to export the static route in the rip declaration to make its information available to the rip protocol? From atanu@ICSI.Berkeley.EDU Fri Oct 21 10:53:59 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 21 Oct 2005 02:53:59 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Thu, 20 Oct 2005 12:45:09 EDT." <20051020164509.GA16606@lcs.mit.edu> Message-ID: <73252.1129888439@tigger.icir.org> --=-=-= >>>>> "Nick" == Nick Feamster writes: Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote: >> of the routers neighbours are the designated router or backup >> designated router. This method should only be called if the the >> link type is Broadcast or NBMA, as these are the only link types >> that perform DR election. I assume that the link-type is set to >> point-to-multipoint (p2m), in when case the assert is signalling >> a programming error. The OSPF process will have exited. A stack >> backtrace might yield some clues. Nick> Yes, the link-type is p2m in our case, so perhaps this method Nick> should not be called? It appears that the OSPF process dies Nick> completely as a result. Sure, I will send along a backtrace. This problem is now fixed in CVS. >> If the problem is reproducible with the latest code from CVS then >> the configuration files and some information about the topology >> would be useful. Nick> Simple topology: Nick> A <-> B <-> C, where both links are p2m links. I've attached Nick> the configuration files. I'v included a cut down configuration files that worked for me. I had to modify the prefix length from 32 to 24 on the first router. Also you shouldn't be setting discard to true on interfaces that you want to route traffic through. >> If an attempt was made to add a route to the RIB and it failed >> you should error messages in the log. Nick> How do I ensure that routes are in the RIB, then? Here's what Nick> I see in the log. Use the show route command: Xorp> show route table ipv4 unicast ospf Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 To see the final table: Xorp> show route table ipv4 unicast final Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 Atanu. --=-=-= Content-Disposition: attachment; filename=p3 Content-Description: p3 interfaces { interface eth0 { vif eth0 { address 128.31.1.13 { prefix-length: 24 } } } } protocols { ospf4 { router-id: 128.31.1.13 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 { router-id: 128.31.1.14 } } } } } } } } --=-=-= Content-Disposition: attachment; filename=p4 Content-Description: p4 interfaces { interface eth0 { vif eth0 { address 128.31.1.14 { prefix-length: 24 } } } } protocols { ospf4 { router-id: 128.31.1.14 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 { router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id: 128.31.1.15 } } } } } } } } --=-=-= Content-Disposition: attachment; filename=p5 Content-Description: p5 interfaces { interface eth0 { vif eth0 { address 128.31.1.15 { prefix-length: 24 } } } } protocols { ospf4 { router-id: 128.31.1.15 area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 { router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id: 128.31.1.14 } } } } } } } } --=-=-=-- From pavlin@icir.org Fri Oct 21 17:33:21 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 21 Oct 2005 09:33:21 -0700 Subject: [Xorp-users] Some help with xorp sintax! In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Fri, 21 Oct 2005 08:48:24 BST." <7196516.1129880904729.JavaMail.root@pswm10.cp.tin.it> Message-ID: <200510211633.j9LGXLmb050064@possum.icir.org> > i did a configuration file matching a static route with an interface > following some suggestion on the sintax i had to use. > My problem is > that with this file i am able to specify the interface to use to > forward packets through but i don't know the right sintaz to specify > also the next-hop address! > Could somebody help me? > protocols { > > static { > interface-route4 192.168.10.0/24 { > > next-hop-interface: "eth9" > next-hop-vif: "eth9" > metric:7 > } > } No, currently the rtrmgr template for interface-routes doesn't allow you to provide the next-hop router address as well. To add the syntax for specifying the next-hop router address as well all you need to do is to modify file etc/templates/static_routes.tp. At the end of this email there is a patch that adds this syntax for "interface-route4" (adding same syntax for interface-route6 and for mrib-interface-route{4,6} would require similar modifications). With the new syntax, you can use "next-hop-router" to specify the next-hop-router address for interface-route4 entries. Please let me know If it works for yor and I will apply the patch to CVS. > I have also a second question! > I am trying to > configure a 4 interfaces network adapter. > One of this interface is > configured with a static route by xorp. > Because all these interfaces > are located on the same pc,do i need to export the static route in the > rip declaration to make its information available to the rip protocol? The answer depends on what you want to do with this static route. If you want to tell the other RIP routers about it, then yes you have to export it. Pavlin ---------- Index: static_routes.tp =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/static_routes.tp,v retrieving revision 1.25 diff -u -p -r1.25 static_routes.tp --- static_routes.tp 6 Oct 2005 00:33:56 -0000 1.25 +++ static_routes.tp 21 Oct 2005 16:22:40 -0000 @@ -15,6 +15,7 @@ protocols { interface-route4 @: ipv4net { next-hop-interface: txt = ""; next-hop-vif: txt = ""; + next-hop-router: ipv4 = 0.0.0.0; metric: u32 = 1; } @@ -133,8 +134,8 @@ protocols { %help: short "Configure an interface-based IPv4 static route"; %mandatory: $(@.next-hop-interface), $(@.next-hop-vif); - %activate: xrl "$(static.targetname)/static_routes/0.1/add_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=0.0.0.0&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif)&metric:u32=$(@.metric)"; - %update: xrl "$(static.targetname)/static_routes/0.1/replace_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=0.0.0.0&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif)&metric:u32=$(@.metric)"; + %activate: xrl "$(static.targetname)/static_routes/0.1/add_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=$(@.next-hop-router)&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif)&metric:u32=$(@.metric)"; + %update: xrl "$(static.targetname)/static_routes/0.1/replace_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=$(@.next-hop-router)&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif)&metric:u32=$(@.metric)"; %delete: xrl "$(static.targetname)/static_routes/0.1/delete_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)"; next-hop-interface { @@ -147,6 +148,11 @@ protocols { %set:; } + next-hop-router { + %help: short "Configure the next-hop router"; + %set:; + } + metric { %help: short "Configure the routing metric"; %allow-range: $(@) "1" "65535"; ---------- From ninanooo@dsys.korea.ac.kr Sun Oct 23 09:08:41 2005 From: ninanooo@dsys.korea.ac.kr (ninanooo) Date: Sun, 23 Oct 2005 17:08:41 +0900 Subject: [Xorp-users] Question about SSM support of PIM-SM Message-ID: <001401c5d7a8$fad4ba10$4c1598a3@nethogu> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C5D7F4.6AB07B30 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJIGtub3cgdGhhdCB0aGUgU1NNIHN1cHBvcnQgaXMgbm90IHlldCBzdGFydGVk IGluIHRoZSBSZWxlYXNlIDEuMS4gDQpCdXQgSSB3b25kZXIgaWYgdGhpcyBtZWFucyBpdCBjYW5u b3Qgc3VwcG9ydCBzd2l0Y2hpbmcgdG8gU1BULg0KSWYgaXQgY2FuIHN1cHBvcnQgU1BUIHN3aXRj aGluZywgaG93IGNhbiBJIHRlc3QgaXQ/DQoNClBsZWFzZSBoZWxwIG1lLiBUaGFueA== ------=_NextPart_000_0011_01C5D7F4.6AB07B30 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBzaXplPTI+DQo8RElWPkhpLCBhbGw8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkga25vdyB0aGF0Jm5ic3A7dGhlIFNTTSBz dXBwb3J0IGlzIG5vdCB5ZXQgc3RhcnRlZCBpbiB0aGUgUmVsZWFzZSAxLjEuIA0KPC9ESVY+DQo8 RElWPkJ1dCBJIHdvbmRlciZuYnNwO2lmIHRoaXMgbWVhbnMgaXQgY2Fubm90IHN1cHBvcnQgc3dp dGNoaW5nIHRvIFNQVC48L0RJVj4NCjxESVY+SWYgaXQgY2FuIHN1cHBvcnQgU1BUIHN3aXRjaGlu ZywgaG93IGNhbiBJIHRlc3QgaXQ/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QbGVh c2UgaGVscCBtZS4gVGhhbng8L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0011_01C5D7F4.6AB07B30-- From pavlin@icir.org Sun Oct 23 16:49:00 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 23 Oct 2005 08:49:00 -0700 Subject: [Xorp-users] Question about SSM support of PIM-SM In-Reply-To: Message from "ninanooo" of "Sun, 23 Oct 2005 17:08:41 +0900." <001401c5d7a8$fad4ba10$4c1598a3@nethogu> Message-ID: <200510231549.j9NFn0jG058781@possum.icir.org> > I know that the SSM support is not yet started in the Release 1.1. > But I wonder if this means it cannot support switching to SPT. > If it can support SPT switching, how can I test it? The PIM-SM SPT switch is part of the base protocol specification and is implemented in XORP. One way to test it is to configure the "switch-to-spt-threshold" in your last-hop router to initiate the SPT switch after the first data packet is forwarded. See the "PIM Sparse-Mode" chapter in the XORP User Manual for more information about this configuration statement. Pavlin From ninanooo@dsys.korea.ac.kr Mon Oct 24 13:26:41 2005 From: ninanooo@dsys.korea.ac.kr (ninanooo) Date: Mon, 24 Oct 2005 21:26:41 +0900 Subject: [Xorp-users] How to send the PIM-SM control message? Message-ID: <001301c5d896$30ad3980$4c1598a3@nethogu> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C5D8E1.A043B440 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJJ20gdXNpbmcgWE9SUCAxLjEgcmVsZWFzZXMgb24gdGhlIFJlZGhhdCBsaW51 eA0KTm93LCBJIGFtIHRyeWluZyB0byB0ZXN0IFBJTS1TTSBvcGVyYXRpb24NCkJ1dCBJIGNhbiBu b3Qgc2VuZCBQSU0tU00gY29udHJvIG1lc3NhZ2VzIChKb2luL1BydW5lLCBSZWdpc3RlciwgUmVn aXN0ZXItc3RvcCwgZXRjKQ0KDQpJbiBYT1JQIFBJTS1TTSBUZXN0IFN1aXRlLCBpdCB0ZWxscyB0 aGF0IA0KIlRoZSB0ZXN0IHNvZnR3YXJlIHVzZWQgaW4gdGhpcyB0ZXN0IHN1aXRlIGlzIHRoZSBY T1JQIFBJTS1TTSBpbXBsZW1lbnRhdGlvbiBpdHNlbGYuIE1vcmUgc3BlY2lmaWNhbGx5LA0KdGhl IFhPUlAgUElNLVNNIGltcGxlbWVudGF0aW9uIGhhcyBleHRlbnNpb25zIHRoYXQgY2FuIGJlIHVz ZWQgdG8gZ2VuZXJhdGUgdmFyaW91cyBQSU0tU00NCnByb3RvY29sIGNvbnRyb2wgcGFja2V0cyBm b3IgdGVzdGluZyBwdXJwb3NlIg0KDQpCdXQgaXQgZG9lc24ndCB0ZWxsIGhvdyB0byBnZW5lcmF0 ZSB2YXJpb3VzIFBJTS1TTSBjb250cm9sIHBhY2tldHMuDQoNClBsZWFzZSBoZWxwIG1lLiBUaGFu eH4= ------=_NextPart_000_0010_01C5D8E1.A043B440 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBhbGw8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5JJ20gdXNpbmcgWE9SUCAxLjEgcmVsZWFzZXMgb24gdGhlIFJlZGhhdCBs aW51eDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk5vdywgSSBhbSB0cnlpbmcgdG8g dGVzdCBQSU0tU00gb3BlcmF0aW9uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QnV0 IEkgY2FuIG5vdCBzZW5kIFBJTS1TTSBjb250cm8gbWVzc2FnZXMgKEpvaW4vUHJ1bmUsIA0KUmVn aXN0ZXIsIFJlZ2lzdGVyLXN0b3AsIGV0Yyk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JbiBYT1JQIFBJTS1TTSBU ZXN0IFN1aXRlLCBpdCB0ZWxscyB0aGF0IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PiJUaGUgdGVzdCBzb2Z0d2FyZSB1c2VkIGluIHRoaXMgdGVzdCBzdWl0ZSBpcyZuYnNwO3RoZSBY T1JQIA0KUElNLVNNIGltcGxlbWVudGF0aW9uIGl0c2VsZi4gTW9yZSBzcGVjaWZpY2FsbHksPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGhlIFhPUlAgUElNLVNNIGltcGxlbWVudGF0 aW9uIGhhcyBleHRlbnNpb25zIHRoYXQgY2FuIGJlIHVzZWQgDQp0byBnZW5lcmF0ZSB2YXJpb3Vz IFBJTS1TTTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnByb3RvY29sIGNvbnRyb2wg cGFja2V0cyBmb3IgdGVzdGluZyBwdXJwb3NlIjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJ1dCBpdCBkb2Vzbid0 IHRlbGwgaG93IHRvIGdlbmVyYXRlIHZhcmlvdXMgUElNLVNNIGNvbnRyb2wgDQpwYWNrZXRzLjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPlBsZWFzZSBoZWxwIG1lLiBUaGFueH48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------=_NextPart_000_0010_01C5D8E1.A043B440-- From pavlin@icir.org Tue Oct 25 06:28:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 24 Oct 2005 22:28:24 -0700 Subject: [Xorp-users] How to send the PIM-SM control message? In-Reply-To: Message from "ninanooo" of "Mon, 24 Oct 2005 21:26:41 +0900." <001301c5d896$30ad3980$4c1598a3@nethogu> Message-ID: <200510250528.j9P5SO9u024599@possum.icir.org> > I'm using XORP 1.1 releases on the Redhat linux > Now, I am trying to test PIM-SM operation > But I can not send PIM-SM contro messages (Join/Prune, Register, Register-stop, etc) > > In XORP PIM-SM Test Suite, it tells that > "The test software used in this test suite is the XORP PIM-SM implementation itself. More specifically, > the XORP PIM-SM implementation has extensions that can be used to generate various PIM-SM > protocol control packets for testing purpose" > > But it doesn't tell how to generate various PIM-SM control packets. You can use the send_test_* XRL interface (see xrl/interfaces/pim.xif). The model for sending the Join/Prune messages is that you call a number of add_test_jp_entry{4,6} to add each entry, and then you send the composed message by send_test_jp_entry{4,6}. The model for sending the Bootstrap and Cand-RP-Adv messages is similar: you use add_test_bsr_zone{4,6}, add_test_bsr_group_prefix{4,6}, add_test_bsr_rp{4,6} to compose the message, and then it is transmitted by one of the send_test_bootstrap* or send_test_cand_rp_adv XRLs. The Assert messages don't need to be composed in advance and are transmitted directly by send_test_assert{4,6}. Unfortunately, there is no XRL to explicitly trigger sending of a Hello message. In my tests I found it more useful to use XORP as-is to transmit periodically the PIM Hello messages. I think this is an omission and for completeness there should be an XRL to transmit a Hello message with various options enabled/disabled. If having the Hello message support is important for you, please add a bugzilla entry about it. Pavlin From riccardo.sciaccaluga@tin.it" Here you have the answers to the following operational xorp commands: show route table ipv4 unicast static show route table ipv4 unicast rip show route table ipv4 unicast final Xorp> show route table ipv4 unicast static Network 192.168.10.0/24 Nexthop := 192.168.15.1 Metric := 7 Protocol := static Interface := eth6 Vif := eth6 Xorp> show route table ipv4 unicast rip Network 192.168.6.0/24 Nexthop := 192.168.6.1 Metric := 0 Protocol := rip Interface := eth6 Vif := eth6 Network 192.168.8.0/24 Nexthop := 192.168.8.1 Metric := 0 Protocol := rip Interface := eth8 Vif := eth8 Network 192.168.9.0/24 Nexthop := 192.168.9.1 Metric := 0 Protocol := rip Interface := eth9 Vif := eth9 Xorp> show route table ipv4 unicast final Network 192.168.6.0/24 Nexthop := 192.168.6.1 Metric := 0 Protocol := connected Interface := eth6 Vif := eth6 Network 192.168.8.0/24 Nexthop := 192.168.8.1 Metric := 0 Protocol := connected Interface := eth8 Vif := eth8 Network 192.168.9.0/24 Nexthop := 192.168.9.1 Metric := 0 Protocol := connected Interface := eth9 Vif := eth9 Network 192.168.10.0/24 Nexthop := 192.168.15.1 Metric := 7 Protocol := static Interface := eth6 Vif := eth6 >From those outputs i can see that there is the static route i set up but i can't see it with the linux bash command "route" ----Messaggio originale---- Da: pavlin@icir. org Data: 25-ott-2005 7.40 AM A: "riccardo.sciaccaluga@tin.it" Cc: Ogg: Re: R: Re: [Xorp-users] Some help with xorp sintax! > ------=_Part_78549_28762835. 1130169891174 > Content-Type: text/plain; charset=UTF-8 > Content- Transfer-Encoding: 7bit > > Ok the patch you gave me it adds the information of the next-hop-router > address to my xorp routing table, so it works. > Unfortunately i have > another problem, my conifg.boot doesen't add the static route i > configured on it to the routing table of my system kernel and i don't > know why! > For example if i set a very simple xorp configuration with > just set up a static route on my config.boot file, i can check it > succesfully on my system kernel route table. > On the other hand if i add > some other routing protocol matched with some other interface i can't > see anymore my static route on the system kernel entries! What is the output of the following operational commands when you are running both static and RIP: show route table ipv4 unicast static show route table ipv4 unicast rip show route table ipv4 unicast final > I attach my > config.boot file! > Sorry for my so often question but i'm a student > and i am working on my thesys with the need of beeing able to manage > the routing table of the router with xorp! > Thanks in advance > > P. s:how > could do(i mena the sintax) if i would export the static route on my > file Somebody else should answer the above question so if you don't receive an answer then please resend the same question in a new thread :) Pavlin > ------=_Part_78549_28762835.1130169891174 > Content-Type: APPLICATION/OCTET-STREAM; name=config.boot > Content- Transfer-Encoding: 7bit > Content-Disposition: attachment; filename=config.boot; size=1717 > > interfaces { > interface eth6 { > description:"data interface" > disable:false > vif eth6 { > disable:false > address 192.168.6.1 { > prefix-length: 24 > broadcast: 192.168.6.255 > disable:false > } > } > } > interface eth8 { > description:"data interface" > disable:false > vif eth8 { > disable:false > address 192.168.8.1 { > prefix-length: 24 > broadcast: 192.168.8.255 > disable:false > } > } > } > interface eth9 { > description:"data interface" > disable:false > vif eth9 { > disable:false > address 192.168.9.1 { > prefix-length: 24 > broadcast: 192.168.9.255 > disable:false > } > } > } > > > } > fea { > unicast-forwarding4 { > disable:false > } > } > > protocols { > static { > interface-route4 192.168.10.0/24 { > next-hop-interface: "eth6" > next-hop-vif: "eth6" > next-hop-router: 192.168.15.1 > metric:7 > > } > } > } > protocols { > rip { > export connected { > metric: 0 > tag: 0 > } > interface eth8 { > vif eth8 { > address 192.168.8.1 { > disable: false > } > } > } > interface eth9 { > vif eth9 { > address 192.168.9.1 { > disable: false > } > } > } > } > } > > ------=_Part_78549_28762835.1130169891174-- > From pavlin@icir.org Tue Oct 25 17:05:25 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 25 Oct 2005 09:05:25 -0700 Subject: [Xorp-users] Some xorp sintax help! In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Tue, 25 Oct 2005 10:34:14 BST." <32106198.1130232854168.JavaMail.root@pswm1> Message-ID: <200510251605.j9PG5PPX065722@possum.icir.org> > Here you have the answers to the following operational xorp commands: > show route table ipv4 unicast static > show route table ipv4 unicast rip > show route table ipv4 unicast final > > Xorp> show route table ipv4 > unicast static > Network 192.168.10.0/24 > Nexthop := 192.168.15.1 > > Metric := 7 Protocol := static Interface := eth6 Vif := > eth6 > Xorp> show route table ipv4 unicast rip > Network 192.168.6.0/24 > > Nexthop := 192.168.6.1 > Metric := 0 Protocol := rip > Interface := eth6 Vif := eth6 > Network 192.168.8.0/24 > Nexthop := > 192.168.8.1 > Metric := 0 Protocol := rip Interface := > eth8 Vif := eth8 > Network 192.168.9.0/24 > Nexthop := 192.168.9.1 > Metric := 0 Protocol := rip Interface := eth9 Vif := > eth9 > Xorp> show route table ipv4 unicast final > Network 192.168.6.0/24 > Nexthop := 192.168.6.1 > Metric := 0 Protocol := > connected Interface := eth6 Vif := eth6 > Network 192.168.8.0/24 > Nexthop := 192.168.8.1 > Metric := 0 Protocol := > connected Interface := eth8 Vif := eth8 > Network 192.168.9.0/24 > Nexthop := 192.168.9.1 > Metric := 0 Protocol := > connected Interface := eth9 Vif := eth9 > Network 192.168.10.0/24 > Nexthop := 192.168.15.1 > Metric := 7 Protocol := > static Interface := eth6 Vif := eth6 > > >From those outputs i can > see that there is the static route i set up but i can't see it with the > linux bash command "route" The above routes seem fine, and the static route is in the RIB's final table. What is the output of "/sbin/ip route"? Also, were there any route-related warning/error messages? Previously you said that you see the static route in the kernel only if you are not running RIP. Can you double-check this: 1. Verify with "/sbin/ip route" that the 192.168.10.0/24 route is not in the kernel. 2. Start XORP with "static" only (i.e., no RIP) and verify that the above route is in the kernel. 3. Stop XORP and verify that the route is gone. Finally, can you set the "XRLTRACE" environmental variable and run XORP with both "static" and RIP configured. This will produce lots of output with all XRLs transmitted. Save this output and look for the "redist_transaction4/0.1/add_route" XRLs which are sent from RIB to the FEA. You should see such XRLs for all routes that are in the "final" RIB table (see the output of "show route table ipv4 unicast final"). Pavlin From ninanooo@dsys.korea.ac.kr Wed Oct 26 10:44:26 2005 From: ninanooo@dsys.korea.ac.kr (ninanooo) Date: Wed, 26 Oct 2005 18:44:26 +0900 Subject: [Xorp-users] Does XORP support IPv6 multicast routing on the Linux? Message-ID: <000901c5da11$ddd09220$4c1598a3@nethogu> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C5DA5D.4A43ACD0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJIGhhdmUgaGVhcmQgdGhhdCANCiJJbiBjYXNlIG9mIExpbnV4LCBYT1JQIG9u bHkgd29ya3MgaW4gSVB2NCBiZWNhdXNlIHRoZSBrZXJuZWwgaXRzZWxmIGRvZXNuJ3Qgc3VwcG9y dCBJUHY2IG11bHRpY2FzdCByb3V0aW5nIg0KDQpJcyB0aGlzIHJpZ2h0PyBQbGVhc2UgaGVscCBt ZSA6KQ== ------=_NextPart_000_0006_01C5DA5D.4A43ACD0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLCBhbGw8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5JIGhhdmUgaGVhcmQgdGhhdCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4iSW4gY2FzZSBvZiBMaW51eCwgWE9SUCBvbmx5IHdvcmtzIGluIElQdjQgYmVjYXVz ZSB0aGUga2VybmVsIA0KaXRzZWxmIGRvZXNuJ3Qgc3VwcG9ydCBJUHY2IDwvRk9OVD48Rk9OVCBz aXplPTI+bXVsdGljYXN0IHJvdXRpbmciPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhpcyByaWdodD8gUGxl YXNlIGhlbHAgbWUgOik8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C5DA5D.4A43ACD0-- From pavlin@icir.org Wed Oct 26 17:55:17 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Oct 2005 09:55:17 -0700 Subject: [Xorp-users] Does XORP support IPv6 multicast routing on the Linux? In-Reply-To: Message from "ninanooo" of "Wed, 26 Oct 2005 18:44:26 +0900." <000901c5da11$ddd09220$4c1598a3@nethogu> Message-ID: <200510261655.j9QGtH40059696@possum.icir.org> > Hi, all > > I have heard that > "In case of Linux, XORP only works in IPv4 because the kernel itself > doesn't support IPv6 multicast routing" > > Is this right? There is code in XORP that in theory should work for Linux IPv6 based on the assumption that the Linux IPv6 multicast forwarding API is same as KAME's BSD API (http://www.kame.net/). FYI, there is already IPv6 multicast forwarding patch for the Linux kernel (http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/) which has been merged already with the Usagi code (http://www.linux-ipv6.org/). Unfortunately, I haven't tried it yet. Pavlin From pavlin@icir.org Thu Oct 27 17:15:07 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 27 Oct 2005 09:15:07 -0700 Subject: [Xorp-users] "Gunmeetsingh Nagpal": Does Xorp Support Solaris Platform? Message-ID: <200510271615.j9RGF7nM048912@possum.icir.org> [Note: email forwarded to xorp-users@xorp.org because it is the right ML for such questions]. Currently XORP doesn't support Solaris, but we are interested in having it working on that OS. Has anyone succeeded or at least tried building XORP on Solaris? If there were compilation issues, obtaining a temporary login account on a Solaris box to fix those issues is always welcome :) Pavlin ------- Forwarded Message Subject: Does Xorp Support Solaris Platform? Date: Thu, 27 Oct 2005 08:29:42 -0700 Message-ID: <69B4FF51CCC44540A75309838116485BA4E640@roamexchange.mobileum.com> From: "Gunmeetsingh Nagpal" - ------_=_NextPart_001_01C5DB0B.4072EDD5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 I am interested in using Xorp . Can anyone confirm me if Xorp support = Solaris Platform .=20 =20 thanks & regards Gunmeet - ------_=_NextPart_001_01C5DB0B.4072EDD5-- ------- End of Forwarded Message From tdurack@gmail.com Thu Oct 27 20:26:47 2005 From: tdurack@gmail.com (Tim Durack) Date: Thu, 27 Oct 2005 15:26:47 -0400 Subject: [Xorp-users] Connected interfaces redistribution Message-ID: <9e246b4d0510271226j401d0044mf62bd33af437292d@mail.gmail.com> Looks like XORP is progressing nicely towards it's next release - thanks for all the hard work! I'm now able to reliably get OSPF running between two peers. I would like to be able to redistribute connected routes into BGP, but I'm not sure if this is possible yet. Any pointers? Seems like policy would allow me to do this, but I haven't really got my head around configuring policy stuff. Some examples would be great... Tim:> From atanu@ICSI.Berkeley.EDU Thu Oct 27 20:57:16 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 27 Oct 2005 12:57:16 -0700 Subject: [Xorp-users] Connected interfaces redistribution In-Reply-To: Message from Tim Durack of "Thu, 27 Oct 2005 15:26:47 EDT." <9e246b4d0510271226j401d0044mf62bd33af437292d@mail.gmail.com> Message-ID: <19205.1130443036@tigger.icir.org> Hi, There is a chapter in the user manual on configuring policy, but you will need to build it from source. The formatted manual on the web page does not have this chapter. There is also the recent paper . We will be putting examples in the manual. To answer your specific question: 1) Define a policy block that matches all connected routes. policy { policy-statement connected { term export { from { protocol: "rib" } } } } 2) Place an export statement in your protocol. protocols { bgp { bgp-id: 10.0.1.1 local-as: 65014 export: "connected" peer 192.168.0.2 { local-ip: 192.168.0.1 as: 65004 next-hop: 192.168.0.1 } } } If you want to export the static routes as well: policy { policy-statement static { term export { from { protocol: "static" } } } } protocols { bgp { bgp-id: 10.0.1.1 local-as: 65014 export: "connected,static" peer 192.168.0.2 { local-ip: 192.168.0.1 as: 65004 next-hop: 192.168.0.1 } } } Atanu. >>>>> "Tim" == Tim Durack writes: Tim> Looks like XORP is progressing nicely towards it's next release Tim> - thanks for all the hard work! Tim> I'm now able to reliably get OSPF running between two peers. Tim> I would like to be able to redistribute connected routes into Tim> BGP, but I'm not sure if this is possible yet. Any pointers? Tim> Seems like policy would allow me to do this, but I haven't Tim> really got my head around configuring policy stuff. Some Tim> examples would be great... Tim> Tim:> Tim> _______________________________________________ Xorp-users Tim> mailing list Xorp-users@xorp.org Tim> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From tdurack@gmail.com Thu Oct 27 21:33:42 2005 From: tdurack@gmail.com (Tim Durack) Date: Thu, 27 Oct 2005 16:33:42 -0400 Subject: [Xorp-users] Connected interfaces redistribution In-Reply-To: <19205.1130443036@tigger.icir.org> References: <9e246b4d0510271226j401d0044mf62bd33af437292d@mail.gmail.com> <19205.1130443036@tigger.icir.org> Message-ID: <9e246b4d0510271333i70913af7g5f41991d1608e3e3@mail.gmail.com> Ah, that's starting to make sense. I had to add a next-hop statement for routing to work: policy-statement connected { term export { from { protocol: "rib" } then { nexthop4: 10.240.1.1 } } } Thanks for the help! Tim:> From zhaoyuchi@gmail.com Fri Oct 28 03:48:47 2005 From: zhaoyuchi@gmail.com (Zhaoyu Chi) Date: Thu, 27 Oct 2005 22:48:47 -0400 Subject: [Xorp-users] Help:about kernel-level Click Message-ID: <17ffd49d0510271948t1fc79169teb36866dd18dcd8f@mail.gmail.com> I setup a network, as following. --------- ---------- --------- | | | | | | | A | | B | | C | | | | | | | --------- ---------- --------- | | | | | | | | | | ---------------------- ------------------ --------- NET-X NET-Y NET-Z It works very well using linux kernel(2.4.20) forwarding engine, user-level Click and kernel-level Click with duplicate-routes-to-kernel enable. However, when use kernel-level click without duplicate-routes-to-kernel enable, I cannot access A from C and other host on NET-Z. And, I can see the right final route table in XORP using 'xorpsh', but cannot see the route to NET-X on C using 'route' command. How can I use only the Click to forward packets instead using the linux kernel? From pavlin@icir.org Fri Oct 28 08:04:39 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 28 Oct 2005 00:04:39 -0700 Subject: [Xorp-users] Help:about kernel-level Click In-Reply-To: Message from Zhaoyu Chi of "Thu, 27 Oct 2005 22:48:47 EDT." <17ffd49d0510271948t1fc79169teb36866dd18dcd8f@mail.gmail.com> Message-ID: <200510280704.j9S74duN063153@possum.icir.org> > I setup a network, as following. > > --------- ---------- --------- > | | | | | | > | A | | B | | C | > | | | | | | > --------- ---------- --------- > | | | | | > | | | | | > ---------------------- ------------------ --------- > NET-X NET-Y NET-Z > > > It works very well using linux kernel(2.4.20) forwarding engine, > user-level Click and kernel-level Click with > duplicate-routes-to-kernel enable. However, when use kernel-level > click without duplicate-routes-to-kernel enable, I cannot access A > from C and other host on NET-Z. And, I can see the right final route > table in XORP using 'xorpsh', > but cannot see the route to NET-X on C using 'route' command. You need to look into the running Click configuration, and the installed Click routes. You cannot use the UNIX "route" to see the Click routes. Instead, for userland Click you have to do the following (someone please correct me because I am typing from memory): 1. telnet localhost 13000 2. read config To read the routing table you have to: read _xorp_rt4.table In case of kernel Click you have to read /click/config and /click/_xorp_rt4/table to get the installed configuration and the installed forwarding entries. Once you have the installed configuration and the forwarding entries, then try running only Click and play with the configuration to see where the problem is. Pavlin > > How can I use only the Click to forward packets instead using the linux kernel? > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Fri Oct 28 17:34:58 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 28 Oct 2005 09:34:58 -0700 Subject: [Xorp-users] Help:about kernel-level Click In-Reply-To: Message from Pavlin Radoslavov of "Fri, 28 Oct 2005 00:04:39 PDT." <200510280704.j9S74duN063153@possum.icir.org> Message-ID: <200510281634.j9SGYwiB068670@possum.icir.org> Forgot to ask, which XORP version are you using? Please try the lastest version from CVS. Pavlin > > I setup a network, as following. > > > > --------- ---------- --------- > > | | | | | | > > | A | | B | | C | > > | | | | | | > > --------- ---------- --------- > > | | | | | > > | | | | | > > ---------------------- ------------------ --------- > > NET-X NET-Y NET-Z > > > > > > It works very well using linux kernel(2.4.20) forwarding engine, > > user-level Click and kernel-level Click with > > duplicate-routes-to-kernel enable. However, when use kernel-level > > click without duplicate-routes-to-kernel enable, I cannot access A > > from C and other host on NET-Z. And, I can see the right final route > > table in XORP using 'xorpsh', > > but cannot see the route to NET-X on C using 'route' command. > > You need to look into the running Click configuration, and the > installed Click routes. > You cannot use the UNIX "route" to see the Click routes. > > Instead, for userland Click you have to do the following > (someone please correct me because I am typing from memory): > > 1. telnet localhost 13000 > 2. read config > To read the routing table you have to: > read _xorp_rt4.table > > In case of kernel Click you have to read /click/config and > /click/_xorp_rt4/table to get the installed configuration and the > installed forwarding entries. > > Once you have the installed configuration and the forwarding > entries, then try running only Click and play with the configuration > to see where the problem is. > > Pavlin > > > > > How can I use only the Click to forward packets instead using the linux kernel? > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From tdurack@gmail.com Fri Oct 28 20:29:59 2005 From: tdurack@gmail.com (Tim Durack) Date: Fri, 28 Oct 2005 15:29:59 -0400 Subject: [Xorp-users] rtrmgr { load-http-command } Message-ID: <9e246b4d0510281229i7606b20ew2227d90f670e6802@mail.gmail.com> Is the load-http functionality fully-baked? rtrmgr { load-http-command: "wget" load-http-command-args: "-q" } XORP> load http://192.168.1.253/xen1.config Load done. [edit] XORP> show My web server shows the config being pulled, but XORP shows a blank config afterwards. It would be great if this worked, then my Xen/XORP lab would bootstrap nicely :-) Tim:> From tdurack@gmail.com Fri Oct 28 22:21:27 2005 From: tdurack@gmail.com (Tim Durack) Date: Fri, 28 Oct 2005 17:21:27 -0400 Subject: [Xorp-users] Re: rtrmgr { load-http-command } In-Reply-To: <9e246b4d0510281229i7606b20ew2227d90f670e6802@mail.gmail.com> References: <9e246b4d0510281229i7606b20ew2227d90f670e6802@mail.gmail.com> Message-ID: <9e246b4d0510281421g6cc5f46fh1cdecd742be45faf@mail.gmail.com> I spoke to soon. curl works (default is to write to stdout) wget doesn't (default is to write to file) - I was setting "-O -" to force stdout. Tim:> On 10/28/05, Tim Durack wrote: > Is the load-http functionality fully-baked? > > rtrmgr { > load-http-command: "wget" > load-http-command-args: "-q" > } > > XORP> load http://192.168.1.253/xen1.config > Load done. > [edit] > XORP> show > > My web server shows the config being pulled, but XORP shows a blank > config afterwards. > > It would be great if this worked, then my Xen/XORP lab would bootstrap > nicely :-) > > Tim:> > From feamster@lcs.mit.edu Sat Oct 29 04:32:05 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Fri, 28 Oct 2005 23:32:05 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <73252.1129888439@tigger.icir.org> References: <20051020164509.GA16606@lcs.mit.edu> <73252.1129888439@tigger.icir.org> Message-ID: <20051029033205.GN19281@lcs.mit.edu> Atanu, Finally got around to testing the patches from CVS tonight. Looks good; I'm no longer getting the crash in OSPF. I don't quite see the routing table as below yes, but I'll mess with the configuration a little bit more...might be a config problem on my end. Essentially, I'm seeing p3 send: [ 5326 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0, src = 128.31.1.13, dst = 128.31.1.14, payload_size = 44 But p4 never receives... -Nick On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote: > >>>>> "Nick" == Nick Feamster writes: > > Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote: > >> of the routers neighbours are the designated router or backup > >> designated router. This method should only be called if the the > >> link type is Broadcast or NBMA, as these are the only link types > >> that perform DR election. I assume that the link-type is set to > >> point-to-multipoint (p2m), in when case the assert is signalling > >> a programming error. The OSPF process will have exited. A stack > >> backtrace might yield some clues. > > Nick> Yes, the link-type is p2m in our case, so perhaps this method > Nick> should not be called? It appears that the OSPF process dies > Nick> completely as a result. Sure, I will send along a backtrace. > > This problem is now fixed in CVS. > > >> If the problem is reproducible with the latest code from CVS then > >> the configuration files and some information about the topology > >> would be useful. > > Nick> Simple topology: > > Nick> A <-> B <-> C, where both links are p2m links. I've attached > Nick> the configuration files. > > I'v included a cut down configuration files that worked for me. I had to > modify the prefix length from 32 to 24 on the first router. Also you > shouldn't be setting discard to true on interfaces that you want to > route traffic through. > > >> If an attempt was made to add a route to the RIB and it failed > >> you should error messages in the log. > > Nick> How do I ensure that routes are in the RIB, then? Here's what > Nick> I see in the log. > > Use the show route command: > Xorp> show route table ipv4 unicast ospf > Network 128.31.1.15/32 > Nexthop := 128.31.1.14 > Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 > > To see the final table: > Xorp> show route table ipv4 unicast final > Network 128.31.1.0/24 > Nexthop := 128.31.1.13 > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > Network 128.31.1.15/32 > Nexthop := 128.31.1.14 > Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 > > Atanu. > Content-Description: p3 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.13 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.13 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.13 { > interface-cost: 5 > neighbour 128.31.1.14 { > router-id: 128.31.1.14 > } > } > } > } > } > } > } > } Content-Description: p4 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.14 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.14 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.14 { > interface-cost: 5 > neighbour 128.31.1.13 { > router-id: 128.31.1.13 > } > neighbour 128.31.1.15 { > router-id: 128.31.1.15 > } > } > } > } > } > } > } > } Content-Description: p5 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.15 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.15 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.15 { > interface-cost: 5 > neighbour 128.31.1.13 { > router-id: 128.31.1.13 > } > neighbour 128.31.1.14 { > router-id: 128.31.1.14 > } > } > } > } > } > } > } > } From feamster@lcs.mit.edu Sat Oct 29 05:12:01 2005 From: feamster@lcs.mit.edu (Nick Feamster) Date: Sat, 29 Oct 2005 00:12:01 -0400 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: <73252.1129888439@tigger.icir.org> References: <20051020164509.GA16606@lcs.mit.edu> <73252.1129888439@tigger.icir.org> Message-ID: <20051029041201.GD19630@lcs.mit.edu> Spoke a bit too soon. I'm still getting these error logs on p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) Interface( eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) Interface(eth 0/eth0) Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(eth0 /eth0) Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27 FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_ or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29 00:10:37 ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc delete_entry ] User-level Click command error: 520-Write handler '_xorp_rt4.rem ove' error: 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37 ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_ result ] FTI transaction commit failed on DeleteEntry4: net = 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = fals e is_deleted = false is_unresolved = false is_connected_route = false [ 2005/10/29 00:10:37 ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc delete_entry ] User-level Click command error: 520-Write handler '_xorp_rt4.rem ove' error: 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37 ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc delete_entry ] User-level Click command error: 520-Write handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 - -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea XrlFeaTarget ] Handling method for redist _transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_ connected_route = false On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote: > >>>>> "Nick" == Nick Feamster writes: > > Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote: > >> of the routers neighbours are the designated router or backup > >> designated router. This method should only be called if the the > >> link type is Broadcast or NBMA, as these are the only link types > >> that perform DR election. I assume that the link-type is set to > >> point-to-multipoint (p2m), in when case the assert is signalling > >> a programming error. The OSPF process will have exited. A stack > >> backtrace might yield some clues. > > Nick> Yes, the link-type is p2m in our case, so perhaps this method > Nick> should not be called? It appears that the OSPF process dies > Nick> completely as a result. Sure, I will send along a backtrace. > > This problem is now fixed in CVS. > > >> If the problem is reproducible with the latest code from CVS then > >> the configuration files and some information about the topology > >> would be useful. > > Nick> Simple topology: > > Nick> A <-> B <-> C, where both links are p2m links. I've attached > Nick> the configuration files. > > I'v included a cut down configuration files that worked for me. I had to > modify the prefix length from 32 to 24 on the first router. Also you > shouldn't be setting discard to true on interfaces that you want to > route traffic through. > > >> If an attempt was made to add a route to the RIB and it failed > >> you should error messages in the log. > > Nick> How do I ensure that routes are in the RIB, then? Here's what > Nick> I see in the log. > > Use the show route command: > Xorp> show route table ipv4 unicast ospf > Network 128.31.1.15/32 > Nexthop := 128.31.1.14 > Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 > > To see the final table: > Xorp> show route table ipv4 unicast final > Network 128.31.1.0/24 > Nexthop := 128.31.1.13 > Metric := 0 Protocol := connected Interface := eth0 Vif := eth0 > Network 128.31.1.15/32 > Nexthop := 128.31.1.14 > Metric := 10 Protocol := ospf Interface := eth0 Vif := eth0 > > Atanu. > Content-Description: p3 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.13 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.13 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.13 { > interface-cost: 5 > neighbour 128.31.1.14 { > router-id: 128.31.1.14 > } > } > } > } > } > } > } > } Content-Description: p4 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.14 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.14 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.14 { > interface-cost: 5 > neighbour 128.31.1.13 { > router-id: 128.31.1.13 > } > neighbour 128.31.1.15 { > router-id: 128.31.1.15 > } > } > } > } > } > } > } > } Content-Description: p5 > interfaces { > interface eth0 { > vif eth0 { > address 128.31.1.15 { > prefix-length: 24 > } > } > } > } > protocols { > ospf4 { > router-id: 128.31.1.15 > > area 0.0.0.0 { > interface eth0 { > link-type: "p2m" > vif eth0 { > address 128.31.1.15 { > interface-cost: 5 > neighbour 128.31.1.13 { > router-id: 128.31.1.13 > } > neighbour 128.31.1.14 { > router-id: 128.31.1.14 > } > } > } > } > } > } > } > } From atanu@ICSI.Berkeley.EDU Sat Oct 29 09:07:50 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 29 Oct 2005 01:07:50 -0700 Subject: [Xorp-users] Re: help establishing OSPF adjacencies In-Reply-To: Message from Nick Feamster of "Sat, 29 Oct 2005 00:12:01 EDT." <20051029041201.GD19630@lcs.mit.edu> Message-ID: <80646.1130573270@tigger.icir.org> Hi, I don't think that you have the latest code, I still see an Assertion in the trace (Assertion (do_dr_or_bdr()) failed). Atanu. >>>>> "Nick" == Nick Feamster writes: Nick> Spoke a bit too soon. I'm still getting these error logs on Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Nick> Event(DataDescriptionReceived-pse udo-event) Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [ Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Nick> Event(NegotiationDone) Interface( eth0/eth0) Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27 Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15) Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Nick> Event(ExchangeDone) Interface(eth 0/eth0) Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27 Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13) Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ] Nick> Event(LoadingDone) Interface(eth0 /eth0) Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27 Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_ Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29 Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433 Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error: Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37 Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_ Nick> result ] FTI transaction commit failed on DeleteEntry4: net = Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0 Nick> admin_distance = 0 xorp_route = fals e is_deleted = false Nick> is_unresolved = false is_connected_route = false [ 2005/10/29 Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433 Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error: Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37 Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc Nick> delete_entry ] User-level Click command error: 520-Write Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 - Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea Nick> XrlFeaTarget ] Handling method for redist Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102 Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop = Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0 Nick> xorp_route = false is_deleted = false is_unresolved = false Nick> is_ connected_route = false Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote: >> >>>>> "Nick" == Nick Feamster writes: >> Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote: >> >> of the routers neighbours are the designated router or backup >> >> designated router. This method should only be called if the >> the >> link type is Broadcast or NBMA, as these are the only link >> types >> that perform DR election. I assume that the link-type is >> set to >> point-to-multipoint (p2m), in when case the assert is >> signalling >> a programming error. The OSPF process will have >> exited. A stack >> backtrace might yield some clues. >> Nick> Yes, the link-type is p2m in our case, so perhaps this method Nick> should not be called? It appears that the OSPF process dies Nick> completely as a result. Sure, I will send along a backtrace. >> This problem is now fixed in CVS. >> >> >> If the problem is reproducible with the latest code from CVS >> then >> the configuration files and some information about the >> topology >> would be useful. >> Nick> Simple topology: >> Nick> A <-> B <-> C, where both links are p2m links. I've attached Nick> the configuration files. >> I'v included a cut down configuration files that worked for >> me. I had to modify the prefix length from 32 to 24 on the first >> router. Also you shouldn't be setting discard to true on >> interfaces that you want to route traffic through. >> >> >> If an attempt was made to add a route to the RIB and it failed >> >> you should error messages in the log. >> Nick> How do I ensure that routes are in the RIB, then? Here's what Nick> I see in the log. >> Use the show route command: Xorp> show route table ipv4 unicast ospf >> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10 >> Protocol := ospf Interface := eth0 Vif := eth0 >> >> To see the final table: Xorp> show route table ipv4 unicast final >> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0 Protocol >> := connected Interface := eth0 Vif := eth0 Network 128.31.1.15/32 >> Nexthop := 128.31.1.14 Metric := 10 Protocol := ospf Interface := >> eth0 Vif := eth0 >> >> Atanu. >> Nick> Content-Description: p3 >> interfaces { interface eth0 { vif eth0 { address 128.31.1.13 { >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >> 128.31.1.13 >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >> address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 { >> router-id: 128.31.1.14 } } } } } } } } Nick> Content-Description: p4 >> interfaces { interface eth0 { vif eth0 { address 128.31.1.14 { >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >> 128.31.1.14 >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >> address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 { >> router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id: >> 128.31.1.15 } } } } } } } } Nick> Content-Description: p5 >> interfaces { interface eth0 { vif eth0 { address 128.31.1.15 { >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >> 128.31.1.15 >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >> address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 { >> router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id: >> 128.31.1.14 } } } } } } } } From kristian@juniks.net Sun Oct 30 14:37:09 2005 From: kristian@juniks.net (Kristian Larsson) Date: Sun, 30 Oct 2005 15:37:09 +0100 Subject: [Xorp-users] "Gunmeetsingh Nagpal": Does Xorp Support Solaris Platform? In-Reply-To: <200510271850.j9RIo8PE050114@possum.icir.org> References: <20051027183418.GD3639@juniks.net> <200510271850.j9RIo8PE050114@possum.icir.org> Message-ID: <20051030143709.GB13127@juniks.net> I am sorry but I have been unable to setup the machine. I don't seem to have the proper console cable and thus I am unable to control the server. On top of that the machine is located at "home", I moved a month ago and now live three hours away. I'll try to get a shot at it next weekend too, if anyone has any pointers on the serial cable of a Sun Enterprise 220 R I'd be really grateful. Kristian On Thu, Oct 27, 2005 at 11:50:08AM -0700, Pavlin Radoslavov wrote: > > I could setup a Solaris box over the weekend. > > Thanks! > > For the login name of the temporary account please use some generic > name like xorp_dev (or something like this). > > Pavlin From deathdealer@gmx.net Sun Oct 30 15:05:52 2005 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Sun, 30 Oct 2005 16:05:52 +0100 (MET) Subject: [Xorp-users] "Gunmeetsingh Nagpal": Does Xorp Support Solaris Platform? References: <20051030143709.GB13127@juniks.net> Message-ID: <21895.1130684752@www57.gmx.net> Hello Kristian, hope this helps http://www.sunhelp.org/unix-serial-port-resources/serial-pinouts/#u12.link regards Patrick > --- Ursprüngliche Nachricht --- > Von: Kristian Larsson > An: Pavlin Radoslavov > Kopie: xorp-users@xorp.org > Betreff: Re: [Xorp-users] "Gunmeetsingh Nagpal": Does Xorp Support Solaris > Platform? > Datum: Sun, 30 Oct 2005 15:37:09 +0100 > > I am sorry but I have been unable to setup the > machine. > I don't seem to have the proper console cable and > thus I am unable to control the server. On top of > that the machine is located at "home", I moved a > month ago and now live three hours away. > I'll try to get a shot at it next weekend too, if > anyone has any pointers on the serial cable of a > Sun Enterprise 220 R I'd be really grateful. > > Kristian > > On Thu, Oct 27, 2005 at 11:50:08AM -0700, Pavlin Radoslavov wrote: > > > I could setup a Solaris box over the weekend. > > > > Thanks! > > > > For the login name of the temporary account please use some generic > > name like xorp_dev (or something like this). > > > > Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- best regards Patrick Marc Preuss ---------------------------------------------------------------------- -- "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" (1979) Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From zhaoyuchi@gmail.com Mon Oct 31 17:49:22 2005 From: zhaoyuchi@gmail.com (Zhaoyu Chi) Date: Mon, 31 Oct 2005 12:49:22 -0500 Subject: [Xorp-users] Does the kernel-land Click support Multicast? Message-ID: <17ffd49d0510310949v6bc54870n14cb9684cf454537@mail.gmail.com> Hi: I setup a network using XORP with kernel-land Click. The unicast forwarding wroks very well, but the multicast forwarding seems not work. Is there anyone successfully using the kernel-land Click to forward Multicast data? Does the kernel-land Click support Multicast? Thanks in advance. Zhaoyu From pavlin@icir.org Mon Oct 31 18:14:48 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 31 Oct 2005 10:14:48 -0800 Subject: [Xorp-users] Does the kernel-land Click support Multicast? In-Reply-To: Message from Zhaoyu Chi of "Mon, 31 Oct 2005 12:49:22 EST." <17ffd49d0510310949v6bc54870n14cb9684cf454537@mail.gmail.com> Message-ID: <200510311814.j9VIEmZa066741@possum.icir.org> > I setup a network using XORP with kernel-land Click. The unicast > forwarding wroks very well, but the multicast forwarding seems not > work. Is there anyone successfully using the kernel-land Click to > forward Multicast data? Does the kernel-land Click support Multicast? No, Click does not have support for multicast forwarding. Pavlin