From reach_dinesh at hotmail.com Tue Jan 1 21:11:31 2008 From: reach_dinesh at hotmail.com (Dinesh Kumar) Date: Wed, 2 Jan 2008 13:11:31 +0800 Subject: [Xorp-users] Missing OSPF neighbours In-Reply-To: References: Message from Dinesh Kumar of <19110.1198708018@tigger.icir.org> Message-ID: Hi All, OSPF is working now. The cause of missing OSPF neighbours was the firewall running in Linux. When I disabled it, adjacency was established. Thanks, Dinesh ---------------------------------------- > From: reach_dinesh at hotmail.com > To: atanu at ICSI.Berkeley.EDU > Date: Thu, 27 Dec 2007 12:12:27 +0800 > CC: xorp-users at xorp.org > Subject: Re: [Xorp-users] Missing OSPF neighbours > > > Hi Atanu, > > Thank you so much for your reply. I tried removing the static routes and restarted the xorp_rtrmgr processes in both the PCs. But there is no adjacency yet. Also, I am connecting two PCs through a cross-cable, ethernet to ethernet direct. > > dinesh at linux-xorp> show ospf4 neighbor > Address Interface State ID Pri Dead > dinesh at linux-xorp> > > But in one of the PC, I am getting the following error while starting xorp_rtrmgr process, which I did not notice it before. > > [ 2007/12/27 12:02:34 ERROR xorp_fea:18805 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol > [ 2007/12/27 12:02:34 ERROR xorp_fea:18805 LIBCOMM +114 comm_sock.c comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol > > Is this error related to forming adjacency between the PCs ? > > Thanks, > Dinesh > ---------------------------------------- >> To: reach_dinesh at hotmail.com >> CC: xorp-users at xorp.org >> Subject: Re: [Xorp-users] Missing OSPF neighbours >> From: atanu at icsi.berkeley.edu >> Date: Wed, 26 Dec 2007 14:26:58 -0800 >> >> Hi, >> >> Your config files worked fine for me (I changed the interface addresses >> for my setup and didn't include the static route). By the way I wouldn't >> expect to see any ospf routes, the two routers can already reach each >> other. >> >> Atanu. >> >> Xorp> show ospf4 neighbor >> Address Interface State ID Pri Dead >> 10.0.1.5 fxp1/fxp1 Full 10.0.0.1 128 33 >> >> Xorp> show ospf4 neighbor >> Address Interface State ID Pri Dead >> 10.0.1.1 xl0/xl0 Full 10.0.0.2 128 35 >> >> D>>>>> "Dinesh" == Dinesh Kumar writes: >> Dinesh> ear XORP users, >> >> Dinesh> I have configured OSPF using xorp between 2 PCs running linux. I am not able to see any OSPF neighbours in the xorp shell (xorpsh) in both the PCs. >> >> Dinesh> PC1:(using config1.boot) >> Dinesh> ------------------------------ >> Dinesh> dinesh at linux-xorp> show ospf4 neighbor >> Dinesh> Address Interface State ID Pri Dead >> Dinesh> dinesh at linux-xorp> >> >> Dinesh> dinesh at linux-xorp> show route table ipv4 unicast ospf >> Dinesh> dinesh at linux-xorp> >> >> Dinesh> dinesh at linux-xorp> show ospf4 database >> Dinesh> OSPF link state database, Area 0.0.0.0 >> Dinesh> Type ID Adv Rtr Seq Age Opt Cksum Len >> Dinesh> Router *10.0.0.2 10.0.0.2 0x80000001 105 0x2 0x260a 36 >> Dinesh> dinesh at linux-xorp> >> >> >> Dinesh> I am really not sure why there is no adjacency between these two PCs. I have checked the reachability between them also. >> >> Dinesh> From PC1 to PC2: >> Dinesh> ----------------------- >> Dinesh> dinesh at linux-xorp> ping 10.0.0.1 >> Dinesh> PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. >> Dinesh> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.54 ms >> Dinesh> 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.204 ms >> Dinesh> 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.212 ms >> Dinesh> 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.204 ms >> >> Dinesh> Command interrupted! >> >> Dinesh> dinesh at linux-xorp> >> >> Dinesh> From PC2 to PC1: >> Dinesh> ---------------------- >> Dinesh> dinesh at linux-xorp2> ping 10.0.0.2 >> Dinesh> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >> Dinesh> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.191 ms >> Dinesh> 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.182 ms >> Dinesh> 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.177 ms >> >> Dinesh> Command interrupted! >> >> Dinesh> dinesh at linux-xorp2> >> >> Dinesh> I have attached the config.boot files of both the PCs. I would be very much obliged if somebody can point out if i have missed anything in config.boot. Thanks in advance. >> >> Dinesh> Regards, >> Dinesh> Dinesh >> >> Dinesh> _________________________________________________________________ >> Dinesh> Get your free suite of Windows Live services today! >> Dinesh> http://www.get.live.com/wl/all_______________________________________________ >> Dinesh> Xorp-users mailing list >> Dinesh> Xorp-users at xorp.org >> Dinesh> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _________________________________________________________________ > Publish your photos to your Space easily with Photo Gallery. > http://www.get.live.com/wl/all > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _________________________________________________________________ Edit your photos like a pro with Photo Gallery. http://www.get.live.com/wl/all From reach_dinesh at hotmail.com Tue Jan 1 23:30:19 2008 From: reach_dinesh at hotmail.com (Dinesh Kumar) Date: Wed, 2 Jan 2008 15:30:19 +0800 Subject: [Xorp-users] Missing OSPF neighbours In-Reply-To: <57043.1199251843@tigger.icir.org> References: Message from Dinesh Kumar of <57043.1199251843@tigger.icir.org> Message-ID: Thanks Atanu. I really appreciate your time and efforts. Also would like to appreciate the efforts of Pavlin, who has helped me many times. Thanks Pavlin !! It is because of people like you, I was able to proceed till this point in my project. (I knew nothing about xorp, when I started). Great Work guys, Keep it going!! With lots of appreciation, Dinesh ---------------------------------------- > To: reach_dinesh at hotmail.com > Subject: Re: [Xorp-users] Missing OSPF neighbours > From: atanu at icsi.berkeley.edu > Date: Tue, 1 Jan 2008 21:30:43 -0800 > > Hi, > > Glad to hear that it is working now. > > Atanu. > >>>>>> "Dinesh" == Dinesh Kumar writes: > > Dinesh> Hi All, > > Dinesh> OSPF is working now. The cause of missing OSPF neighbours > Dinesh> was the firewall running in Linux. When I disabled it, > Dinesh> adjacency was established. > > Dinesh> Thanks, Dinesh ---------------------------------------- > >> From: reach_dinesh at hotmail.com To: atanu at ICSI.Berkeley.EDU Date: > >> Thu, 27 Dec 2007 12:12:27 +0800 CC: xorp-users at xorp.org Subject: > >> Re: [Xorp-users] Missing OSPF neighbours > >> > >> > >> Hi Atanu, > >> > >> Thank you so much for your reply. I tried removing the static > >> routes and restarted the xorp_rtrmgr processes in both the > >> PCs. But there is no adjacency yet. Also, I am connecting two > >> PCs through a cross-cable, ethernet to ethernet direct. > >> > >> dinesh at linux-xorp> show ospf4 neighbor Address Interface State ID > >> Pri Dead dinesh at linux-xorp> > >> > >> But in one of the PC, I am getting the following error while > >> starting xorp_rtrmgr process, which I did not notice it before. > >> > >> [ 2007/12/27 12:02:34 ERROR xorp_fea:18805 LIBCOMM +114 > >> comm_sock.c comm_sock_open ] Error opening socket (domain = 10, > >> type = 2, protocol = 0): Address family not supported by protocol > >> [ 2007/12/27 12:02:34 ERROR xorp_fea:18805 LIBCOMM +114 > >> comm_sock.c comm_sock_open ] Error opening socket (domain = 10, > >> type = 2, protocol = 0): Address family not supported by protocol > >> > >> Is this error related to forming adjacency between the PCs ? > >> > >> Thanks, Dinesh > >> ---------------------------------------- > >>> To: reach_dinesh at hotmail.com CC: xorp-users at xorp.org Subject: > >>> Re: [Xorp-users] Missing OSPF neighbours From: > >>> atanu at icsi.berkeley.edu Date: Wed, 26 Dec 2007 14:26:58 -0800 > >>> > >>> Hi, > >>> > >>> Your config files worked fine for me (I changed the interface > >>> addresses for my setup and didn't include the static route). By > >>> the way I wouldn't expect to see any ospf routes, the two > >>> routers can already reach each other. > >>> > >>> Atanu. > >>> > Xorp> show ospf4 neighbor > >>> Address Interface State ID Pri Dead 10.0.1.5 fxp1/fxp1 Full > >>> 10.0.0.1 128 33 > >>> > Xorp> show ospf4 neighbor > >>> Address Interface State ID Pri Dead 10.0.1.1 xl0/xl0 Full > >>> 10.0.0.2 128 35 > >>> > D> "Dinesh" == Dinesh Kumar writes: > Dinesh> ear XORP users, > >>> > Dinesh> I have configured OSPF using xorp between 2 PCs running > Dinesh> linux. I am not able to see any OSPF neighbours in the xorp > Dinesh> shell (xorpsh) in both the PCs. > >>> > Dinesh> PC1:(using config1.boot) ------------------------------ > Dinesh> dinesh at linux-xorp> show ospf4 neighbor Address Interface > Dinesh> State ID Pri Dead dinesh at linux-xorp> > >>> > Dinesh> dinesh at linux-xorp> show route table ipv4 unicast ospf > Dinesh> dinesh at linux-xorp> > >>> > Dinesh> dinesh at linux-xorp> show ospf4 database OSPF link state > Dinesh> database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len > Dinesh> Router *10.0.0.2 10.0.0.2 0x80000001 105 0x2 0x260a 36 > Dinesh> dinesh at linux-xorp> > >>> > Dinesh> I am really not sure why there is no adjacency between these > Dinesh> two PCs. I have checked the reachability between them also. > >>> > Dinesh> From PC1 to PC2: ----------------------- dinesh at linux-xorp> > Dinesh> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. > Dinesh> 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=3.54 ms 64 > Dinesh> bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.204 ms 64 > Dinesh> bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.212 ms 64 > Dinesh> bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.204 ms > >>> > Dinesh> Command interrupted! > >>> > Dinesh> dinesh at linux-xorp> > >>> > Dinesh> From PC2 to PC1: ---------------------- dinesh at linux-xorp2> > Dinesh> ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > Dinesh> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.191 ms 64 > Dinesh> bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.182 ms 64 > Dinesh> bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.177 ms > >>> > Dinesh> Command interrupted! > >>> > Dinesh> dinesh at linux-xorp2> > >>> > Dinesh> I have attached the config.boot files of both the PCs. I > Dinesh> would be very much obliged if somebody can point out if i > Dinesh> have missed anything in config.boot. Thanks in advance. > >>> > Dinesh> Regards, Dinesh > >>> > Dinesh> _________________________________________________________________ > Dinesh> Get your free suite of Windows Live services today! > Dinesh> http://www.get.live.com/wl/all_______________________________________________ > Dinesh> Xorp-users mailing list Xorp-users at xorp.org > Dinesh> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> > >> _________________________________________________________________ > >> Publish your photos to your Space easily with Photo Gallery. > >> http://www.get.live.com/wl/all > >> > >> _______________________________________________ Xorp-users > >> mailing list Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > Dinesh> _________________________________________________________________ > Dinesh> Edit your photos like a pro with Photo Gallery. > Dinesh> http://www.get.live.com/wl/all > > Dinesh> _______________________________________________ Xorp-users > Dinesh> mailing list Xorp-users at xorp.org > Dinesh> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _________________________________________________________________ Easily manage multiple email accounts with Windows Live Mail! http://www.get.live.com/wl/all From yueli.m at gmail.com Fri Jan 4 16:02:55 2008 From: yueli.m at gmail.com (Yue Li) Date: Fri, 4 Jan 2008 19:02:55 -0500 Subject: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found Message-ID: <49567c360801041602s79b402e3l2c786289708026fe@mail.gmail.com> Hi, everyone I am doing some experiment with ospfv2. The problem is xorp is keep saying "no matching neighbor found" when receiving database description packets. When I show ospf database through xorpsh, there is nothing. Can you give me any clues? Thanks! From atanu at ICSI.Berkeley.EDU Fri Jan 4 16:58:32 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 04 Jan 2008 16:58:32 -0800 Subject: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found In-Reply-To: Message from "Yue Li" of "Fri, 04 Jan 2008 19:02:55 EST." <49567c360801041602s79b402e3l2c786289708026fe@mail.gmail.com> Message-ID: <81022.1199494712@tigger.icir.org> Hi, The XORP OSPF will not accept data description packets from an unknown neighbour (this is a protocol requirement). Can you send the output of the "show ospf4 neighbor" command? Atanu. . >>>>> "Yue" == Yue Li writes: Yue> Hi, everyone I am doing some experiment with ospfv2. The Yue> problem is xorp is keep saying "no matching neighbor found" Yue> when receiving database description packets. When I show ospf Yue> database through xorpsh, there is nothing. Yue> Can you give me any clues? Thanks! Yue> _______________________________________________ Xorp-users Yue> mailing list Xorp-users at xorp.org Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From yueli.m at gmail.com Sat Jan 5 22:54:06 2008 From: yueli.m at gmail.com (Yue Li) Date: Sun, 6 Jan 2008 01:54:06 -0500 Subject: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found In-Reply-To: <49567c360801052251yda0f2e3xd98ef19a90c1bd7e@mail.gmail.com> References: <49567c360801041602s79b402e3l2c786289708026fe@mail.gmail.com> <81022.1199494712@tigger.icir.org> <49567c360801052251yda0f2e3xd98ef19a90c1bd7e@mail.gmail.com> Message-ID: <49567c360801052254k77f150ebp23a1c978bd1b697b@mail.gmail.com> ---------- Forwarded message ---------- From: Yue Li Date: 2008-1-6 ??1:51 Subject: Re: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found To: atanu at icsi.berkeley.edu Hi, Thanks for your reply. The topology used is as follow: +---+ (10.10.0.9) (10.10.0.10)+---+ | A |----------------------------------------- | B | +---+ +---+ |(10.10.0.1) | (10.10.0.6) | | | | (10.10.0.5) | (10.10.0.2) +----+ - --------------------------------------------| C | +----+ Router A (id: 10.10.0.1), Router B (id: 10.10.0.10) and Router C (id: 10.10.0.5), each has two neighbors. On Router A: show ospf4 neighbor: Address Interface State ID Pri Dead 10.10.0.2 tun0/tun0 ExStart 10.10.0.5 128 31 10.10.0.10 tun1/tun1 ExStart 10.10.0.10 128 33 show ospf4 database: OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *10.10.0.1 10.10.0.1 0x80000001 78 0x2 0xad78 48 2008/1/4, Atanu Ghosh : > Hi, > > The XORP OSPF will not accept data description packets from an unknown > neighbour (this is a protocol requirement). > > Can you send the output of the "show ospf4 neighbor" command? > > Atanu. > . > >>>>> "Yue" == Yue Li writes: > > Yue> Hi, everyone I am doing some experiment with ospfv2. The > Yue> problem is xorp is keep saying "no matching neighbor found" > Yue> when receiving database description packets. When I show ospf > Yue> database through xorpsh, there is nothing. > > Yue> Can you give me any clues? Thanks! > > Yue> _______________________________________________ Xorp-users > Yue> mailing list Xorp-users at xorp.org > Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From donghaima at gmail.com Mon Jan 7 14:15:56 2008 From: donghaima at gmail.com (Donghai Ma) Date: Mon, 7 Jan 2008 17:15:56 -0500 Subject: [Xorp-users] A question on exporting connected routes into OSPF Message-ID: <50e8f1110801071415o5fab45f3sfb555c56b223dc32@mail.gmail.com> Hello List, I am new to XORP and having difficulties to get XORP to distribute connected routes into OSPF. For example, after I add an address to eth1: $ ip addr add 8.65.1.10/32 dev eth1 I'd like the connected route 8.65.1.10/32 be distributed by the OSPF process. After reading through the XORP manual I have the latest 1.4 release running on my Linux box. The OSPF process is receiving routes correctly from the upstream router. But the route export/distribution does not work as I had hoped. When I add or delete ip addresses the XORP process does not do OSPF LS Update. My question is: does XORP currently support this kind of route distribution? And if yes how to make this work? Any help is very much appreciated! Thanks, -Donghai Ma PS. Here is my configuration: -------------------------------------------- xorp config file starts -------------------------------------------- /* $XORP: xorp/rtrmgr/config.boot 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth1 { description: "eth1" disable: false /* default-system-config */ vif eth1 { disable: false address 5.8.27.2 { prefix-length: 24 broadcast: 5.8.27.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } policy { /* Describe connected routes for redistribution */ policy-statement POLICY_CONNECTED { term 1 { from { protocol: "connected" } then { trace 3 accept } } } } protocols { ospf4 { router-id: 5.8.27.2 area 0.0.0.0 { area-type: "normal" interface eth1 { /* link-type: "broadcast" */ vif eth1 { address 5.8.27.2 { } } } } export: "POLICY_CONNECTED" } } -------------------------------------------- xorp config file ends -------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080107/c483af3a/attachment.html From atanu at ICSI.Berkeley.EDU Tue Jan 8 15:37:42 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 08 Jan 2008 15:37:42 -0800 Subject: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found In-Reply-To: Message from "Yue Li" of "Sun, 06 Jan 2008 01:54:06 EST." <49567c360801052254k77f150ebp23a1c978bd1b697b@mail.gmail.com> Message-ID: <48018.1199835462@tigger.icir.org> Hi, In OSPF some packets such as the hello packets are multicast and other packets such as the data description packets are unicast. The source address in a packet is used to demultiplex a packet and associate it with a neighbour. I notice from the output of "show ospf4 neighbour" that you seem to be using tunnels. What may be happening is that the hello packets that are multicast are being received with the orignal source address provided by OSPF, the source address of unicast packets may be changed by the tunnel, which could explain why they are not recognised. Try running tcpdump on router A and check the source addresses of received packets. Atanu. >>>>> "Yue" == Yue Li writes: Yue> ---------- Forwarded message ---------- Yue> From: Yue Li Yue> Date: 2008-1-6 ????1:51 Yue> Subject: Re: [Xorp-users] [xorp-users] OSPFv2 problem: no matching Yue> neighbor found Yue> To: atanu at icsi.berkeley.edu Yue> Hi, Yue> Thanks for your reply. Yue> The topology used is as follow: Yue> +---+ (10.10.0.9) (10.10.0.10)+---+ Yue> | A |----------------------------------------- | B | Yue> +---+ +---+ Yue> |(10.10.0.1) | (10.10.0.6) Yue> | | Yue> | | (10.10.0.5) Yue> | (10.10.0.2) +----+ Yue> - --------------------------------------------| C | Yue> +----+ Yue> Router A (id: 10.10.0.1), Router B (id: 10.10.0.10) and Router C (id: Yue> 10.10.0.5), Yue> each has two neighbors. Yue> On Router A: Yue> show ospf4 neighbor: Yue> Address Interface State ID Pri Dead Yue> 10.10.0.2 tun0/tun0 ExStart 10.10.0.5 128 31 Yue> 10.10.0.10 tun1/tun1 ExStart 10.10.0.10 128 33 Yue> show ospf4 database: Yue> OSPF link state database, Area 0.0.0.0 Yue> Type ID Adv Rtr Seq Age Opt Cksum Len Yue> Router *10.10.0.1 10.10.0.1 0x80000001 78 0x2 0xad78 48 Yue> 2008/1/4, Atanu Ghosh : >> Hi, >> >> The XORP OSPF will not accept data description packets from an unknown >> neighbour (this is a protocol requirement). >> >> Can you send the output of the "show ospf4 neighbor" command? >> >> Atanu. >> . >> >>>>> "Yue" == Yue Li writes: >> Yue> Hi, everyone I am doing some experiment with ospfv2. The Yue> problem is xorp is keep saying "no matching neighbor found" Yue> when receiving database description packets. When I show ospf Yue> database through xorpsh, there is nothing. >> Yue> Can you give me any clues? Thanks! >> Yue> _______________________________________________ Xorp-users Yue> mailing list Xorp-users at xorp.org Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> From atanu at ICSI.Berkeley.EDU Tue Jan 8 16:25:35 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 08 Jan 2008 16:25:35 -0800 Subject: [Xorp-users] A question on exporting connected routes into OSPF In-Reply-To: Message from "Donghai Ma" of "Mon, 07 Jan 2008 17:15:56 EST." <50e8f1110801071415o5fab45f3sfb555c56b223dc32@mail.gmail.com> Message-ID: <59248.1199838335@tigger.icir.org> Hi, I tried your config and it worked fine for me. interfaces { interface fxp0 { description: "fxp0" vif fxp0 { address 5.8.27.2 { prefix-length: 24 } address 8.65.1.10 { prefix-length: 32 } } } } Xorp> show ospf4 database OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *5.8.27.2 5.8.27.2 0x80000001 189 0x2 0x23b0 36 ASExt-2 *5.8.27.0 5.8.27.2 0x80000001 189 0x2 0xf362 36 ASExt-2 *8.65.1.10 5.8.27.2 0x80000001 189 0x2 0xc48f 36 I am using the latest code from CVS and I explictly configured the second address in the interface block. Atanu. >>>>> "Donghai" == Donghai Ma writes: Donghai> Hello List, Donghai> I am new to XORP and having difficulties to get XORP to distribute Donghai> connected routes into OSPF. For example, after I add an address to Donghai> eth1: Donghai> $ ip addr add 8.65.1.10/32 dev eth1 Donghai> I'd like the connected route 8.65.1.10/32 be distributed by the OSPF Donghai> process. Donghai> After reading through the XORP manual I have the latest 1.4 release Donghai> running on my Linux box. The OSPF process is receiving routes Donghai> correctly from the upstream router. But the route export/distribution Donghai> does not work as I had hoped. When I add or delete ip addresses the Donghai> XORP process does not do OSPF LS Update. Donghai> My question is: does XORP currently support this kind of route Donghai> distribution? And if yes how to make this work? Donghai> Any help is very much appreciated! Donghai> Thanks, Donghai> -Donghai Ma Donghai> PS. Donghai> Here is my configuration: Donghai> -------------------------------------------- xorp config file starts Donghai> -------------------------------------------- Donghai> /* $XORP: xorp/rtrmgr/config.boot 1.46 2007/03/12 10:16:05 atanu Exp $ Donghai> */ Donghai> interfaces { Donghai> restore-original-config-on-shutdown: false Donghai> interface eth1 { Donghai> description: "eth1" Donghai> disable: false Donghai> /* default-system-config */ Donghai> vif eth1 { Donghai> disable: false Donghai> address 5.8.27.2 { Donghai> prefix-length: 24 Donghai> broadcast: 5.8.27.255 Donghai> disable: false Donghai> } Donghai> } Donghai> } Donghai> } Donghai> fea { Donghai> unicast-forwarding4 { Donghai> disable: false Donghai> forwarding-entries { Donghai> retain-on-startup: false Donghai> retain-on-shutdown: false Donghai> } Donghai> } Donghai> } Donghai> policy { Donghai> /* Describe connected routes for redistribution */ Donghai> policy-statement POLICY_CONNECTED { Donghai> term 1 { Donghai> from { Donghai> protocol: "connected" Donghai> } Donghai> then { Donghai> trace 3 Donghai> accept Donghai> } Donghai> } Donghai> } Donghai> } Donghai> protocols { Donghai> ospf4 { Donghai> router-id: 5.8.27.2 Donghai> area 0.0.0.0 { Donghai> area-type: "normal" Donghai> interface eth1 { Donghai> /* link-type: "broadcast" */ Donghai> vif eth1 { Donghai> address 5.8.27.2 { Donghai> } Donghai> } Donghai> } Donghai> } Donghai> export: "POLICY_CONNECTED" Donghai> } Donghai> } Donghai> -------------------------------------------- xorp config file ends Donghai> -------------------------------------------- Donghai> _______________________________________________ Donghai> Xorp-users mailing list Donghai> Xorp-users at xorp.org Donghai> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bbb999 at zerodistance.fi Wed Jan 9 06:32:20 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Wed, 9 Jan 2008 16:32:20 +0200 Subject: [Xorp-users] xorpsh load command Message-ID: <20080109143220.GA19600@zerodistance.fi> Xorpsh load command does not seem to work in all situations. If I start XORP with xorp1.conf shown below, and then try to load xorp2.conf by using the load command in xorpsh, the following error message is shown: [ 2008/01/09 12:05:14 WARNING xorp_policy:5327 XrlPolicyTarget +360 policy_base.cc handle_policy_0_1_delete_policy ] Handling method for policy/0.1/delete_policy failed: XrlCmdError 102 Command failed delete_policy: DependancyError from line 154 of dependancy.hh: Dependency remove: Object test in use by: bgp [ 2008/01/09 12:05:14 ERROR xorp_rtrmgr:5324 RTRMGR +675 master_conf_tree. cc commit_pass2_done ] Commit failed: 102 Command failed delete_policy: DependancyError from line 154 of dependancy.hh: Dependency remove: Object test in use by: bgp ERROR: Load failed. 102 Command failed delete_policy: DependancyError from line 154 of dependancy.hh: Dependency remove: Object test in use by: bgp [edit] If I start XORP with xorp2.conf as parameter, and then load xorp1.conf by using xorpsh, it works OK. Is there a way to change from xorp1.conf to xorp2.conf without restarting XORP? Even some kind of workaround would be OK. I am using Linux, XORP 1.4. Regards, Arsi -- xorp1.conf --- interfaces { restore-original-config-on-shutdown: false interface eth1 { default-system-config } } policy { policy-statement test { term a { from { protocol: "bgp" } then { accept } } } } protocols { bgp { export: "test" bgp-id: 10.1.0.1 local-as: 1 peer 10.1.0.2 { local-ip: 10.1.0.1 as: 110 next-hop: 10.1.0.1 } } } --- xorp2.conf --- interfaces { restore-original-config-on-shutdown: false interface eth1 { default-system-config } } protocols { bgp { bgp-id: 10.1.0.1 local-as: 1 peer 10.1.0.2 { local-ip: 10.1.0.1 as: 110 next-hop: 10.1.0.1 } } } From pavlin at icir.org Wed Jan 9 06:53:27 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 Jan 2008 06:53:27 -0800 Subject: [Xorp-users] xorpsh load command In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Wed, 09 Jan 2008 16:32:20 +0200." <20080109143220.GA19600@zerodistance.fi> Message-ID: <200801091453.m09ErRWM048540@possum.icir.org> Arsi Antila wrote: > Xorpsh load command does not seem to work in all situations. > > If I start XORP with xorp1.conf shown below, and then try to load > xorp2.conf by using the load command in xorpsh, the following error > message is shown: > > [ 2008/01/09 12:05:14 WARNING xorp_policy:5327 XrlPolicyTarget +360 > policy_base.cc handle_policy_0_1_delete_policy ] Handling method for > policy/0.1/delete_policy failed: XrlCmdError 102 Command failed delete_policy: > DependancyError from line 154 of dependancy.hh: Dependency remove: Object test > in use by: bgp > [ 2008/01/09 12:05:14 ERROR xorp_rtrmgr:5324 RTRMGR +675 > master_conf_tree. > cc commit_pass2_done ] Commit failed: 102 Command failed delete_policy: > DependancyError from line 154 of dependancy.hh: Dependency remove: Object > test in use by: bgp > ERROR: Load failed. > 102 Command failed delete_policy: DependancyError from line 154 of > dependancy.hh: Dependency remove: Object test in use by: bgp [edit] > > > If I start XORP with xorp2.conf as parameter, and then load > xorp1.conf by using xorpsh, it works OK. > > Is there a way to change from xorp1.conf to xorp2.conf without > restarting XORP? Even some kind of workaround would be OK. I am using > Linux, XORP 1.4. The problem is that in xorp1.conf inside the "bgp" config there is [export: "test"] statement. During the loading of xorp2.conf, the first processed configuration delta is the deletion of the policy statement, but from policy manager perspective it is still in use by BGP, hence the above error. The work-around would be to delete first [export: "test"] inside bgp, commit the change, and then load xorp2.conf. Regards, Pavlin > > Regards, > Arsi > > > > -- xorp1.conf --- > > interfaces { > restore-original-config-on-shutdown: false > interface eth1 { > default-system-config > } > } > > policy { > policy-statement test { > term a { > from { > protocol: "bgp" > } > then { > accept > } > } > } > } > > protocols { > bgp { > export: "test" > bgp-id: 10.1.0.1 > local-as: 1 > peer 10.1.0.2 { > local-ip: 10.1.0.1 > as: 110 > next-hop: 10.1.0.1 > } > } > } > > --- xorp2.conf --- > > interfaces { > restore-original-config-on-shutdown: false > interface eth1 { > default-system-config > } > } > > protocols { > bgp { > bgp-id: 10.1.0.1 > local-as: 1 > peer 10.1.0.2 { > local-ip: 10.1.0.1 > as: 110 > next-hop: 10.1.0.1 > } > } > } > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bbb999 at zerodistance.fi Wed Jan 9 09:09:16 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Wed, 9 Jan 2008 19:09:16 +0200 Subject: [Xorp-users] xorpsh load command In-Reply-To: <200801091453.m09ErRWM048540@possum.icir.org> References: <20080109143220.GA19600@zerodistance.fi> <200801091453.m09ErRWM048540@possum.icir.org> Message-ID: <20080109170916.GA31624@zerodistance.fi> On Wed, Jan 09, 2008 at 06:53:27AM -0800, Pavlin Radoslavov wrote: > Arsi Antila wrote: > > > Xorpsh load command does not seem to work in all situations. > > > > If I start XORP with xorp1.conf shown below, and then try to load > > xorp2.conf by using the load command in xorpsh, the following error > > message is shown: > > > > [ 2008/01/09 12:05:14 WARNING xorp_policy:5327 XrlPolicyTarget +360 > > policy_base.cc handle_policy_0_1_delete_policy ] Handling method for > > policy/0.1/delete_policy failed: XrlCmdError 102 Command failed delete_policy: > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object test > > in use by: bgp > > [ 2008/01/09 12:05:14 ERROR xorp_rtrmgr:5324 RTRMGR +675 > > master_conf_tree. > > cc commit_pass2_done ] Commit failed: 102 Command failed delete_policy: > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object > > test in use by: bgp > > ERROR: Load failed. > > 102 Command failed delete_policy: DependancyError from line 154 of > > dependancy.hh: Dependency remove: Object test in use by: bgp [edit] > > > > > > If I start XORP with xorp2.conf as parameter, and then load > > xorp1.conf by using xorpsh, it works OK. > > > > Is there a way to change from xorp1.conf to xorp2.conf without > > restarting XORP? Even some kind of workaround would be OK. I am using > > Linux, XORP 1.4. > > The problem is that in xorp1.conf inside the "bgp" config there > is [export: "test"] statement. During the loading of xorp2.conf, the > first processed configuration delta is the deletion of the policy > statement, but from policy manager perspective it is still in use by > BGP, hence the above error. > > The work-around would be to delete first [export: "test"] inside > bgp, commit the change, and then load xorp2.conf. > Would that be a generic solution to the problem of changing from arbitrary configuration A to configuration B at run time? If I have a script which first deletes all policies, and then issues a load command, is there something that would prevent it from working in all situations? If both configurations A and B had restrictive policies, it would seem that there would be no policy rules in use for a few seconds during the transformation from A to B. Regards, Arsi From pavlin at icir.org Wed Jan 9 11:05:27 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 09 Jan 2008 11:05:27 -0800 Subject: [Xorp-users] xorpsh load command In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Wed, 09 Jan 2008 19:09:16 +0200." <20080109170916.GA31624@zerodistance.fi> Message-ID: <200801091905.m09J5RJ4050339@possum.icir.org> Arsi Antila wrote: > On Wed, Jan 09, 2008 at 06:53:27AM -0800, Pavlin Radoslavov wrote: > > Arsi Antila wrote: > > > > > Xorpsh load command does not seem to work in all situations. > > > > > > If I start XORP with xorp1.conf shown below, and then try to load > > > xorp2.conf by using the load command in xorpsh, the following error > > > message is shown: > > > > > > [ 2008/01/09 12:05:14 WARNING xorp_policy:5327 XrlPolicyTarget +360 > > > policy_base.cc handle_policy_0_1_delete_policy ] Handling method for > > > policy/0.1/delete_policy failed: XrlCmdError 102 Command failed delete_policy: > > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object test > > > in use by: bgp > > > [ 2008/01/09 12:05:14 ERROR xorp_rtrmgr:5324 RTRMGR +675 > > > master_conf_tree. > > > cc commit_pass2_done ] Commit failed: 102 Command failed delete_policy: > > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object > > > test in use by: bgp > > > ERROR: Load failed. > > > 102 Command failed delete_policy: DependancyError from line 154 of > > > dependancy.hh: Dependency remove: Object test in use by: bgp [edit] > > > > > > > > > If I start XORP with xorp2.conf as parameter, and then load > > > xorp1.conf by using xorpsh, it works OK. > > > > > > Is there a way to change from xorp1.conf to xorp2.conf without > > > restarting XORP? Even some kind of workaround would be OK. I am using > > > Linux, XORP 1.4. > > > > The problem is that in xorp1.conf inside the "bgp" config there > > is [export: "test"] statement. During the loading of xorp2.conf, the > > first processed configuration delta is the deletion of the policy > > statement, but from policy manager perspective it is still in use by > > BGP, hence the above error. > > > > The work-around would be to delete first [export: "test"] inside > > bgp, commit the change, and then load xorp2.conf. > > > > Would that be a generic solution to the problem of changing from > arbitrary configuration A to configuration B at run time? If I have a > script which first deletes all policies, and then issues a load command, > is there something that would prevent it from working in all situations? > If both configurations A and B had restrictive policies, it would seem > that there would be no policy rules in use for a few seconds during the > transformation from A to B. The issue I described applies to all cases if the to-be-deleted policies are referred by other part of the current configuration (which typically is being exported or imported by some protocol). In all such cases you have to apply the same solution: delete first the export/import policy statement in the protocols, commit, and then delete the previously used policy (or load new configuration). Adding new policies or deleting policies that are not exported/imported shouldn't trigger this issue. FYI, loading new configuration is basically performing delta between the two configurations, and then deleting/adding the deltas. Regards, Pavlin From yueli.m at gmail.com Wed Jan 9 11:27:52 2008 From: yueli.m at gmail.com (Yue Li) Date: Wed, 9 Jan 2008 14:27:52 -0500 Subject: [Xorp-users] [xorp-users] OSPFv2 problem: no matching neighbor found In-Reply-To: <48018.1199835462@tigger.icir.org> References: <49567c360801052254k77f150ebp23a1c978bd1b697b@mail.gmail.com> <48018.1199835462@tigger.icir.org> Message-ID: <49567c360801091127w3432b46bted0edff0518819ca@mail.gmail.com> Hi, Atanu I have figured it out. Thank you very much. 2008/1/8, Atanu Ghosh : > Hi, > > In OSPF some packets such as the hello packets are multicast and other > packets such as the data description packets are unicast. The source > address in a packet is used to demultiplex a packet and associate it > with a neighbour. I notice from the output of "show ospf4 neighbour" > that you seem to be using tunnels. What may be happening is that the > hello packets that are multicast are being received with the orignal > source address provided by OSPF, the source address of unicast packets > may be changed by the tunnel, which could explain why they are not > recognised. > > Try running tcpdump on router A and check the source addresses of > received packets. > > Atanu. > > >>>>> "Yue" == Yue Li writes: > > Yue> ---------- Forwarded message ---------- > Yue> From: Yue Li > Yue> Date: 2008-1-6 ????1:51 > Yue> Subject: Re: [Xorp-users] [xorp-users] OSPFv2 problem: no matching > Yue> neighbor found > Yue> To: atanu at icsi.berkeley.edu > > > Yue> Hi, > Yue> Thanks for your reply. > Yue> The topology used is as follow: > > Yue> +---+ (10.10.0.9) (10.10.0.10)+---+ > Yue> | A |----------------------------------------- | B | > Yue> +---+ +---+ > Yue> |(10.10.0.1) | (10.10.0.6) > Yue> | | > Yue> | | (10.10.0.5) > Yue> | (10.10.0.2) +----+ > Yue> - --------------------------------------------| C | > Yue> +----+ > > Yue> Router A (id: 10.10.0.1), Router B (id: 10.10.0.10) and Router C (id: > Yue> 10.10.0.5), > Yue> each has two neighbors. > > Yue> On Router A: > Yue> show ospf4 neighbor: > Yue> Address Interface State ID Pri Dead > Yue> 10.10.0.2 tun0/tun0 ExStart 10.10.0.5 128 31 > Yue> 10.10.0.10 tun1/tun1 ExStart 10.10.0.10 128 33 > > Yue> show ospf4 database: > Yue> OSPF link state database, Area 0.0.0.0 > Yue> Type ID Adv Rtr Seq Age Opt Cksum Len > Yue> Router *10.10.0.1 10.10.0.1 0x80000001 78 0x2 0xad78 48 > > > Yue> 2008/1/4, Atanu Ghosh : > >> Hi, > >> > >> The XORP OSPF will not accept data description packets from an unknown > >> neighbour (this is a protocol requirement). > >> > >> Can you send the output of the "show ospf4 neighbor" command? > >> > >> Atanu. > >> . > >> >>>>> "Yue" == Yue Li writes: > >> > Yue> Hi, everyone I am doing some experiment with ospfv2. The > Yue> problem is xorp is keep saying "no matching neighbor found" > Yue> when receiving database description packets. When I show ospf > Yue> database through xorpsh, there is nothing. > >> > Yue> Can you give me any clues? Thanks! > >> > Yue> _______________________________________________ Xorp-users > Yue> mailing list Xorp-users at xorp.org > Yue> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> > > From bbb999 at zerodistance.fi Thu Jan 10 03:43:08 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Thu, 10 Jan 2008 13:43:08 +0200 Subject: [Xorp-users] OSPF neighbor death Message-ID: <20080110114308.GA20767@zerodistance.fi> When OSPF p2p neighbor dies, the routes advertised by that neighbor are not deleted. Is this correct? In broadcast mode the routes for a dead neighbor are deleted. The sequence of steps is shown below. Network 192.10.0.0/24 is advertised by the OSPF neighbor. In broadcast mode this network is not shown with 'show route table ipv4 unicast final' after the neighbor has died. -- Start both routers -- root at sisa1a> show ospf4 neighbor Address Interface State ID Pri Dead 10.1.0.1 eth0/eth0 Full 10.1.0.1 128 38 root at sisa1a> show route table ipv4 unicast final 10.1.0.0/24 [connected(0)/0] > via eth0/eth0 192.10.0.0/24 [ospf(110)/2] > to 10.1.0.1 via eth0/eth0 -- Neighbor dies -- root at sisa1a> show ospf4 neighbor Address Interface State ID Pri Dead 10.1.0.1 eth0/eth0 Down 10.1.0.1 0 0 root at sisa1a> show route table ipv4 unicast final 10.1.0.0/24 [connected(0)/0] > via eth0/eth0 192.10.0.0/24 [ospf(110)/2] > to 10.1.0.1 via eth0/eth0 ------------------------------------------ interfaces { restore-original-config-on-shutdown: false interface eth0 { default-system-config } } protocols { ospf4 { router-id: 10.1.0.2 area 0.0.0.0 { interface eth0 { link-type: "p2p" vif eth0 { address 10.1.0.2 { router-dead-interval: 40 neighbor 10.1.0.1 { router-id: 10.1.0.1 } } } } } } } From atanu at ICSI.Berkeley.EDU Thu Jan 10 11:45:11 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 10 Jan 2008 11:45:11 -0800 Subject: [Xorp-users] OSPF neighbor death In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Thu, 10 Jan 2008 13:43:08 +0200." <20080110114308.GA20767@zerodistance.fi> Message-ID: <81831.1199994311@tigger.icir.org> Hi, This problem is fixed in CVS but is not in the latest release. Atanu. >>>>> "Arsi" == Arsi Antila writes: Arsi> When OSPF p2p neighbor dies, the routes advertised by that Arsi> neighbor are not deleted. Is this correct? In broadcast mode Arsi> the routes for a dead neighbor are deleted. Arsi> The sequence of steps is shown below. Network 192.10.0.0/24 is Arsi> advertised by the OSPF neighbor. In broadcast mode this Arsi> network is not shown with 'show route table ipv4 unicast Arsi> final' after the neighbor has died. Arsi> -- Start both routers -- Arsi> root at sisa1a> show ospf4 neighbor Address Interface State ID Arsi> Pri Dead 10.1.0.1 eth0/eth0 Full 10.1.0.1 128 38 Arsi> root at sisa1a> show route table ipv4 unicast final 10.1.0.0/24 Arsi> [connected(0)/0] >> via eth0/eth0 Arsi> 192.10.0.0/24 [ospf(110)/2] >> to 10.1.0.1 via eth0/eth0 Arsi> -- Neighbor dies -- Arsi> root at sisa1a> show ospf4 neighbor Address Interface State ID Arsi> Pri Dead 10.1.0.1 eth0/eth0 Down 10.1.0.1 0 0 Arsi> root at sisa1a> show route table ipv4 unicast final 10.1.0.0/24 Arsi> [connected(0)/0] >> via eth0/eth0 Arsi> 192.10.0.0/24 [ospf(110)/2] >> to 10.1.0.1 via eth0/eth0 Arsi> ------------------------------------------ Arsi> interfaces { restore-original-config-on-shutdown: false Arsi> interface eth0 { default-system-config } } Arsi> protocols { ospf4 { router-id: 10.1.0.2 Arsi> area 0.0.0.0 { interface eth0 { link-type: "p2p" vif eth0 Arsi> { address 10.1.0.2 { router-dead-interval: 40 neighbor Arsi> 10.1.0.1 { router-id: 10.1.0.1 } } } } } } } Arsi> _______________________________________________ Xorp-users Arsi> mailing list Xorp-users at xorp.org Arsi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From johansson500 at gmail.com Sat Jan 12 03:46:29 2008 From: johansson500 at gmail.com (Mikael Johansson) Date: Sat, 12 Jan 2008 13:46:29 +0200 Subject: [Xorp-users] XORP versions Message-ID: We are evaluating using XORP in a network of about 500 routers, some of which would be XORP routers. There have been some concerns about stability in our organization. Our internal testing has noticed that XORP routing processes sometimes die in situations where processor load is high. Is there something that could be done to increase stability, except to make sure that routing processes get enough processor time? Should we use the latest XORP release 1.4, or the most recent CVS version? When is XORP-1.5 being released? We are using multicasting, OSPF and BGP. With regards to features, the most critical is the lack of virtualization, because we need to run two or more OSPF processes which are completely isolated from each other. This can probably be implemented in Linux using Xen. Have there been efforts to get XORP running in a virtualized environment? Best regards, Mikael From greearb at candelatech.com Sat Jan 12 12:14:32 2008 From: greearb at candelatech.com (Ben Greear) Date: Sat, 12 Jan 2008 12:14:32 -0800 Subject: [Xorp-users] XORP versions In-Reply-To: References: Message-ID: <47891FA8.4010300@candelatech.com> Mikael Johansson wrote: > We are evaluating using XORP in a network of about 500 routers, some > of which would be XORP routers. There have been some concerns about > stability in our organization. Our internal testing has noticed that > XORP routing processes sometimes die in situations > where processor load is high. Is there something that could be done to > increase stability, except to make sure that routing processes get > enough processor time? Should we use the latest XORP release 1.4, or > the most recent CVS version? When is XORP-1.5 being released? We are > using multicasting, OSPF and BGP. > Send details on the crashes (stack-traces from gdb, etc). Use the most recent cvs, it fixes a lot of bugs, and at least on Linux, you can run multiple xorp instances virtualized using unique routing tables. No patches or xen like things are needed if you have a modern OS (Fedora 8, for instance). We have run at least 20 instances, for example. > With regards to features, the most critical is the lack of > virtualization, because we need to run two or more OSPF processes > which are completely isolated from each other. This can probably be > implemented in Linux using Xen. Have there been efforts to get XORP > running in a virtualized environment? > Search back through the archives for my name and answers to my many questions. :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From tuan.hoang at agilecommunications.com Wed Jan 9 09:45:09 2008 From: tuan.hoang at agilecommunications.com (Tuan Hoang) Date: Wed, 9 Jan 2008 12:45:09 -0500 Subject: [Xorp-users] static qualified next-hop-router problem Message-ID: <156C21096797BC4D948462D8C7ED8918363694@agiledc1.agilecommunications.com> Hi, I'm using a XORP 1.4 under CentOS 4.5. I have a router connected to two ISP's and want to detect when my primary gateway is down on eth1 (Note: ethernet link is still up but gateway is unreachable) and then switch over my default route to my other ISP's gateway on eth2. I have the static route configured with the a simple next-hop-router to eth1 with ISP1's GW and also a qualified next-hop-router to eth2 with ISP2's GW. When I turn off my cable modem to ISP1, XORP does not change my default route's GW to ISP2's GW on eth2. The only way I've gotten this to work is by removing the eth1 ethernet cable to cause the interface flags to change. FWIW, I've made sure that the ARP cache is flushed for the ISP1 GW. Thanks, Tuan P.S. Please reply all since I am not subscribing to the list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080109/d769c625/attachment.html From a.greenhalgh at cs.ucl.ac.uk Sun Jan 13 10:37:37 2008 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Sun, 13 Jan 2008 18:37:37 +0000 Subject: [Xorp-users] static qualified next-hop-router problem In-Reply-To: <156C21096797BC4D948462D8C7ED8918363694@agiledc1.agilecommunications.com> References: <156C21096797BC4D948462D8C7ED8918363694@agiledc1.agilecommunications.com> Message-ID: <4769af410801131037k84c065bxd518e613956a5d00@mail.gmail.com> Tuan, You didn't say whether you were running any routing protocols. Adam On 09/01/2008, Tuan Hoang wrote: > > > > Hi, > > I'm using a XORP 1.4 under CentOS 4.5. I have a router connected to two > ISP's and want to detect when my primary gateway is down on eth1 (Note: > ethernet link is still up but gateway is unreachable) and then switch over > my default route to my other ISP's gateway on eth2. > > I have the static route configured with the a simple next-hop-router to eth1 > with ISP1's GW and also a qualified next-hop-router to eth2 with ISP2's GW. > When I turn off my cable modem to ISP1, XORP does not change my default > route's GW to ISP2's GW on eth2. The only way I've gotten this to work is > by removing the eth1 ethernet cable to cause the interface flags to change. > > FWIW, I've made sure that the ARP cache is flushed for the ISP1 GW. > > Thanks, > Tuan > > P.S. Please reply all since I am not subscribing to the list. > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From pavlin at icir.org Sun Jan 13 21:22:18 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 13 Jan 2008 21:22:18 -0800 Subject: [Xorp-users] XORP versions In-Reply-To: Message from Ben Greear of "Sat, 12 Jan 2008 12:14:32 PST." <47891FA8.4010300@candelatech.com> Message-ID: <200801140522.m0E5MIpd026271@possum.icir.org> Ben Greear wrote: > Mikael Johansson wrote: > > We are evaluating using XORP in a network of about 500 routers, some > > of which would be XORP routers. There have been some concerns about > > stability in our organization. Our internal testing has noticed that > > XORP routing processes sometimes die in situations > > where processor load is high. Is there something that could be done to > > increase stability, except to make sure that routing processes get > > enough processor time? Should we use the latest XORP release 1.4, or > > the most recent CVS version? When is XORP-1.5 being released? We are > > using multicasting, OSPF and BGP. > > > Send details on the crashes (stack-traces from gdb, etc). Use the most > recent cvs, it > fixes a lot of bugs, and at least on Linux, you can run multiple xorp > instances virtualized > using unique routing tables. No patches or xen like things are needed > if you have a > modern OS (Fedora 8, for instance). > > We have run at least 20 instances, for example. > > With regards to features, the most critical is the lack of > > virtualization, because we need to run two or more OSPF processes > > which are completely isolated from each other. This can probably be > > implemented in Linux using Xen. Have there been efforts to get XORP > > running in a virtualized environment? > > > Search back through the archives for my name and answers to my many > questions. :) In the context of virtualization, you can run multiple XORP instances, but only for unicast protocols (BGP probably excluded due to some short-term reasons), and only on Linux which supports multiple unicast forwarding tables. You can't run do this for multicast. One of the reasons is that the UNIX kernel allows only a single instance of the special multicast routing socket. If you want to run multiple XORP instances, please drop us an email, so we can give you the technical details (they are not in the in the user documentation yet). If you use XORP on top of Xen or Vmware, then you are practically running multiple OS instances, so the above limitations don't apply. An alternative solution is to use IMUNES: http://www.imunes.net/ http://www.tel.fer.hr/imunes/ It virtualizes the kernel networking stack itself and is extremely lightweight. It also has a very cool GUI which gives you lots of control over the virtual topology management. It is available for FreeBSD, so if you don't have OS requirements I'd strongly recommend considering it. Marko Zec (who wrote IMUNES) is on this mailing list and can give you more information about it. Regards, Pavlin From pavlin at icir.org Sun Jan 13 21:35:32 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 13 Jan 2008 21:35:32 -0800 Subject: [Xorp-users] static qualified next-hop-router problem In-Reply-To: Message from "Adam Greenhalgh" of "Sun, 13 Jan 2008 18:37:37 GMT." <4769af410801131037k84c065bxd518e613956a5d00@mail.gmail.com> Message-ID: <200801140535.m0E5ZWCA026367@possum.icir.org> Adam Greenhalgh wrote: > Tuan, > > You didn't say whether you were running any routing protocols. > > Adam My interpretation of Tuan's email is that the used protocol is "static routes". The obvious solution would be to use a dynamic protocol like RIP or OSPF. Though, if your ISPs don't let you run any, then this is not an option for you. The StaticRoutes solution can't track the status of remote gateways on its own; this is why there are dynamic protocols. One possible work-around hack is to use an external script that helps StaticRoutes tracking the status of the gateways. The script will run a periodic ping to the primary gateway. If the ping fails, then the script will use xorpsh to reconfigure XORP by changing the next-hop address to the secondary gateway. Hope that helps, Pavlin > On 09/01/2008, Tuan Hoang wrote: > > > > > > > > Hi, > > > > I'm using a XORP 1.4 under CentOS 4.5. I have a router connected to two > > ISP's and want to detect when my primary gateway is down on eth1 (Note: > > ethernet link is still up but gateway is unreachable) and then switch over > > my default route to my other ISP's gateway on eth2. > > > > I have the static route configured with the a simple next-hop-router to eth1 > > with ISP1's GW and also a qualified next-hop-router to eth2 with ISP2's GW. > > When I turn off my cable modem to ISP1, XORP does not change my default > > route's GW to ISP2's GW on eth2. The only way I've gotten this to work is > > by removing the eth1 ethernet cable to cause the interface flags to change. > > > > FWIW, I've made sure that the ARP cache is flushed for the ISP1 GW. > > > > Thanks, > > Tuan > > > > P.S. Please reply all since I am not subscribing to the list. > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From johansson500 at gmail.com Mon Jan 14 02:16:21 2008 From: johansson500 at gmail.com (Mikael Johansson) Date: Mon, 14 Jan 2008 12:16:21 +0200 Subject: [Xorp-users] XORP versions In-Reply-To: <200801140522.m0E5MIpd026271@possum.icir.org> References: <47891FA8.4010300@candelatech.com> <200801140522.m0E5MIpd026271@possum.icir.org> Message-ID: > In the context of virtualization, you can run multiple XORP > instances, but only for unicast protocols (BGP probably excluded due > to some short-term reasons), and only on Linux which supports > multiple unicast forwarding tables. > You can't run do this for multicast. One of the reasons is that the > UNIX kernel allows only a single instance of the special multicast > routing socket. We need to do multicast too, so running multiple XORP instances is probably not the solution for us. We don't even necessarily need multiple forwarding tables (although it would be preferable). A kind of a hack which would do almost everything we need would be to somehow be able to control which routes are advertised to which OSPF or BGP neighbor, and there are different configurations. For example if a device has two BGP neighbors and two OSPF neighbors, the routes from one BGP neighbor could be advertised to only one OSPF neighbor. I don't think this is possible in XORP. > If you want to run multiple XORP instances, please drop us an email, > so we can give you the technical details (they are not in the in the > user documentation yet). > > If you use XORP on top of Xen or Vmware, then you are practically > running multiple OS instances, so the above limitations don't > apply. > > An alternative solution is to use IMUNES: > http://www.imunes.net/ > http://www.tel.fer.hr/imunes/ > > It virtualizes the kernel networking stack itself and is extremely > lightweight. It also has a very cool GUI which gives you lots of > control over the virtual topology management. > It is available for FreeBSD, so if you don't have OS requirements > I'd strongly recommend considering it. > Marko Zec (who wrote IMUNES) is on this mailing list and can give > you more information about it. We also need to run another application which is only for Linux, so we can't use FreeBSD. Regards, Mikael From tuan.hoang at agilecommunications.com Mon Jan 14 05:13:11 2008 From: tuan.hoang at agilecommunications.com (Tuan Hoang) Date: Mon, 14 Jan 2008 08:13:11 -0500 Subject: [Xorp-users] static qualified next-hop-router problem In-Reply-To: <200801140535.m0E5ZWCA026367@possum.icir.org> References: Message from "Adam Greenhalgh" of "Sun, 13 Jan 2008 18:37:37 GMT." <4769af410801131037k84c065bxd518e613956a5d00@mail.gmail.com> <200801140535.m0E5ZWCA026367@possum.icir.org> Message-ID: <156C21096797BC4D948462D8C7ED891836390B@agiledc1.agilecommunications.com> Yes, that is correct. This is a very simple network, so the static route (with qualified next-hop-router) was the easiest compared to using either RIP or OSPF. Also as you suspected, my ISP's don't allow routing protocols...for obvious reasons. So the only way for XORP to detect that my ISP gateway is down is if the network interface flags change right (i.e when unplugging the wire or basically breaking the link)? If that is the case, then I'll go with the scripting method. Thanks, Tuan -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at icir.org] Sent: Monday, January 14, 2008 12:36 AM To: Adam Greenhalgh Cc: Tuan Hoang; xorp-users at xorp.org Subject: Re: [Xorp-users] static qualified next-hop-router problem Adam Greenhalgh wrote: > Tuan, > > You didn't say whether you were running any routing protocols. > > Adam My interpretation of Tuan's email is that the used protocol is "static routes". The obvious solution would be to use a dynamic protocol like RIP or OSPF. Though, if your ISPs don't let you run any, then this is not an option for you. The StaticRoutes solution can't track the status of remote gateways on its own; this is why there are dynamic protocols. One possible work-around hack is to use an external script that helps StaticRoutes tracking the status of the gateways. The script will run a periodic ping to the primary gateway. If the ping fails, then the script will use xorpsh to reconfigure XORP by changing the next-hop address to the secondary gateway. Hope that helps, Pavlin > On 09/01/2008, Tuan Hoang wrote: > > > > > > > > Hi, > > > > I'm using a XORP 1.4 under CentOS 4.5. I have a router connected to > > two ISP's and want to detect when my primary gateway is down on eth1 (Note: > > ethernet link is still up but gateway is unreachable) and then > > switch over my default route to my other ISP's gateway on eth2. > > > > I have the static route configured with the a simple next-hop-router > > to eth1 with ISP1's GW and also a qualified next-hop-router to eth2 with ISP2's GW. > > When I turn off my cable modem to ISP1, XORP does not change my > > default route's GW to ISP2's GW on eth2. The only way I've gotten > > this to work is by removing the eth1 ethernet cable to cause the interface flags to change. > > > > FWIW, I've made sure that the ARP cache is flushed for the ISP1 GW. > > > > Thanks, > > Tuan > > > > P.S. Please reply all since I am not subscribing to the list. > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Mon Jan 14 11:33:06 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 14 Jan 2008 11:33:06 -0800 Subject: [Xorp-users] XORP versions In-Reply-To: Message from "Mikael Johansson" of "Mon, 14 Jan 2008 12:16:21 +0200." Message-ID: <200801141933.m0EJX6m6032011@possum.icir.org> Mikael Johansson wrote: > > In the context of virtualization, you can run multiple XORP > > instances, but only for unicast protocols (BGP probably excluded due > > to some short-term reasons), and only on Linux which supports > > multiple unicast forwarding tables. > > You can't run do this for multicast. One of the reasons is that the > > UNIX kernel allows only a single instance of the special multicast > > routing socket. > > We need to do multicast too, so running multiple XORP instances is > probably not the solution for us. > > We don't even necessarily need multiple forwarding tables (although it > would be preferable). A kind of a hack which would do almost > everything we need would be to somehow be able to control which routes > are advertised to which OSPF or BGP neighbor, and there are different > configurations. For example if a device has two BGP neighbors and two > OSPF neighbors, the routes from one BGP neighbor could be advertised > to only one OSPF neighbor. I don't think this is possible in XORP. Currently, the multiple (unicast) forwarding tables is the only way to run multiple XORP instances on the same stack. Otherwise, the result can be unpredictable (e.g., if two XORP instances try to install the same route into the single forwarding table). Regarding the routes advertisement, actually you can achieve a lot with policy statements. They are very flexible and give you lots of control. So you might be able to achieve what you want with some policy configuration. BTW, when you mention advertising BGP routes into OSPF, I hope you are not planning to export full BGP feed (200K+ routes) into OSPF. IGP protocols like OSPF are not designed to carry that amount of load so for that you should use iBGP instead. > > If you want to run multiple XORP instances, please drop us an email, > > so we can give you the technical details (they are not in the in the > > user documentation yet). > > > > If you use XORP on top of Xen or Vmware, then you are practically > > running multiple OS instances, so the above limitations don't > > apply. > > > > An alternative solution is to use IMUNES: > > http://www.imunes.net/ > > http://www.tel.fer.hr/imunes/ > > > > It virtualizes the kernel networking stack itself and is extremely > > lightweight. It also has a very cool GUI which gives you lots of > > control over the virtual topology management. > > It is available for FreeBSD, so if you don't have OS requirements > > I'd strongly recommend considering it. > > Marko Zec (who wrote IMUNES) is on this mailing list and can give > > you more information about it. > > We also need to run another application which is only for Linux, so we > can't use FreeBSD. FYI, FreeBSD has Linux binary compatibility support (e.g., you can run Linux Firefox binary on FreeBSD). Unless your application is doing something Linux-specific, you might actually be able to run the binary on a FreeBSD box. Regards, Pavlin From pavlin at icir.org Mon Jan 14 11:40:42 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 14 Jan 2008 11:40:42 -0800 Subject: [Xorp-users] static qualified next-hop-router problem In-Reply-To: Message from "Tuan Hoang" of "Mon, 14 Jan 2008 08:13:11 EST." <156C21096797BC4D948462D8C7ED891836390B@agiledc1.agilecommunications.com> Message-ID: <200801141940.m0EJegsB032134@possum.icir.org> Tuan Hoang wrote: > Yes, that is correct. This is a very simple network, so the static > route (with qualified next-hop-router) was the easiest compared to using > either RIP or OSPF. Also as you suspected, my ISP's don't allow routing > protocols...for obvious reasons. > > So the only way for XORP to detect that my ISP gateway is down is if the > network interface flags change right (i.e when unplugging the wire or > basically breaking the link)? If that is the case, then I'll go with > the scripting method. Correct. StaticRoutes can detect only changes to the interface flags (including the unplugging of the cable) which is a local event. Please keep us informed how it goes with the scripting method. Regards, Pavlin > Thanks, > Tuan > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at icir.org] > Sent: Monday, January 14, 2008 12:36 AM > To: Adam Greenhalgh > Cc: Tuan Hoang; xorp-users at xorp.org > Subject: Re: [Xorp-users] static qualified next-hop-router problem > > Adam Greenhalgh wrote: > > > Tuan, > > > > You didn't say whether you were running any routing protocols. > > > > Adam > > My interpretation of Tuan's email is that the used protocol is "static > routes". > > The obvious solution would be to use a dynamic protocol like RIP or > OSPF. Though, if your ISPs don't let you run any, then this is not an > option for you. > > The StaticRoutes solution can't track the status of remote gateways on > its own; this is why there are dynamic protocols. > > One possible work-around hack is to use an external script that helps > StaticRoutes tracking the status of the gateways. > > The script will run a periodic ping to the primary gateway. If the ping > fails, then the script will use xorpsh to reconfigure XORP by changing > the next-hop address to the secondary gateway. > > Hope that helps, > Pavlin > > > On 09/01/2008, Tuan Hoang wrote: > > > > > > > > > > > > Hi, > > > > > > I'm using a XORP 1.4 under CentOS 4.5. I have a router connected to > > > > two ISP's and want to detect when my primary gateway is down on eth1 > (Note: > > > ethernet link is still up but gateway is unreachable) and then > > > switch over my default route to my other ISP's gateway on eth2. > > > > > > I have the static route configured with the a simple next-hop-router > > > > to eth1 with ISP1's GW and also a qualified next-hop-router to eth2 > with ISP2's GW. > > > When I turn off my cable modem to ISP1, XORP does not change my > > > default route's GW to ISP2's GW on eth2. The only way I've gotten > > > this to work is by removing the eth1 ethernet cable to cause the > interface flags to change. > > > > > > FWIW, I've made sure that the ARP cache is flushed for the ISP1 GW. > > > > > > Thanks, > > > Tuan > > > > > > P.S. Please reply all since I am not subscribing to the list. > > > _______________________________________________ > > > Xorp-users mailing list > > > Xorp-users at xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Mon Jan 14 13:03:48 2008 From: greearb at candelatech.com (Ben Greear) Date: Mon, 14 Jan 2008 13:03:48 -0800 Subject: [Xorp-users] Question on OSPF route failover. Message-ID: <478BCE34.6020109@candelatech.com> Suppose there are two paths between two XORP OSPF routers. One is high cost, the other low cost and preferred if it is up. The high-cost link is assumed to be always up in this scenario. When xorp first starts, and both links are up, it chooses the low cost link. When the low cost link dies, it chooses the high-cost link. But, when the low-cost link comes back, it doesn't seem to change back to using it. Is this expected behaviour? Is there any way to make sure it uses the low-cost link whenever it's up? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From johansson500 at gmail.com Tue Jan 15 02:03:28 2008 From: johansson500 at gmail.com (Mikael Johansson) Date: Tue, 15 Jan 2008 12:03:28 +0200 Subject: [Xorp-users] XORP versions In-Reply-To: <200801141933.m0EJX6m6032011@possum.icir.org> References: <200801141933.m0EJX6m6032011@possum.icir.org> Message-ID: On Jan 14, 2008 9:33 PM, Pavlin Radoslavov wrote: > Mikael Johansson wrote: > > > > In the context of virtualization, you can run multiple XORP > > > instances, but only for unicast protocols (BGP probably excluded due > > > to some short-term reasons), and only on Linux which supports > > > multiple unicast forwarding tables. > > > You can't run do this for multicast. One of the reasons is that the > > > UNIX kernel allows only a single instance of the special multicast > > > routing socket. > > > > We need to do multicast too, so running multiple XORP instances is > > probably not the solution for us. > > > > We don't even necessarily need multiple forwarding tables (although it > > would be preferable). A kind of a hack which would do almost > > everything we need would be to somehow be able to control which routes > > are advertised to which OSPF or BGP neighbor, and there are different > > configurations. For example if a device has two BGP neighbors and two > > OSPF neighbors, the routes from one BGP neighbor could be advertised > > to only one OSPF neighbor. I don't think this is possible in XORP. > > Currently, the multiple (unicast) forwarding tables is the only way > to run multiple XORP instances on the same stack. Otherwise, the > result can be unpredictable (e.g., if two XORP instances try to > install the same route into the single forwarding table). > > Regarding the routes advertisement, actually you can achieve a lot > with policy statements. They are very flexible and give you lots of > control. So you might be able to achieve what you want with some > policy configuration. Yes, we can achieve almost everything we need by using BGP policy rules, but not when OSPF is used. Another example of the kind of things we need to do is to disable advertising between two OSPF interfaces. I don't think this is possible in XORP, at least not in all cases (AS-external routes, or OSPF interfaces belonging to the same area). > BTW, when you mention advertising BGP routes into OSPF, I hope you > are not planning to export full BGP feed (200K+ routes) into OSPF. > IGP protocols like OSPF are not designed to carry that amount of > load so for that you should use iBGP instead. There is no need to process that many routes (the design of the network is quite unusual). > > > If you want to run multiple XORP instances, please drop us an email, > > > so we can give you the technical details (they are not in the in the > > > user documentation yet). > > > > > > If you use XORP on top of Xen or Vmware, then you are practically > > > running multiple OS instances, so the above limitations don't > > > apply. > > > > > > An alternative solution is to use IMUNES: > > > http://www.imunes.net/ > > > http://www.tel.fer.hr/imunes/ > > > > > > It virtualizes the kernel networking stack itself and is extremely > > > lightweight. It also has a very cool GUI which gives you lots of > > > control over the virtual topology management. > > > It is available for FreeBSD, so if you don't have OS requirements > > > I'd strongly recommend considering it. > > > Marko Zec (who wrote IMUNES) is on this mailing list and can give > > > you more information about it. > > > > We also need to run another application which is only for Linux, so we > > can't use FreeBSD. > > FYI, FreeBSD has Linux binary compatibility support (e.g., you can > run Linux Firefox binary on FreeBSD). Unless your application is > doing something Linux-specific, you might actually be able to run > the binary on a FreeBSD box. > It is Linux-specific, the main part is a Linux kernel module. There are also other reasons that force us to use Linux. Regards, Mikael From johansson500 at gmail.com Tue Jan 15 02:17:14 2008 From: johansson500 at gmail.com (Mikael Johansson) Date: Tue, 15 Jan 2008 12:17:14 +0200 Subject: [Xorp-users] XORP versions In-Reply-To: <47891FA8.4010300@candelatech.com> References: <47891FA8.4010300@candelatech.com> Message-ID: On Jan 12, 2008 10:14 PM, Ben Greear wrote: > Mikael Johansson wrote: > > We are evaluating using XORP in a network of about 500 routers, some > > of which would be XORP routers. There have been some concerns about > > stability in our organization. Our internal testing has noticed that > > XORP routing processes sometimes die in situations > > where processor load is high. Is there something that could be done to > > increase stability, except to make sure that routing processes get > > enough processor time? Should we use the latest XORP release 1.4, or > > the most recent CVS version? When is XORP-1.5 being released? We are > > using multicasting, OSPF and BGP. > > > Send details on the crashes (stack-traces from gdb, etc). Use the most > recent cvs, it > fixes a lot of bugs, and at least on Linux, you can run multiple xorp > instances virtualized > using unique routing tables. No patches or xen like things are needed > if you have a > modern OS (Fedora 8, for instance). I can send here an example of a routing process death next time when it happens. It usually happens after a message like "timer expired" is shown. I don't know if it is even really a crash, it looks like that some of the routing processes decide to terminate themselves when they don't get enough processor time. Regards, Mikael From bbb999 at zerodistance.fi Wed Jan 16 03:20:40 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Wed, 16 Jan 2008 13:20:40 +0200 Subject: [Xorp-users] xorpsh load command In-Reply-To: <200801091905.m09J5RJ4050339@possum.icir.org> References: <20080109170916.GA31624@zerodistance.fi> <200801091905.m09J5RJ4050339@possum.icir.org> Message-ID: <20080116112040.GA17159@zerodistance.fi> On Wed, Jan 09, 2008 at 11:05:27AM -0800, Pavlin Radoslavov wrote: > Arsi Antila wrote: > > > On Wed, Jan 09, 2008 at 06:53:27AM -0800, Pavlin Radoslavov wrote: > > > Arsi Antila wrote: > > > > > > > Xorpsh load command does not seem to work in all situations. > > > > > > > > If I start XORP with xorp1.conf shown below, and then try to load > > > > xorp2.conf by using the load command in xorpsh, the following error > > > > message is shown: > > > > > > > > [ 2008/01/09 12:05:14 WARNING xorp_policy:5327 XrlPolicyTarget +360 > > > > policy_base.cc handle_policy_0_1_delete_policy ] Handling method for > > > > policy/0.1/delete_policy failed: XrlCmdError 102 Command failed delete_policy: > > > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object test > > > > in use by: bgp > > > > [ 2008/01/09 12:05:14 ERROR xorp_rtrmgr:5324 RTRMGR +675 > > > > master_conf_tree. > > > > cc commit_pass2_done ] Commit failed: 102 Command failed delete_policy: > > > > DependancyError from line 154 of dependancy.hh: Dependency remove: Object > > > > test in use by: bgp > > > > ERROR: Load failed. > > > > 102 Command failed delete_policy: DependancyError from line 154 of > > > > dependancy.hh: Dependency remove: Object test in use by: bgp [edit] > > > > > > > > > > > > If I start XORP with xorp2.conf as parameter, and then load > > > > xorp1.conf by using xorpsh, it works OK. > > > > > > > > Is there a way to change from xorp1.conf to xorp2.conf without > > > > restarting XORP? Even some kind of workaround would be OK. I am using > > > > Linux, XORP 1.4. > > > > > > The problem is that in xorp1.conf inside the "bgp" config there > > > is [export: "test"] statement. During the loading of xorp2.conf, the > > > first processed configuration delta is the deletion of the policy > > > statement, but from policy manager perspective it is still in use by > > > BGP, hence the above error. > > > > > > The work-around would be to delete first [export: "test"] inside > > > bgp, commit the change, and then load xorp2.conf. > > > > > > > Would that be a generic solution to the problem of changing from > > arbitrary configuration A to configuration B at run time? If I have a > > script which first deletes all policies, and then issues a load command, > > is there something that would prevent it from working in all situations? > > If both configurations A and B had restrictive policies, it would seem > > that there would be no policy rules in use for a few seconds during the > > transformation from A to B. > > The issue I described applies to all cases if the to-be-deleted > policies are referred by other part of the current configuration > (which typically is being exported or imported by some protocol). > In all such cases you have to apply the same solution: > delete first the export/import policy statement in the protocols, > commit, and then delete the previously used policy (or load new > configuration). > > Adding new policies or deleting policies that are not > exported/imported shouldn't trigger this issue. > FYI, loading new configuration is basically performing delta between > the two configurations, and then deleting/adding the deltas. I have experimented switching between different configurations by using the xorpsh load command. It seems to work OK, but I found one situation which produces an error message. This happens when I try to convert OSPF link type from broadcast to p2p, as described below. Start XORP with 'test_no_p2p_xorp.conf' as parameter. Use xorpsh load command with 'test_p2p_xorp.conf' as parameter. This results in an error message: root at sisa4a# load test_p2p_xorp.conf [ 2008/01/16 11:15:54 ERROR xorp_ospfv2:4825 OSPF +936 peer.cc add_neighbour ] Neighbour exists Address: 12.4.0.1RouterID: 12.4.0.1 [ 2008/01/16 11:15:54 WARNING xorp_ospfv2:4825 XrlOspfv2Target +604 ospfv2_base.cc handle_ospfv2_0_1_add_neighbour ] Handling method for ospfv2/0.1/add_neighbour failed: XrlCmdError 102 Command failed Failed to add neighbour 12.4.0.1 [ 2008/01/16 11:15:54 ERROR xorp_rtrmgr:4821 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Failed to add neighbour 12.4.0.1 ERROR: Load failed. 102 Command failed Failed to add neighbour 12.4.0.1[edit] ------- test_no_p2p_xorp.conf ----------- interfaces { restore-original-config-on-shutdown: false interface eth0 { default-system-config } } protocols { ospf4 { router-id: 12.4.0.2 area 0.0.0.0 { interface eth0 { vif eth0 { address 12.4.0.2 { } } } } } } -------- test_p2p_xorp.conf ---------- interfaces { restore-original-config-on-shutdown: false interface eth0 { default-system-config } } protocols { ospf4 { router-id: 12.4.0.2 area 0.0.0.0 { interface eth0 { link-type: "p2p" vif eth0 { address 12.4.0.2 { neighbor 12.4.0.1 { router-id: 12.4.0.1 } } } } } } } From pavlin at icir.org Wed Jan 16 07:53:41 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 16 Jan 2008 07:53:41 -0800 Subject: [Xorp-users] xorpsh load command In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Wed, 16 Jan 2008 13:20:40 +0200." <20080116112040.GA17159@zerodistance.fi> Message-ID: <200801161553.m0GFrfGR012708@possum.icir.org> > I have experimented switching between different configurations by using > the xorpsh load command. It seems to work OK, but I found one situation > which produces an error message. This happens when I try to convert OSPF > link type from broadcast to p2p, as described below. > > Start XORP with 'test_no_p2p_xorp.conf' as parameter. > > Use xorpsh load command with 'test_p2p_xorp.conf' as parameter. > > This results in an error message: > > root at sisa4a# load test_p2p_xorp.conf > [ 2008/01/16 11:15:54 ERROR xorp_ospfv2:4825 OSPF +936 peer.cc > add_neighbour ] > Neighbour exists Address: 12.4.0.1RouterID: 12.4.0.1 > [ 2008/01/16 11:15:54 WARNING xorp_ospfv2:4825 XrlOspfv2Target +604 > ospfv2_base.cc handle_ospfv2_0_1_add_neighbour ] Handling method for > ospfv2/0.1/add_neighbour failed: > XrlCmdError 102 Command failed Failed to add neighbour 12.4.0.1 > [ 2008/01/16 11:15:54 ERROR xorp_rtrmgr:4821 RTRMGR +675 > master_conf_tree.cc commit_pass2_done ] Commit failed: 102 > Command failed Failed to add neighbour 12.4.0.1 > ERROR: Load failed. > 102 Command failed Failed to add neighbour 12.4.0.1[edit] This problem seems to be different from the previous one. It looks like it has to do something with the OSPF internals so I would have to pass the debugging token to Atanu. Regards, Pavlin > ------- test_no_p2p_xorp.conf ----------- > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > default-system-config > } > } > protocols { > ospf4 { > router-id: 12.4.0.2 > area 0.0.0.0 { > interface eth0 { > vif eth0 { > address 12.4.0.2 { > } > } > } > } > } > } > > > -------- test_p2p_xorp.conf ---------- > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > default-system-config > } > } > protocols { > ospf4 { > router-id: 12.4.0.2 > area 0.0.0.0 { > interface eth0 { > link-type: "p2p" > vif eth0 { > address 12.4.0.2 { > neighbor 12.4.0.1 { > router-id: 12.4.0.1 > } > } > } > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From gdsm at tgfslp.dalmany.co.uk Thu Jan 17 07:44:48 2008 From: gdsm at tgfslp.dalmany.co.uk (GDS.Marshall) Date: Thu, 17 Jan 2008 15:44:48 -0000 (UTC) Subject: [Xorp-users] help please my multicasting is not working Message-ID: <43082.88.96.235.249.1200584688.squirrel@squirrelmail.tgfslp.dalmany.co.uk> I have read the xorp documentation (including that on multicasting), I have looked at the example configuration for multicasting, I have googled till the cows come home, I have read the mailing list, even back as far as 2005, but for the life of me I can not get this working. Would anyone have any suggestions on what to check or change etc. please? ISP ---- cisco 1700 ---- linux xorp ---- LAN DSL ^ ^ ^ ^ 82.70.154.150 | 192.168.4.3 192.168.4.0/24 82.70.154.145 on the cisco 1700 if I do an mtrace, it succeeds. mtrace 81.20.48.1 82.70.154.145 233.153.34.2 Type escape sequence to abort. Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 >From source (master1.gcapmedia.net) to destination (ns0.dalmany.co.uk) Querying full reverse path... 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) -1 gatekeeper.dalmany.co.uk (82.70.154.150) PIM [default] -2 master1.gcapmedia.net (81.20.48.1) If I run mtrace from a laptop on the 192.168.4.0/24 network /usr/local/bin/mtrace 81.20.48.1 192.168.4.50 233.153.34.2 Mtrace from 81.20.48.1 to 192.168.4.50 via group 233.153.34.2 Querying full reverse path... * switching to hop-by-hop: 0 hp-laptop.local (192.168.4.50) -1 * * * -2 * * * -3 * * * -4 * * * ...giving up Timed out receiving responses Perhaps no local router has a route for source 81.20.48.1 but if I look in xorp, it does xorpsh> show route table ipv4 multicast final 0.0.0.0/0 [fib2mrib(254)/65535] > to 82.70.154.150 via eth1/eth1 192.168.4.0/24 [connected(0)/0] > via eth0/eth0 82.70.154.144/29 [connected(0)/0] > via eth1/eth1 next I tried mtrace from the outside interface of the linux xorp /usr/local/bin/mtrace 81.20.48.1 82.70.154.145 233.153.34.2 Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 Querying full reverse path... * switching to hop-by-hop: 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) -1 * * * -2 * * * -3 * * * -4 * * * ...giving up Timed out receiving responses Perhaps no local router has a route for source 81.20.48.1 Here are a few show commands and results xoprsh> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout eth1 1 82.70.154.150 2 Sparse 105 98 xorpsh> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors eth0 UP Sparse 2 DR 1 192.168.4.3 0 eth1 UP Sparse 2 NotDR 1 82.70.154.150 1 register_vif UP Sparse 2 DR 1 192.168.4.3 0 why is eth1 "NotDR?" xorpsh> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 0.0.0.0/0 82.70.154.150 eth1 1 254 65535 82.70.154.144/29 82.70.154.145 eth1 1 0 0 192.168.4.0/24 192.168.4.3 eth0 0 0 0 xorpsh> ping 224.0.0.1 PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data. 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.08 ms 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.05 ms xorpsh> ping 224.0.0.13 PING 224.0.0.13 (224.0.0.13) 56(84) bytes of data. 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.07 ms 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.07 ms xorpsh> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix (i.e. there are none) Here is my configuration. /* */ interfaces { interface eth0 { default-system-config } interface eth1 { default-system-config } } plumbing { mfea4 { interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { disable: false } } } } protocols { igmp { interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } } pimsm4 { interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { disable: false } } } fib2mrib { disable: false } } Many thanks in advance, Spencer From pavlin at icir.org Thu Jan 17 12:54:27 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 17 Jan 2008 12:54:27 -0800 Subject: [Xorp-users] help please my multicasting is not working In-Reply-To: Message from "GDS.Marshall" of "Thu, 17 Jan 2008 15:44:48 GMT." <43082.88.96.235.249.1200584688.squirrel@squirrelmail.tgfslp.dalmany.co.uk> Message-ID: <200801172054.m0HKsR1v041349@possum.icir.org> GDS.Marshall wrote: > I have read the xorp documentation (including that on multicasting), I > have looked at the example configuration for multicasting, I have googled > till the cows come home, I have read the mailing list, even back as far as > 2005, but for the life of me I can not get this working. The reason it didn't work for you is very simple. Mtrace requires special support from the multicast routers, and currently the XORP implementation doesn't contain it. It is on our TODO list, but right now there is IETF activity to generate a spec for the mtrace protocol, so our preference is to have an implementation that is based on the new spec. If I remember correctly, the existing mtrace tool is based on Internet Drafts that have expired long time ago. The reason that it appears to work in one direction is probably accidental. Regards, Pavlin > Would anyone have any suggestions on what to check or change etc. please? > > ISP ---- cisco 1700 ---- linux xorp ---- LAN > DSL ^ ^ ^ ^ > 82.70.154.150 | 192.168.4.3 192.168.4.0/24 > 82.70.154.145 > > on the cisco 1700 if I do an mtrace, it succeeds. > mtrace 81.20.48.1 82.70.154.145 233.153.34.2 > Type escape sequence to abort. > Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 > From source (master1.gcapmedia.net) to destination (ns0.dalmany.co.uk) > Querying full reverse path... > 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) > -1 gatekeeper.dalmany.co.uk (82.70.154.150) PIM [default] > -2 master1.gcapmedia.net (81.20.48.1) > > If I run mtrace from a laptop on the 192.168.4.0/24 network > /usr/local/bin/mtrace 81.20.48.1 192.168.4.50 233.153.34.2 > Mtrace from 81.20.48.1 to 192.168.4.50 via group 233.153.34.2 > Querying full reverse path... * switching to hop-by-hop: > 0 hp-laptop.local (192.168.4.50) > -1 * * * > -2 * * * > -3 * * * > -4 * * * ...giving up > Timed out receiving responses > Perhaps no local router has a route for source 81.20.48.1 > > but if I look in xorp, it does > xorpsh> show route table ipv4 multicast final > 0.0.0.0/0 [fib2mrib(254)/65535] > > to 82.70.154.150 via eth1/eth1 > 192.168.4.0/24 [connected(0)/0] > > via eth0/eth0 > 82.70.154.144/29 [connected(0)/0] > > via eth1/eth1 > > next I tried mtrace from the outside interface of the linux xorp > /usr/local/bin/mtrace 81.20.48.1 82.70.154.145 233.153.34.2 > Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 > Querying full reverse path... * switching to hop-by-hop: > 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) > -1 * * * > -2 * * * > -3 * * * > -4 * * * ...giving up > Timed out receiving responses > Perhaps no local router has a route for source 81.20.48.1 > > Here are a few show commands and results > xoprsh> show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > eth1 1 82.70.154.150 2 Sparse 105 98 > > xorpsh> show pim interface > Interface State Mode V PIMstate Priority DRaddr Neighbors > eth0 UP Sparse 2 DR 1 192.168.4.3 0 > eth1 UP Sparse 2 NotDR 1 82.70.154.150 1 > register_vif UP Sparse 2 DR 1 192.168.4.3 0 > > why is eth1 "NotDR?" > > xorpsh> show pim mrib > DestPrefix NextHopRouter VifName VifIndex MetricPref Metric > 0.0.0.0/0 82.70.154.150 eth1 1 254 65535 > 82.70.154.144/29 82.70.154.145 eth1 1 0 0 > 192.168.4.0/24 192.168.4.3 eth0 0 0 0 > > xorpsh> ping 224.0.0.1 > PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data. > 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.08 ms > 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.05 ms > > xorpsh> ping 224.0.0.13 > PING 224.0.0.13 (224.0.0.13) 56(84) bytes of data. > 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.07 ms > 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.07 ms > > xorpsh> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > > (i.e. there are none) > > Here is my configuration. > /* > > */ > interfaces { > interface eth0 { > default-system-config > } > interface eth1 { > default-system-config > } > } > > plumbing { > mfea4 { > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > } > } > > protocols { > igmp { > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > } > > pimsm4 { > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > } > > fib2mrib { > disable: false > } > } > > Many thanks in advance, > > Spencer > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From gdsm at tgfslp.dalmany.co.uk Fri Jan 18 00:07:24 2008 From: gdsm at tgfslp.dalmany.co.uk (GDS.Marshall) Date: Fri, 18 Jan 2008 08:07:24 -0000 (UTC) Subject: [Xorp-users] help please my multicasting is not working In-Reply-To: <200801172054.m0HKsR1v041349@possum.icir.org> References: <200801172054.m0HKsR1v041349@possum.icir.org> Message-ID: <59828.82.70.154.145.1200643644.squirrel@squirrelmail.tgfslp.dalmany.co.uk> On Thu, 17 January, 2008 8:54 pm, Pavlin Radoslavov wrote: > GDS.Marshall wrote: > >> I have read the xorp documentation (including that on multicasting), I >> have looked at the example configuration for multicasting, I have >> googled >> till the cows come home, I have read the mailing list, even back as far >> as >> 2005, but for the life of me I can not get this working. > > The reason it didn't work for you is very simple. > Mtrace requires special support from the multicast routers, and > currently the XORP implementation doesn't contain it. So all my diagnosing was wasted :( The reason for trying mtrace was the fact my multicast is not working. I can not view/listen to any multicast streams. Neither do dbeacon or ssmping work from a multicast point of view. Would anyone have any suggestions on what to check or change etc. please? >> >> ISP ---- cisco 1700 ---- linux xorp ---- LAN >> DSL ^ ^ ^ ^ >> 82.70.154.150 | 192.168.4.3 192.168.4.0/24 >> 82.70.154.145 >> >> on the cisco 1700 if I do an mtrace, it succeeds. >> mtrace 81.20.48.1 82.70.154.145 233.153.34.2 >> Type escape sequence to abort. >> Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 >> From source (master1.gcapmedia.net) to destination (ns0.dalmany.co.uk) >> Querying full reverse path... >> 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) >> -1 gatekeeper.dalmany.co.uk (82.70.154.150) PIM [default] >> -2 master1.gcapmedia.net (81.20.48.1) >> >> If I run mtrace from a laptop on the 192.168.4.0/24 network >> /usr/local/bin/mtrace 81.20.48.1 192.168.4.50 233.153.34.2 >> Mtrace from 81.20.48.1 to 192.168.4.50 via group 233.153.34.2 >> Querying full reverse path... * switching to hop-by-hop: >> 0 hp-laptop.local (192.168.4.50) >> -1 * * * >> -2 * * * >> -3 * * * >> -4 * * * ...giving up >> Timed out receiving responses >> Perhaps no local router has a route for source 81.20.48.1 >> >> but if I look in xorp, it does >> xorpsh> show route table ipv4 multicast final >> 0.0.0.0/0 [fib2mrib(254)/65535] >> > to 82.70.154.150 via eth1/eth1 >> 192.168.4.0/24 [connected(0)/0] >> > via eth0/eth0 >> 82.70.154.144/29 [connected(0)/0] >> > via eth1/eth1 >> >> next I tried mtrace from the outside interface of the linux xorp >> /usr/local/bin/mtrace 81.20.48.1 82.70.154.145 233.153.34.2 >> Mtrace from 81.20.48.1 to 82.70.154.145 via group 233.153.34.2 >> Querying full reverse path... * switching to hop-by-hop: >> 0 spitfire.tgfslp.dalmany.co.uk (82.70.154.145) >> -1 * * * >> -2 * * * >> -3 * * * >> -4 * * * ...giving up >> Timed out receiving responses >> Perhaps no local router has a route for source 81.20.48.1 >> >> Here are a few show commands and results >> xoprsh> show pim neighbors >> Interface DRpriority NeighborAddr V Mode Holdtime Timeout >> eth1 1 82.70.154.150 2 Sparse 105 98 >> >> xorpsh> show pim interface >> Interface State Mode V PIMstate Priority DRaddr >> Neighbors >> eth0 UP Sparse 2 DR 1 192.168.4.3 >> 0 >> eth1 UP Sparse 2 NotDR 1 82.70.154.150 >> 1 >> register_vif UP Sparse 2 DR 1 192.168.4.3 >> 0 >> >> why is eth1 "NotDR?" >> >> xorpsh> show pim mrib >> DestPrefix NextHopRouter VifName VifIndex MetricPref Metric >> 0.0.0.0/0 82.70.154.150 eth1 1 254 65535 >> 82.70.154.144/29 82.70.154.145 eth1 1 0 0 >> 192.168.4.0/24 192.168.4.3 eth0 0 0 0 >> >> xorpsh> ping 224.0.0.1 >> PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data. >> 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.08 ms >> 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.05 ms >> >> xorpsh> ping 224.0.0.13 >> PING 224.0.0.13 (224.0.0.13) 56(84) bytes of data. >> 64 bytes from 82.70.154.150: icmp_seq=1 ttl=255 time=1.07 ms >> 64 bytes from 82.70.154.150: icmp_seq=2 ttl=255 time=1.07 ms >> >> xorpsh> show pim rps >> RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix >> >> (i.e. there are none) >> >> Here is my configuration. >> /* >> >> */ >> interfaces { >> interface eth0 { >> default-system-config >> } >> interface eth1 { >> default-system-config >> } >> } >> >> plumbing { >> mfea4 { >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> disable: false >> } >> } >> } >> } >> >> protocols { >> igmp { >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> } >> } >> } >> >> pimsm4 { >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> disable: false >> } >> } >> } >> >> fib2mrib { >> disable: false >> } >> } >> >> Many thanks in advance, >> >> Spencer >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From jfs at computer.org Fri Jan 18 01:15:28 2008 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Fri, 18 Jan 2008 10:15:28 +0100 Subject: [Xorp-users] help please my multicasting is not working In-Reply-To: <59828.82.70.154.145.1200643644.squirrel@squirrelmail.tgfslp.dalmany.co.uk> References: <200801172054.m0HKsR1v041349@possum.icir.org> <59828.82.70.154.145.1200643644.squirrel@squirrelmail.tgfslp.dalmany.co.uk> Message-ID: 2008/1/18, GDS.Marshall : > The reason for trying mtrace was the fact my multicast is not working. I > can not view/listen to any multicast streams. Neither do dbeacon or > ssmping work from a multicast point of view. If multicast is working you should be able to use ssmping to test it out. Maybe you could use msend/mlisten too. Those tools do work with Xorp. > > Would anyone have any suggestions on what to check or change etc. > please? It looks like Xorp doesn't know who to forward traffic of unknown multicast groups to. Maybe you want to explicitly set the RendezVous Point (RP) for Xorp. Since the DR for the interrouter network is the Cisco router you might want to add: static-rps { rp 82.70.154.150 { group-prefix 224.0.0.0/4 { } } } To the pimsm4 definition. As for why is the Cisco router is the DR 82.70.154.144/29 I guess that's because it is negotiated that way. Maybe the Cisco router has a Multicast configuration giving it a higher weight. IIRC the RFCs say that on even weights the DR of a network is the multicast router with the lowest IP but that is not happening in yours (Xorp has the IP address 82.70.154.145, which is lower than 82.70.154.150). I suggest you review the multicast configuration on the Cisco router or, if none has been done, the system's default values for Multicast. HTH Javier From gdsm at tgfslp.dalmany.co.uk Fri Jan 18 06:32:49 2008 From: gdsm at tgfslp.dalmany.co.uk (GDS.Marshall) Date: Fri, 18 Jan 2008 14:32:49 -0000 (UTC) Subject: [Xorp-users] help please my multicasting is not working In-Reply-To: References: <200801172054.m0HKsR1v041349@possum.icir.org> <59828.82.70.154.145.1200643644.squirrel@squirrelmail.tgfslp.dalmany.co.uk> Message-ID: <2089.88.96.235.249.1200666769.squirrel@squirrelmail.tgfslp.dalmany.co.uk> On Fri, 18 January, 2008 9:15 am, Javier Fernandez-Sanguino wrote: > 2008/1/18, GDS.Marshall : >> The reason for trying mtrace was the fact my multicast is not working. >> I >> can not view/listen to any multicast streams. Neither do dbeacon or >> ssmping work from a multicast point of view. > > If multicast is working you should be able to use ssmping to test it > out. Maybe you could use msend/mlisten too. Those tools do work with > Xorp. I have tried to find msend/mlisten, I found a reference and url in a reply Pavlin made to Swati (http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-April/000532.html) however, it would appear the site (http://netweb.usc.edu/pim/pimd/) is no longer available. Does anyone know where else I can download it from please? I could not find it on freshmeat, sourceforge or google. I have looked in the pimd package (ubuntu/debian) but it is not there either. > >> >> Would anyone have any suggestions on what to check or change etc. >> please? > > It looks like Xorp doesn't know who to forward traffic of unknown > multicast groups to. Maybe you want to explicitly set the RendezVous > Point (RP) for Xorp. Since the DR for the interrouter network is the > Cisco router you might want to add: > > static-rps { > rp 82.70.154.150 { > group-prefix 224.0.0.0/4 { > } > } > } > > To the pimsm4 definition. I have done thank you. > > As for why is the Cisco router is the DR 82.70.154.144/29 I guess > that's because it is negotiated that way. Maybe the Cisco router has a > Multicast configuration giving it a higher weight. IIRC the RFCs say > that on even weights the DR of a network is the multicast router with > the lowest IP but that is not happening in yours (Xorp has the IP > address 82.70.154.145, which is lower than 82.70.154.150). rfc4601 has the following "a.primary_ip_address > b.primary_ip_address" and from the cisco notes quote.. If multiple devices have the same DR priority, then the device with the highest IP address becomes the DR. .. endquote I would expect the cisco to be the DR because it has the higher IP > I suggest > you review the multicast configuration on the Cisco router or, if none > has been done, the system's default values for Multicast. I have had another look, and can not see anything glaringly obvious with the exception of show ip pim neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 82.70.154.145 Ethernet0 03:36:31/00:01:15 v2 1 / 0.0.0.0 Dialer1 1w1d/now 0 / DR I would have expected the dialer1 interface to have a neighbour of my ISP's router. The relevant config sections of the cisco if anyone does not mind having a look. ip multicast-routing interface Ethernet0 ip address 82.70.154.150 255.255.255.248 ip pim sparse-dense-mode ip igmp helper-address udl Dialer1 no ip mroute-cache full-duplex no cdp enable interface Dialer1 ip unnumbered Ethernet0 ip mtu 1492 ip nat outside <-- for f0 not being tested for multicast ip pim sparse-dense-mode encapsulation ppp ip route 0.0.0.0 0.0.0.0 Dialer1 Any help anyone can provide is much appreciated. If anyone is running ssmpingd or dbeacon they do not mind me pointing at and letting me know if I get seen, would also be appreciated. Thank you, Spencer From bbb999 at zerodistance.fi Fri Jan 18 08:57:47 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Fri, 18 Jan 2008 18:57:47 +0200 Subject: [Xorp-users] xorpsh load command In-Reply-To: <200801161553.m0GFrfGR012708@possum.icir.org> References: <20080116112040.GA17159@zerodistance.fi> <200801161553.m0GFrfGR012708@possum.icir.org> Message-ID: <20080118165747.GA15744@zerodistance.fi> On Wed, Jan 16, 2008 at 07:53:41AM -0800, Pavlin Radoslavov wrote: > > I have experimented switching between different configurations by using > > the xorpsh load command. It seems to work OK, but I found one situation > > which produces an error message. This happens when I try to convert OSPF > > link type from broadcast to p2p, as described below. > > This problem seems to be different from the previous one. > It looks like it has to do something with the OSPF internals so I > would have to pass the debugging token to Atanu. > Here is something else that works differently when xorpsh-load is used, as compared to giving configuration as parameter when starting XORP. When I try to change BSR scope-zone from 225.0.0.1/32 to 225.0.0.2/32 by using xorpsh-load, BSR state never goes to 'Elected' as it does when the configuration is given as a parameter when starting XORP. Steps below: - Start XORP with xorp1.conf - Wait 2 minutes. BSR in 'Elected' state. > show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 12.1.0.1 1 12.1.0.1 1 Elected 58 -1 Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 12.1.0.1 1 12.1.0.1 1 Init -1 -1 # load xorp2.conf [ 2008/01/18 14:16:02 INFO xorp_pimsm4 PIM ] Bootstrap mechanism stopped [ 2008/01/18 14:16:02 INFO xorp_pimsm4 PIM ] Bootstrap mechanism started [ 2008/01/18 14:16:02 INFO xorp_rtrmgr:11446 RTRMGR +2228 task.cc run_task ] No more tasks to run Load done. [edit] > show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 12.1.0.1 1 12.1.0.1 1 Init -1 -1 - After 2 minutes, BSR not shown in 'Elected' state - When starting XORP with 'xorp2.conf' as parameter, BSR is shown in 'Elected' state after 2 minutes: > show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 12.1.0.1 1 12.1.0.1 1 Elected 53 -1 Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 12.1.0.1 1 12.1.0.1 1 Init -1 -1 --- xorp1.conf --- interfaces { restore-original-config-on-shutdown: false interface eth2 { default-system-config } } protocols { pimsm4 { interface eth2 { vif eth2 { } } interface register_vif { vif register_vif { disable: false } } bootstrap { cand-bsr { scope-zone 225.0.0.1/32 { cand-bsr-by-vif-name: "eth2" cand-bsr-by-vif-addr: 12.1.0.1 } } } } } plumbing { mfea4 { interface eth2 { vif eth2 { } } interface register_vif { vif register_vif { } } } } --- xorp2.conf --- interfaces { restore-original-config-on-shutdown: false interface eth2 { default-system-config } } protocols { pimsm4 { interface eth2 { vif eth2 { } } interface register_vif { vif register_vif { disable: false } } bootstrap { cand-bsr { scope-zone 225.0.0.2/32 { cand-bsr-by-vif-name: "eth2" cand-bsr-by-vif-addr: 12.1.0.1 } } } } } plumbing { mfea4 { interface eth2 { vif eth2 { } } interface register_vif { vif register_vif { } } } } From atanu at ICSI.Berkeley.EDU Fri Jan 18 09:09:45 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 18 Jan 2008 09:09:45 -0800 Subject: [Xorp-users] Question on OSPF route failover. In-Reply-To: Message from Ben Greear of "Mon, 14 Jan 2008 13:03:48 PST." <478BCE34.6020109@candelatech.com> Message-ID: <93338.1200676185@tigger.icir.org> Hi, OSPF should always use the lowest cost link that is up, could you send the OSPF database for the case when the lowest cost link is not being used so that we can investigate. Saving the OSPF database: "ospf/tools/print_lsas -S /tmp/saved.lsas". Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Suppose there are two paths between two XORP OSPF routers. One Ben> is high cost, the other low cost and preferred if it is up. Ben> The high-cost link is assumed to be always up in this scenario. Ben> When xorp first starts, and both links are up, it chooses the Ben> low cost link. When the low cost link dies, it chooses the Ben> high-cost link. Ben> But, when the low-cost link comes back, it doesn't seem to Ben> change back to using it. Is this expected behaviour? Ben> Is there any way to make sure it uses the low-cost link Ben> whenever it's up? Ben> Thanks, Ben Ben> -- Ben Greear Candela Technologies Ben> Inc http://www.candelatech.com Ben> _______________________________________________ Xorp-users Ben> mailing list Xorp-users at xorp.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Fri Jan 18 09:24:13 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 18 Jan 2008 09:24:13 -0800 Subject: [Xorp-users] Question on OSPF route failover. In-Reply-To: <93338.1200676185@tigger.icir.org> References: <93338.1200676185@tigger.icir.org> Message-ID: <4790E0BD.2090703@candelatech.com> Atanu Ghosh wrote: > Hi, > > OSPF should always use the lowest cost link that is up, could you send > the OSPF database for the case when the lowest cost link is not being > used so that we can investigate. > > Saving the OSPF database: "ospf/tools/print_lsas -S /tmp/saved.lsas". > > Atanu. > Ok. This could have been caused by something else, as a reboot seemed to clear up the situation. I wanted to make sure of the expected behaviour before I dug into debugging it too much. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From gdsm at tgfslp.dalmany.co.uk Mon Jan 21 04:13:14 2008 From: gdsm at tgfslp.dalmany.co.uk (GDS.Marshall) Date: Mon, 21 Jan 2008 12:13:14 -0000 (UTC) Subject: [Xorp-users] help with a different multicast tack Message-ID: <45141.88.96.235.249.1200917594.squirrel@squirrelmail.tgfslp.dalmany.co.uk> As I am unable to get multicasting working from my public IP address, I am going to try nat on the router which I understand from else where does work. What I would like to know is how do I tell xorp yes, you have interface eth1:0 172.16.1.3, eth1:1 192.168.1.3 but, only 172.16.1.3 is used for multicast. I tried telling it the interface parameters, but lost the alias in the process. I now presume I leave the interfaces at their default, and change something in the pimsm4 section, but do not know what. Many thanks, Spencer From pavlin at icir.org Mon Jan 21 18:27:50 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 21 Jan 2008 18:27:50 -0800 Subject: [Xorp-users] help please my multicasting is not working In-Reply-To: Message from "GDS.Marshall" of "Fri, 18 Jan 2008 14:32:49 GMT." <2089.88.96.235.249.1200666769.squirrel@squirrelmail.tgfslp.dalmany.co.uk> Message-ID: <200801220227.m0M2RoLH061006@possum.icir.org> > I have tried to find msend/mlisten, I found a reference and url in a reply > Pavlin made to Swati > (http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-April/000532.html) > however, it would appear the site (http://netweb.usc.edu/pim/pimd/) is no > longer available. Does anyone know where else I can download it from > please? I could not find it on freshmeat, sourceforge or google. I have > looked in the pimd package (ubuntu/debian) but it is not there either. I was told that the netweb.usc.edu Web site is temporary down and it might take few weeks until it is back again (due to limited human resources). I just uploaded a copy of the USC mtest to http://www.icir.org/pavlin/.private/mtest.tar.gz However, this will be removed in few days so you should download it now. > > It looks like Xorp doesn't know who to forward traffic of unknown > > multicast groups to. Maybe you want to explicitly set the RendezVous > > Point (RP) for Xorp. Since the DR for the interrouter network is the > > Cisco router you might want to add: > > > > static-rps { > > rp 82.70.154.150 { > > group-prefix 224.0.0.0/4 { > > } > > } > > } > > > > To the pimsm4 definition. > I have done thank you. I should note here that you need to double-check that the RP used by the Cisco router is actually 82.70.154.150. If it is different, then use the actual address in the above XORP configuration. > > As for why is the Cisco router is the DR 82.70.154.144/29 I guess > > that's because it is negotiated that way. Maybe the Cisco router has a > > Multicast configuration giving it a higher weight. IIRC the RFCs say > > that on even weights the DR of a network is the multicast router with > > the lowest IP but that is not happening in yours (Xorp has the IP > > address 82.70.154.145, which is lower than 82.70.154.150). > rfc4601 has the following "a.primary_ip_address > b.primary_ip_address" > > and from the cisco notes quote.. > If multiple devices have the same DR priority, then the device with the > highest IP address becomes the DR. > .. endquote > I would expect the cisco to be the DR because it has the higher IP > > > I suggest > > you review the multicast configuration on the Cisco router or, if none > > has been done, the system's default values for Multicast. > I have had another look, and can not see anything glaringly obvious with > the exception of > show ip pim neighbor > PIM Neighbor Table > Neighbor Interface Uptime/Expires Ver DR > Address Prio/Mode > 82.70.154.145 Ethernet0 03:36:31/00:01:15 v2 1 / > 0.0.0.0 Dialer1 1w1d/now 0 / DR I am not familiar with Cisco output, but to me it looks like that in the above output the IP address of the XORP router (82.70.154.145) is NOT marked as DR. Also, according to your original email on the subject, from XORP's "show pim interface" output it looks like that Cisco's IP address (82.70.154.150) is the DR (as expected): xorpsh> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors eth0 UP Sparse 2 DR 1 192.168.4.3 0 eth1 UP Sparse 2 NotDR 1 82.70.154.150 1 register_vif UP Sparse 2 DR 1 192.168.4.3 0 > I would have expected the dialer1 interface to have a neighbour of my > ISP's router. > > The relevant config sections of the cisco if anyone does not mind having a > look. > ip multicast-routing > interface Ethernet0 > ip address 82.70.154.150 255.255.255.248 > ip pim sparse-dense-mode > ip igmp helper-address udl Dialer1 > no ip mroute-cache > full-duplex > no cdp enable > > interface Dialer1 > ip unnumbered Ethernet0 > ip mtu 1492 > ip nat outside <-- for f0 not being tested for multicast > ip pim sparse-dense-mode > encapsulation ppp > > ip route 0.0.0.0 0.0.0.0 Dialer1 Sorry, I am not familiar with Cisco setup so I can't help you with with its configuration. Regards, Pavlin > Any help anyone can provide is much appreciated. > > If anyone is running ssmpingd or dbeacon they do not mind me pointing at > and letting me know if I get seen, would also be appreciated. > > Thank you, > > Spencer From pavlin at icir.org Tue Jan 22 12:47:16 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Jan 2008 12:47:16 -0800 Subject: [Xorp-users] xorpsh load command In-Reply-To: Message from bbb999@zerodistance.fi (Arsi Antila) of "Fri, 18 Jan 2008 18:57:47 +0200." <20080118165747.GA15744@zerodistance.fi> Message-ID: <200801222047.m0MKlGtC006076@possum.icir.org> > Here is something else that works differently when xorpsh-load is used, > as compared to giving configuration as parameter when starting XORP. > > When I try to change BSR scope-zone from 225.0.0.1/32 to 225.0.0.2/32 by > using xorpsh-load, BSR state never goes to 'Elected' as it does when the > configuration is given as a parameter when starting XORP. Steps below: There was a bug in the PIM template configuration. I just committed a fix which should take care of it: Revision Changes Path 1.33 +7 -5; commitid: 200a479653db7ea6; xorp/etc/templates/pimsm4.tp 1.33 +6 -5; commitid: 200a479653db7ea6; xorp/etc/templates/pimsm6.tp Please get the latest code from anon. CVS and let me know whether it fixes the problem for you. You could try updating only the above template files, but this might not work if your XORP version is very old. Thanks, Pavlin From pavlin at icir.org Tue Jan 22 13:12:19 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 22 Jan 2008 13:12:19 -0800 Subject: [Xorp-users] help with a different multicast tack In-Reply-To: Message from "GDS.Marshall" of "Mon, 21 Jan 2008 12:13:14 GMT." <45141.88.96.235.249.1200917594.squirrel@squirrelmail.tgfslp.dalmany.co.uk> Message-ID: <200801222112.m0MLCJps006435@possum.icir.org> GDS.Marshall wrote: > > As I am unable to get multicasting working from my public IP address, I am > going to try nat on the router which I understand from else where does > work. > > What I would like to know is how do I tell xorp > yes, you have interface eth1:0 172.16.1.3, eth1:1 192.168.1.3 but, only > 172.16.1.3 is used for multicast. I tried telling it the interface > parameters, but lost the alias in the process. Those eth1:0 and eth1:1 are not real interfaces, but IP address aliases for the same interface. If you want to use only a specific single IP address on an interface (or a subset of all IP addresses), then you need to explicitly configure the address information in the "interfaces" section. E.g.: interfaces { interface eth1 { vif eth1 { address 172.16.1.3 { prefix-length: 16 } } } } Then just configure interface/vif eth1 in the mfea4, igmp and pimsm4 sections. E.g.: plumbing { mfea4 { interface eth1 { vif eth1 { } } ... } } Hope that helps, Pavlin > I now presume I leave the interfaces at their default, and change > something in the pimsm4 section, but do not know what. > > Many thanks, > > Spencer > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bbb999 at zerodistance.fi Thu Jan 24 04:22:24 2008 From: bbb999 at zerodistance.fi (Arsi Antila) Date: Thu, 24 Jan 2008 14:22:24 +0200 Subject: [Xorp-users] xorpsh load command In-Reply-To: <200801222047.m0MKlGtC006076@possum.icir.org> References: <20080118165747.GA15744@zerodistance.fi> <200801222047.m0MKlGtC006076@possum.icir.org> Message-ID: <20080124122224.GA32060@zerodistance.fi> On Tue, Jan 22, 2008 at 12:47:16PM -0800, Pavlin Radoslavov wrote: > > Here is something else that works differently when xorpsh-load is used, > > as compared to giving configuration as parameter when starting XORP. > > > > When I try to change BSR scope-zone from 225.0.0.1/32 to 225.0.0.2/32 by > > using xorpsh-load, BSR state never goes to 'Elected' as it does when the > > configuration is given as a parameter when starting XORP. Steps below: > > There was a bug in the PIM template configuration. I just committed > a fix which should take care of it: > > Revision Changes Path > 1.33 +7 -5; commitid: 200a479653db7ea6; xorp/etc/templates/pimsm4.tp > 1.33 +6 -5; commitid: 200a479653db7ea6; xorp/etc/templates/pimsm6.tp > > Please get the latest code from anon. CVS and let me know whether it > fixes the problem for you. > You could try updating only the above template files, but this might > not work if your XORP version is very old. I tried it, and it works. Thanks, Arsi From david.bond at themis.com Thu Jan 24 15:52:50 2008 From: david.bond at themis.com (David Bond) Date: Thu, 24 Jan 2008 15:52:50 -0800 (PST) Subject: [Xorp-users] Multicast Forwarding Message-ID: <4972545.122331201218770386.JavaMail.root@mail.themis.com> I posted the following message to Bugzilla, and it was suggested to move it to the mailing lists instead. Here is the text of my post: The system that I'm using Xorp upon, is a Freescale 8548E based Linux system. It is running kernel version 2.6.9. The Linux port is from Denx. This system has 4 ethernet ports and 2 Infiniband ports. Essentially it is an Infiniband Target Channel Adapter (TCA). All unicast traffic is routed properly, and the system functions quite well. However, multicast traffic from the outside (ethernet side) to the inside (Infiniband), unless there is an application running on the TCA that also receives the multicast traffic. If this occurs, all is well, and the multicast traffic is forward to the inside. The problem is that this is not an acceptable solution, since the TCA is to function as a black box router. Am I missing something in my configuration of Xorp? I'm not using BGP, OSPF, or any ipv6. This is strictly a routing and forwarding application. Any suggestions? Additional details are: - Unicast forwarding is done through static L3 routes. The network is closed (no outside world access), so it was determined to use this approach. - All multicast packets received on any ethernet port need to be forwarded to only one of the Infiniband ports (ib0). The second Infiniband port is inactive in this application. - I have complete control over the multicast group addressing. In other words, I control the source of the multicast packet as well as the destination. - This is a FLASH based system, and numerous parts of xorp were not included due to space limitations. This include xorpsh. So is there a way with Xorp to setup persistent static multicast routes, that do not require an IGMP join? Thank you, David -- ********************************************************************* David Bond Themis Computer 47200 Bayside Parkway Fremont, CA 94538 Telephone: +1-510-252-0870 Fax: +1-510-490-5529 ********************************************************************* No matter where you go, there you are - B. Banzai ********************************************************************* From pavlin at icir.org Thu Jan 24 16:31:56 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 24 Jan 2008 16:31:56 -0800 Subject: [Xorp-users] Multicast Forwarding In-Reply-To: Message from David Bond of "Thu, 24 Jan 2008 15:52:50 PST." <4972545.122331201218770386.JavaMail.root@mail.themis.com> Message-ID: <200801250031.m0P0VuSq030574@possum.icir.org> > - All multicast packets received on any ethernet port need to be > - forwarded to only one of the Infiniband ports (ib0). The second > - Infiniband port is inactive in this application. This requirement means that you cannot use L3 multicast routing (at least by using standard L3 multicast routing protocols). One of the reasons is that typically an explicit join (per group) is needed to forward the traffic. The other reason is that for each multicast forwarding entry there should be a single incoming interface (typically the Reverse Path Forwarding interface toward the source or the RP in case of PIM-SM). It looks like you need a transparent hub that will forward all multicast packets from the Ethernet port to the Infiniband port. Unfortunately I am not aware of any open-source solutions that will do that to you (they might exist, I am just not aware of them). There is one hackish solution you could use with XORP, but it is a bit complicated: 1. Configure the XORP box to be a static RP for the whole multicast address range 224.0.0.0/4. 2. Use the protocols/pimsm4/interface/vif/alternative-subnet configuration statements on each Ethernet interface to add entries to make all remote sources appear as directly connected to one of the Ethernet interfaces. You might have to be a little bit careful about the exact configuration, because (a) you need to cover the address space for all possible remote senders, and (b) if the multicast packets from sender S1 appear on interface eth1, then eth1 must have "alternative-subnet" configuration statement to cover the S1 address. 3. The tricky part: Use PIM-SM (*,*,RP) Join on the Infiniband port. As per the PIM-SM spec, the purpose of the (*,*,RP) Join is to pull-down all multicast traffic that is routed in that RP. Given that your XORP box will be the RP for all multicast groups, as a result of that all traffic that reached any of the Ethernet ports will be forwarded on the Infiniband port. The tricky part is how to get (*,*,RP) Join on the Infiniband port. Those joins are suppose to be periodic and are suppose to come from a PIM-SM neighbor. One option is to have a second instance of XORP running on the TCA, but this is probably too heavy for your requirements. If you have everything under your control, the more pragmatic option is to modify the XORP source code to make it think that it has received (*,*,RP) on the ib0 interface. Let me know if you are willing to try this solution and we can take it offline with the technical details. Regards, Pavlin From pavlin at icir.org Thu Jan 24 16:56:19 2008 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 24 Jan 2008 16:56:19 -0800 Subject: [Xorp-users] Multicast Forwarding In-Reply-To: Message from Pavlin Radoslavov of "Thu, 24 Jan 2008 16:31:56 PST." <200801250031.m0P0VuSq030574@possum.icir.org> Message-ID: <200801250056.m0P0uJnI030958@possum.icir.org> > There is one hackish solution you could use with XORP, but it is a > bit complicated: > > 1. Configure the XORP box to be a static RP for the whole multicast > address range 224.0.0.0/4. > > 2. Use the protocols/pimsm4/interface/vif/alternative-subnet > configuration statements on each Ethernet interface to add > entries to make all remote sources appear as directly connected > to one of the Ethernet interfaces. > You might have to be a little bit careful about the exact > configuration, because (a) you need to cover the address space > for all possible remote senders, and (b) if the multicast packets > from sender S1 appear on interface eth1, then eth1 must have > "alternative-subnet" configuration statement to cover the S1 > address. > > 3. The tricky part: Use PIM-SM (*,*,RP) Join on the Infiniband port. > As per the PIM-SM spec, the purpose of the (*,*,RP) Join is to > pull-down all multicast traffic that is routed in that RP. > Given that your XORP box will be the RP for all multicast groups, > as a result of that all traffic that reached any of the Ethernet > ports will be forwarded on the Infiniband port. > > The tricky part is how to get (*,*,RP) Join on the Infiniband > port. Those joins are suppose to be periodic and are suppose to > come from a PIM-SM neighbor. One option is to have a second > instance of XORP running on the TCA, but this is probably too > heavy for your requirements. > > If you have everything under your control, the more pragmatic > option is to modify the XORP source code to make it think that it > has received (*,*,RP) on the ib0 interface. Forgot to mention that the cleaner option would be for us to add a XORP configuration option to set the equivalent of (*,*,RP) Join state per interface. I need to think more carefully what the exact semantics should look like. I remember in the past someone needed to do something unusual with XORP which could be solved with a similar solution, so I think adding such feature could be useful for various applications. Again, please let me know whether you want to pursue this and we could take it offline. Regards, Pavlin From nezleshmil at gmail.com Mon Jan 28 01:39:47 2008 From: nezleshmil at gmail.com (Anonymous Name) Date: Mon, 28 Jan 2008 11:39:47 +0200 Subject: [Xorp-users] Why an XRL request is failing ?? Message-ID: I am getting this error : WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/deregister_interest4 failed: XrlCmdError 102 Command failed Failed to deregister target bgp for prefix 34.66.87.204/30 somebody knows why this could happen ? Thanks, Nez. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080128/0b267838/attachment.html From asivadu at yahoo.com Mon Jan 28 04:52:15 2008 From: asivadu at yahoo.com (asi vadu) Date: Mon, 28 Jan 2008 04:52:15 -0800 (PST) Subject: [Xorp-users] RIP compilation Message-ID: <900915.80888.qm@web35901.mail.mud.yahoo.com> Hi, I want to compile only RIP protocols frop xorp 1.4. And I want to implement the CLI commands for RIP. What are the modules to be included along with RIP? What are the changes made? please help me. Thanks & Regards, MSRAO. --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080128/dd5fcde9/attachment.html