From lists@pjb.homelinux.net Sun Feb 5 19:36:58 2006 From: lists@pjb.homelinux.net (lists) Date: Sun, 5 Feb 2006 14:36:58 -0500 (EST) Subject: [Xorp-users] Routing of Multicast Traffic Message-ID: <2834.192.168.10.254.1139168218.squirrel@pjb.homelinux.net> Hi, I would like to use Xorp to simulate a ground network which is currently being installed. The aim is to allow lab testing of the distributed system before delivery. The ground network will terminate at 5 sites (each on a different subnet with associated gateway). Until now I have been using monowall with a NIC for each site, with the card IP address set to the respective site gateway IP address. This has worked fine with unicast traffic, but we are now adding multicast traffic to the network (senders and receivers on all subnets) and monowall will not route multicast traffic between interfaces. The equipment at each site will be connected with existing Cisco 3550 Catalyst or Notel Baystack switches (all of which are currently configured as simple switches). I am unsure whether I can achieve what I need to do with the LiveCD and simple static routes (inc. multicast static routes) or whether dynamic routing (PIM-Sparse with RIP or BGP) would be preferable? Each of the 5 sites will have a single switch with connected PCs and is for an evaluation only, not long term installation. Thanks, Peter From pavlin@icir.org Mon Feb 6 03:47:50 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 05 Feb 2006 19:47:50 -0800 Subject: [Xorp-users] Routing of Multicast Traffic In-Reply-To: Message from "lists" of "Sun, 05 Feb 2006 14:36:58 EST." <2834.192.168.10.254.1139168218.squirrel@pjb.homelinux.net> Message-ID: <200602060347.k163loh9019210@possum.icir.org> > I would like to use Xorp to simulate a ground network which is currently > being installed. The aim is to allow lab testing of the distributed system > before delivery. The ground network will terminate at 5 sites (each on a > different subnet with associated gateway). > > Until now I have been using monowall with a NIC for each site, with the > card IP address set to the respective site gateway IP address. This has > worked fine with unicast traffic, but we are now adding multicast traffic > to the network (senders and receivers on all subnets) and monowall will > not route multicast traffic between interfaces. > > The equipment at each site will be connected with existing Cisco 3550 > Catalyst or Notel Baystack switches (all of which are currently configured > as simple switches). > > I am unsure whether I can achieve what I need to do with the LiveCD and > simple static routes (inc. multicast static routes) or whether dynamic > routing (PIM-Sparse with RIP or BGP) would be preferable? Each of the 5 > sites will have a single switch with connected PCs and is for an > evaluation only, not long term installation. First I should say that unlike unicast, for all practical reasons there is no such thing as static multicast routing. In general, multicast group membership is dynamic. Furthermore, static multicast routing can be extremely dangerous: if you end-up with a multicast routing loop this may bring-down your network. Hence, you would have to use PIM-SM (or any other multicast routing protocol you may like) or an alternative like IGMP snooping. Unfortunately, I am not aware about any open-source IGMP snooping implementation so if you choose this option you would have to go with a proprietary implementation. Note that if you decide to run PIM-SM you don't have to run a dynamic unicast routing protocol like BGP or RIP: you could use static unicast routing instead. Furthermore, you don't need to install even unicast static routes: you could install static routes that are used only for the purpose of multicast RPF (reverse-path forwarding) check. See the XORP user manual for the mrib-route4 or mrib-interface-route4 static routes setup. The user manual should contain all other information you need to configure XORP. A hint: probably you don't need the dynamic PIM-SM Bootstrap mechanism; in your case it may be simpler if you use static Cand-RP(s). Pavlin From riccardo.sciaccaluga@tin.it" Hi i made up some switching time test with xorp as follows: 1)I set up a network with two possible path to the same destination but with different metric 2)I start sending ip packets over this network towards the destination node 3)I turned up the metric of the old low cost path to make it the the new higher cost one. 4)I sniffed the ip traffic over these links and i make this experiment lot of times The thing i noticed is that xorp needs 5 to 6 seconds to switch the traffic to the new low cost path. I thing that this time is too long but i also thing that it could be because of some delayed action(like delayed spf scheduling or delayed access to te routing table or whatever). My questions are: what are the default delayed action that xorp does and their delay value? Where can i find this information inside xorp code? Thanks in advance for your help. From hkontos@gmail.com Mon Feb 6 16:48:08 2006 From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=) Date: Mon, 6 Feb 2006 17:48:08 +0100 Subject: [Xorp-users] pimsm-RP placement Message-ID: <15c242670602060848t63624fexb652fd8e77855d7b@mail.gmail.com> May I place multicast clients behind the pimsm RP (rendezvous point) or should the RP be a separate router (with no multicast clients connected directly) ? ie. is it a valid configuration? [hostA]---[routerA]---[routerB=RP]---[hostB] where rouerA, routerB are pimsm routers and routerB is the RP hostA, hostB are multicast clients. Or shall I put the RP to a separate device to which no multicast client is connected directly: [hostA]---[routerA]---[routerC=RP]---[routerB]---[hostB] where rouerA, routerB, routerC are pimsm routers and routerC is the RP hostA, hostB are multicast clients. Thank you for any advice. Hajnalka From pavlin@icir.org Mon Feb 6 18:38:55 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 06 Feb 2006 10:38:55 -0800 Subject: [Xorp-users] pimsm-RP placement In-Reply-To: Message from =?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?= of "Mon, 06 Feb 2006 17:48:08 +0100." <15c242670602060848t63624fexb652fd8e77855d7b@mail.gmail.com> Message-ID: <200602061838.k16IctRd064945@possum.icir.org> > May I place multicast clients behind the pimsm RP (rendezvous point) > or should the RP be a separate router (with no multicast clients > connected directly) ? Either setup is correct. For simplicity, I'd recommend to go with the "[routerB=RP]" setup. Pavlin > ie. is it a valid configuration? > > [hostA]---[routerA]---[routerB=RP]---[hostB] > > where > rouerA, routerB are pimsm routers and routerB is the RP > hostA, hostB are multicast clients. > > Or shall I put the RP to a separate device to which no multicast > client is connected directly: > > [hostA]---[routerA]---[routerC=RP]---[routerB]---[hostB] > > where > rouerA, routerB, routerC are pimsm routers and routerC is the RP > hostA, hostB are multicast clients. > > Thank you for any advice. > Hajnalka > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Mon Feb 6 18:48:07 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 06 Feb 2006 10:48:07 -0800 Subject: [Xorp-users] Xorp delayed actions In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Mon, 06 Feb 2006 09:28:04 +0100." <29015745.1139214484725.JavaMail.root@pswm7.cp.tin.it> Message-ID: <200602061848.k16Im7qG065009@possum.icir.org> > Hi i made up some switching time test with xorp as follows: > 1)I set up > a network with two possible path to the same destination but with > different metric > 2)I start sending ip packets over this network towards > the destination node > 3)I turned up the metric of the old low cost path > to make it the the new higher cost one. > 4)I sniffed the ip traffic over > these links and i make this experiment lot of times > The thing i noticed > is that xorp needs 5 to 6 seconds to switch the traffic to the new low > cost path. > I thing that this time is too long but i also thing that it > could be because of some delayed action(like delayed spf scheduling or > delayed access to te routing table or whatever). > My questions are: > what > are the default delayed action that xorp does and their delay value? > Where can i find this information inside xorp code? What routing protocol are you running and how do you modify the routing metrics? In general, there are no (intentionally) delayed actions. If you use the "-v" option to the rtrmgr you can see extra information about various events, etc. Furthermore, if you set the XRLTRACE environmental variable before starting XORP you will see all the XRL-related events as well. Those can give you some ideas what is happening. Pavlin From atanu@ICSI.Berkeley.EDU Mon Feb 6 19:20:48 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 06 Feb 2006 11:20:48 -0800 Subject: [Xorp-users] Xorp delayed actions In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Mon, 06 Feb 2006 09:28:04 +0100." <29015745.1139214484725.JavaMail.root@pswm7.cp.tin.it> Message-ID: <55042.1139253648@tigger.icir.org> Hi, As a general principle in our routing protocol implementations we have tried to react immediately to a protocol packet (or other event) signalling a topology change. The one exception at the moment is OSPF, which, when it notices a topology change schedules a full routing computation to take place in 5 seconds (perhaps 1 second would be better choice). The optimal way of dealing with a routing change is to only recompute the affected part of the topology. The OSPF code was designed to perform incremental spf computation. Unfortunately some of the dependency tracking turned out to be very complicated and posed the danger of taking more time to compute than running the full computation. We made the pragmatic decision to complete the OSPF implementation and go back to the incremental computation at a later date when we had gained more experience with all the issues. Atanu. >>>>> "riccardo" == riccardo writes: riccardo> Hi i made up some switching time test with xorp as riccardo> follows: 1)I set up a network with two possible path to riccardo> the same destination but with different metric 2)I start riccardo> sending ip packets over this network towards the riccardo> destination node 3)I turned up the metric of the old low riccardo> cost path to make it the the new higher cost one. 4)I riccardo> sniffed the ip traffic over these links and i make this riccardo> experiment lot of times The thing i noticed is that xorp riccardo> needs 5 to 6 seconds to switch the traffic to the new low riccardo> cost path. I thing that this time is too long but i also riccardo> thing that it could be because of some delayed action(like riccardo> delayed spf scheduling or delayed access to te routing riccardo> table or whatever). My questions are: what are the riccardo> default delayed action that xorp does and their delay riccardo> value? Where can i find this information inside xorp riccardo> code? Thanks in advance for your help. riccardo> _______________________________________________ Xorp-users riccardo> mailing list Xorp-users@xorp.org riccardo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hasso@linux.ee Mon Feb 6 20:26:19 2006 From: hasso@linux.ee (Hasso Tepper) Date: Mon, 6 Feb 2006 22:26:19 +0200 Subject: [Xorp-users] Xorp delayed actions In-Reply-To: <55042.1139253648@tigger.icir.org> References: <55042.1139253648@tigger.icir.org> Message-ID: <200602062226.19453.hasso@linux.ee> Atanu Ghosh wrote: > As a general principle in our routing protocol implementations we have > tried to react immediately to a protocol packet (or other event) > signalling a topology change. The one exception at the moment is OSPF, > which, when it notices a topology change schedules a full routing > computation to take place in 5 seconds (perhaps 1 second would be > better choice). Sure, and subsecond would be even better. Actually adaptive timers should be really used in modern link state protocol implementation. IOS and Junos took different approaches with SPF timers. IOS uses exponential algorithm described in http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a0080134ad8.html Junos has taken much simpler approach. Only initial SPF interval is configurable - 50..1000 milliseconds (200ms by default). If there have been three sequential SPF runs with minimal delay (=> topology is unstable), Junos switches to 5 seconds spf delay (not configurable). If there have been no SPF run during 20 seconds (=> topology is stable again), Junos switches back to fast spf delay. I hope this helps. -- Hasso Tepper From hkontos@gmail.com Tue Feb 7 11:03:43 2006 From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=) Date: Tue, 7 Feb 2006 12:03:43 +0100 Subject: [Xorp-users] pimsm-RP placement In-Reply-To: <15c242670602070302u12d8624cscffd023effccaeb6@mail.gmail.com> References: <15c242670602060848t63624fexb652fd8e77855d7b@mail.gmail.com> <200602061838.k16IctRd064945@possum.icir.org> <15c242670602070302u12d8624cscffd023effccaeb6@mail.gmail.com> Message-ID: <15c242670602070303x25c58eefr1a423a368d14da63@mail.gmail.com> Thank you, Pavlin Hajnalka On 2/6/06, Pavlin Radoslavov wrote: > > May I place multicast clients behind the pimsm RP (rendezvous point) > > or should the RP be a separate router (with no multicast clients > > connected directly) ? > > Either setup is correct. > For simplicity, I'd recommend to go with the "[routerB=RP]" setup. > > Pavlin > From hkontos@gmail.com Tue Feb 7 11:08:04 2006 From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=) Date: Tue, 7 Feb 2006 12:08:04 +0100 Subject: [Xorp-users] role of pimreg interface Message-ID: <15c242670602070308r20a3232fs64bd6e9790459629@mail.gmail.com> What is the role of the pimreg interface? Is it used differently on a pimsm RP (rendezvous point) router than on non-RP routers ? Thank you, Hajnalka From riccardo.sciaccaluga@tin.it" Ok i understood that ospf represents the only routing protocols exception concerning to the reaction time. I understood from Atanu mail that xorp reacts with 5 seconds delay to topology changes but where can i find this information inside the code?i mean where is the variable setted up to 5 secs that represents this delay inside the code? Moreover is it possible to change it without any problem to a lower value? Thanks From pavlin@icir.org Tue Feb 7 18:08:19 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 07 Feb 2006 10:08:19 -0800 Subject: [Xorp-users] role of pimreg interface In-Reply-To: Message from =?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?= of "Tue, 07 Feb 2006 12:08:04 +0100." <15c242670602070308r20a3232fs64bd6e9790459629@mail.gmail.com> Message-ID: <200602071808.k17I8JRb095966@possum.icir.org> > What is the role of the pimreg interface? > Is it used differently on a pimsm RP (rendezvous point) router than on > non-RP routers ? It is used by the Designated Routers (DRs) and the RPs. On the DR side it is used for the encapsulation and transmission of the encapsulated PIM Register packets to the RP. On the RP side it is used for the receiving and decapsulation of those packets. Note that any PIM-SM router may be a DR (if it has a directly-connected source) hence it should be enabled on all routers. Even if you are 100% confident that a router won't have a directly-connected source, I still won't recommend disabling it, because the result may be unpredictable. Pavlin From hasso@linux.ee Tue Feb 7 18:12:03 2006 From: hasso@linux.ee (Hasso Tepper) Date: Tue, 7 Feb 2006 20:12:03 +0200 Subject: [Xorp-users] more detail on xorp delay In-Reply-To: <4322941.1139333759726.JavaMail.root@pswm13.cp.tin.it> References: <4322941.1139333759726.JavaMail.root@pswm13.cp.tin.it> Message-ID: <200602072012.04069.hasso@linux.ee> riccardo.sciaccaluga@tin.it wrote: > Ok i understood that ospf represents the only routing protocols > exception concerning to the reaction time. > I understood from Atanu mail > that xorp reacts with 5 seconds delay to topology changes but where can > i find this information inside the code?i mean where is the variable > setted up to 5 secs that represents this delay inside the code? > Moreover is it possible to change it without any problem to a lower > value? There shouldn't be problem. It's not configurable via cli though. It's set in ospf/area_router.cc:63. Just replace 5 with something smaller. -- Hasso Tepper From hkontos@gmail.com Tue Feb 7 18:34:03 2006 From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=) Date: Tue, 7 Feb 2006 19:34:03 +0100 Subject: [Xorp-users] role of pimreg interface In-Reply-To: <200602071808.k17I8JRb095966@possum.icir.org> References: <15c242670602070308r20a3232fs64bd6e9790459629@mail.gmail.com> <200602071808.k17I8JRb095966@possum.icir.org> Message-ID: <15c242670602071034xa7c97f0s1eb6503bc749147a@mail.gmail.com> If routerA----routerB are connected and both of them are using pimsm, then which will be selected as pimsm DR? Is there one pimsm DR per network segment? Is there an option to influence which router be the DR on a segment? Thank you, Hajnalka On 2/7/06, Pavlin Radoslavov wrote: > > What is the role of the pimreg interface? > > Is it used differently on a pimsm RP (rendezvous point) router than on > > non-RP routers ? > > It is used by the Designated Routers (DRs) and the RPs. > On the DR side it is used for the encapsulation and transmission of > the encapsulated PIM Register packets to the RP. > On the RP side it is used for the receiving and decapsulation of > those packets. > > Note that any PIM-SM router may be a DR (if it has a > directly-connected source) hence it should be enabled on all > routers. Even if you are 100% confident that a router won't have a > directly-connected source, I still won't recommend disabling it, > because the result may be unpredictable. > > Pavlin > From pavlin@icir.org Tue Feb 7 18:53:53 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 07 Feb 2006 10:53:53 -0800 Subject: [Xorp-users] role of pimreg interface In-Reply-To: Message from =?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?= of "Tue, 07 Feb 2006 19:34:03 +0100." <15c242670602071034xa7c97f0s1eb6503bc749147a@mail.gmail.com> Message-ID: <200602071853.k17Irr8S098654@possum.icir.org> > If routerA----routerB are connected and both of them are using pimsm, > then which will be selected as pimsm DR? Is there one pimsm DR per > network segment? Is there an option to influence which router be the > DR on a segment? Yes, there is only one DR per network segment. Section 4.3.2 in the PIM-SM spec (draft-ietf-pim-sm-v2-new-11.txt) describes the election algorithm in details. In summary, the router with the largest DR Priority is the DR; if there is a tie, then the router with the larger primary IP address is the DR. Note that if there are legacy PIM routers that don't support the DR Priority Hello option, then only the IP addresses are used in the election. In XORP you can configure the DR Priority with the pimsm4/interface/vif/dr-priority configuration option. See the sample rtrmgr/config.boot.sample and the XORP user manual for details. Pavlin From acb@cs.princeton.edu Tue Feb 7 21:04:12 2006 From: acb@cs.princeton.edu (Andy Bavier) Date: Tue, 07 Feb 2006 16:04:12 -0500 Subject: [Xorp-users] OSPF LSA trigger? Message-ID: <43E90B4C.6060301@cs.princeton.edu> This is a multi-part message in MIME format. --------------060001040300080405060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, What triggers XORP's OSPF to send out a new LSA? I'm running a test network of about 11 XORP routers built from the head of the CVS tree. OSPF establishes adjacencies when the routers come up, configures the FIBs as expected, and continues to send out Hello messages over time. However, when I commit a change in xorpsh (modify the interface cost, delete a neighbour, etc.), nothing much seems to happen. For example, if I disable a neighbour's interface, then no more Hello messages are exchanged with it and eventually it is marked as Down -- but no new LSAs are generated, and the routes through that neighbour are not removed. Is there some specific event that needs to be triggered before LSAs are sent? Any ideas or tips? I'm attaching a config file in case that's useful. The config may look weird -- I'm using XORP to control a Click forwarder that's sitting on the other side of a TUN/TAP interface -- but everything is working except for the "dynamic" part of OSPF. Thanks! Andy --------------060001040300080405060200 Content-Type: text/plain; name="planetlab1.chin.internet2.planet-lab.org.xorp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="planetlab1.chin.internet2.planet-lab.org.xorp" /* Configuration for planetlab1.chin.internet2.planet-lab.org */ /* Generated at Tue Feb 07 15:46:58 EST 2006 */ interfaces { interface tap0 { description: "virtual overlay interface"; disable: false default-system-config } interface eth0 { description: "ethernet adapter" disable: false default-system-config } } fea { unicast-forwarding4 { disable: true } click { disable: false user-click { disable: false command-file: "/home/mit_rcp/demo/click" command-extra-arguments: "-R" command-execute-on-startup: true control-address: 127.0.0.1 control-socket-port: 13654 startup-config-file: "/dev/null" user-click-config-generator-file: "/home/mit_rcp/demo/static_config" } } } protocols { ospf4 { router-id: 198.32.154.178 area 0.0.0.0 { interface tap0 { link-type: "p2m" vif tap0 { address 10.0.217.1 { interface-cost: 1 /* planetlab1.ipls.internet2.planet-lab.org */ neighbour 10.0.116.1 { router-id: 198.32.154.242 } /* planetlab1.nycm.internet2.planet-lab.org */ neighbour 10.0.114.1 { router-id: 198.32.154.250 } } } } } traceoptions { flag { all { disable: false } } } } } --------------060001040300080405060200-- From caddisconsulting@yahoo.com Tue Feb 7 21:27:15 2006 From: caddisconsulting@yahoo.com (Mike Horn) Date: Tue, 7 Feb 2006 14:27:15 -0700 Subject: [Xorp-users] OSPF LSA trigger? In-Reply-To: <43E90B4C.6060301@cs.princeton.edu> Message-ID: <006801c62c2d$44a98a70$6402a8c0@caddisconsulting.com> Hi Andy, When did you download the CVS head? There was a fix last week on 2/1 for bug 387 which was for OSPF not sending out an updated router-LSA when the link state of an interface that was included in OSPF changed. I checked the fix yesterday and the router now correctly sends out LSA updates for link state changes. You should also see a new router-LSA generated if you configure an interface to run OSPF, then commit, then add another interface to the OSPF configuration. Finally, another way to get OSPF to transmit an LSA is to create a policy redistributing static routes into OSPF, this will generate AS-external-LSAs. Let me know if you want a sample configuration. -mike -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Andy Bavier Sent: Tuesday, February 07, 2006 2:04 PM To: Xorp-users@xorp.org Subject: [Xorp-users] OSPF LSA trigger? Hi, What triggers XORP's OSPF to send out a new LSA? I'm running a test network of about 11 XORP routers built from the head of the CVS tree. OSPF establishes adjacencies when the routers come up, configures the FIBs as expected, and continues to send out Hello messages over time. However, when I commit a change in xorpsh (modify the interface cost, delete a neighbour, etc.), nothing much seems to happen. For example, if I disable a neighbour's interface, then no more Hello messages are exchanged with it and eventually it is marked as Down -- but no new LSAs are generated, and the routes through that neighbour are not removed. Is there some specific event that needs to be triggered before LSAs are sent? Any ideas or tips? I'm attaching a config file in case that's useful. The config may look weird -- I'm using XORP to control a Click forwarder that's sitting on the other side of a TUN/TAP interface -- but everything is working except for the "dynamic" part of OSPF. Thanks! Andy From acb@cs.princeton.edu Tue Feb 7 21:54:28 2006 From: acb@cs.princeton.edu (Andy Bavier) Date: Tue, 07 Feb 2006 16:54:28 -0500 Subject: [Xorp-users] OSPF LSA trigger? In-Reply-To: <006801c62c2d$44a98a70$6402a8c0@caddisconsulting.com> References: <006801c62c2d$44a98a70$6402a8c0@caddisconsulting.com> Message-ID: <43E91714.7070809@cs.princeton.edu> Mike, I updated with the head last night so I should have the bug fix. It would be great if you can send me a working sample configuration, maybe that will reveal my problem. Also I'll try your other suggestions. Thanks, Andy Mike Horn wrote: > Hi Andy, > > When did you download the CVS head? There was a fix last week on 2/1 for > bug 387 which was for OSPF not sending out an updated router-LSA when the > link state of an interface that was included in OSPF changed. I checked the > fix yesterday and the router now correctly sends out LSA updates for link > state changes. > > You should also see a new router-LSA generated if you configure an interface > to run OSPF, then commit, then add another interface to the OSPF > configuration. > > Finally, another way to get OSPF to transmit an LSA is to create a policy > redistributing static routes into OSPF, this will generate AS-external-LSAs. > Let me know if you want a sample configuration. > > -mike > > -----Original Message----- > From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf > Of Andy Bavier > Sent: Tuesday, February 07, 2006 2:04 PM > To: Xorp-users@xorp.org > Subject: [Xorp-users] OSPF LSA trigger? > > Hi, > > What triggers XORP's OSPF to send out a new LSA? I'm running a test network > of about 11 XORP routers built from the head of the CVS tree. > OSPF establishes adjacencies when the routers come up, configures the FIBs > as expected, and continues to send out Hello messages over time. > However, when I commit a change in xorpsh (modify the interface cost, delete > a neighbour, etc.), nothing much seems to happen. For example, if I disable > a neighbour's interface, then no more Hello messages are exchanged with it > and eventually it is marked as Down -- but no new LSAs are generated, and > the routes through that neighbour are not removed. > > Is there some specific event that needs to be triggered before LSAs are > sent? Any ideas or tips? I'm attaching a config file in case that's > useful. The config may look weird -- I'm using XORP to control a > Click forwarder that's sitting on the other side of a TUN/TAP interface > -- but everything is working except for the "dynamic" part of OSPF. > > Thanks! > Andy > From hkontos@gmail.com Wed Feb 8 10:05:41 2006 From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=) Date: Wed, 8 Feb 2006 11:05:41 +0100 Subject: [Xorp-users] role of pimreg interface In-Reply-To: <200602071853.k17Irr8S098654@possum.icir.org> References: <15c242670602071034xa7c97f0s1eb6503bc749147a@mail.gmail.com> <200602071853.k17Irr8S098654@possum.icir.org> Message-ID: <15c242670602080205h16bc04b2s42cf976493b0408e@mail.gmail.com> Thank you very much, Pavlin. Hajnalka On 2/7/06, Pavlin Radoslavov wrote: > > If routerA----routerB are connected and both of them are using pimsm, > > then which will be selected as pimsm DR? Is there one pimsm DR per > > network segment? Is there an option to influence which router be the > > DR on a segment? > > Yes, there is only one DR per network segment. Section 4.3.2 in the > PIM-SM spec (draft-ietf-pim-sm-v2-new-11.txt) describes the election > algorithm in details. > In summary, the router with the largest DR Priority is the DR; if > there is a tie, then the router with the larger primary IP address > is the DR. > Note that if there are legacy PIM routers that don't support the DR > Priority Hello option, then only the IP addresses are used in the > election. > > In XORP you can configure the DR Priority with the > pimsm4/interface/vif/dr-priority configuration option. > See the sample rtrmgr/config.boot.sample and the XORP user manual > for details. > > Pavlin > From dave.price@aber.ac.uk Wed Feb 8 16:18:23 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 08 Feb 2006 16:18:23 +0000 Subject: [Xorp-users] Any idea when 1.2 as live CD will appear? Message-ID: <1645.1139415503@aber.ac.uk> Dear All, I currently have an old machine running xorp 1.0 off a liveCD and I was about to swap over to 1.1 but I notice xorp website has "jan 2006" as target date for 1.2 in roadmap. Any idea when it will appear as liveCD? Should I wait? Thanks, Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- From riccardo.sciaccaluga@tin.it" according to the ospf experiment i did and taking in account xorp router_recompute_delay of 5 secs....i still found a switching time of almost two seconds. Because of i placed a timestamp in dijkstra calculation and because i saw that dijkstra calcultion employ just 0,1s ......i don't know why the switching time is around 2 sec. Are there any other delay setted up on ospf code?...like a delay between calculating the new best route and placing it inside the rotuing table or something like that? From kristian@juniks.net Wed Feb 8 18:55:37 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 8 Feb 2006 19:55:37 +0100 Subject: [Xorp-users] Any idea when 1.2 as live CD will appear? In-Reply-To: <1645.1139415503@aber.ac.uk> References: <1645.1139415503@aber.ac.uk> Message-ID: <20060208185537.GB32409@juniks.net> On Wed, Feb 08, 2006 at 04:18:23PM +0000, Dave Price wrote: > Dear All, > > I currently have an old machine running xorp 1.0 off a liveCD > and I was about to swap over to 1.1 but I notice xorp website > has "jan 2006" as target date for 1.2 in roadmap. > > Any idea when it will appear as liveCD? Should I wait? The release is a bit overdue and I would recommend you to use the CVS version during the meantime. Kristian. From atanu@ICSI.Berkeley.EDU Wed Feb 8 20:23:16 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 08 Feb 2006 12:23:16 -0800 Subject: [Xorp-users] Still too long switching time In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" of "Wed, 08 Feb 2006 19:33:49 +0100." <26402512.1139423629247.JavaMail.root@pswm10.cp.tin.it> Message-ID: <88110.1139430196@tigger.icir.org> Hi, Once the SPF computation has been triggered there are no other configured delays that I can remember. If as a result of the SPF computation routes have changed then the delta route information is sent to the RIB. If the routes from OSPF win over routes from other protocols the routes are sent to the FEA. The FEA then adds or deletes the routes from the kernel. Please note a new LSA may trigger a SPF computation but this doesn't have to mean that the routing table will change. The other thing to note is that SPF computation in OSPF is only part of the routing computation. In the base OSPF specification five different LSAs are defined, the SPF computation only uses two LSAs (router-LSA and network-LSA). After the SPF computation is performed the summary-LSAs and AS-External-LSAs are processed to see if the networks they describe are reachable via the graph built in the SPF computation. Atanu. >>>>> "riccardo" == riccardo writes: riccardo> according to the ospf experiment i did and taking in riccardo> account xorp router_recompute_delay of 5 secs....i still riccardo> found a switching time of almost two seconds. Because of riccardo> i placed a timestamp in dijkstra calculation and because i riccardo> saw that dijkstra calcultion employ just 0,1s ......i riccardo> don't know why the switching time is around 2 sec. Are riccardo> there any other delay setted up on ospf code?...like a riccardo> delay between calculating the new best route and placing riccardo> it inside the rotuing table or something like that? riccardo> _______________________________________________ Xorp-users riccardo> mailing list Xorp-users@xorp.org riccardo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From lists@pjb.homelinux.net Thu Feb 9 03:39:39 2006 From: lists@pjb.homelinux.net (lists) Date: Wed, 8 Feb 2006 22:39:39 -0500 (EST) Subject: [Xorp-users] Multicast routing between interfaces Message-ID: <10701.209.87.229.138.1139456379.squirrel@pjb.homelinux.net> Hi, I recently set up a Xorp box which has four interfaces - site1, site2, site3, site4. Each site is on a different subnet with appropriate subnet mask. I am interested in multicast routing between these interfaces and believe I have set Xorp up to do this. However, I believe that rather than routing multicast between the interfaces, it is simply snooping on the multicast traffic on each interface and not actually routing (the 'show igmp group' command does show the multicast groups I expect on each interface correctly). Most of the multicast traffic is voice - and with two transmitting/receiving PCs on a single subnet connected with a crossover cable everything works OK (traffic is seen on 224.1.0.1 and 224.1.0.3). However, if I put the first PC on fxp0 and the second on fxp1 (with appropriate IP, netmask and gateway settings), I see groups 224.1.0.1 and 224.1.0.3 on fxp0 and groups 224.1.0.1 and 224.1.0.3 on fxp1, but no data is passed between the PCs. Any input would be greatly appreciated - my xorp.cfg (with part of the IPs masked) is below: /*XORP Configuration File, v1.0*/ interfaces { interface rl0 { description: "site1" vif rl0 { disable: false address xxx.xxx.84.206 { prefix-length: 28 disable: false broadcast: xxx.xxx.84.207 } } disable: false discard: false } interface fxp0 { description: "site2" vif fxp0 { disable: false address xxx.xxx.84.30 { prefix-length: 27 disable: false broadcast: xxx.xxx.84.31 } } disable: false discard: false } interface fxp1 { description: "site3" vif fxp1 { disable: false address xxx.xxx.84.94 { prefix-length: 27 disable: false broadcast: xxx.xxx.84.95 } } disable: false discard: false } interface xl0 { description: "site4" vif xl0 { disable: false address xxx.xxx.84.174 { prefix-length: 28 disable: false broadcast: xxx.xxx.84.175 } } disable: false discard: false } interface lo0 { description: "Loopback interface" vif lo0 { disable: false } disable: false discard: false } targetname: "fea" } fea { unicast-forwarding4 { disable: false } targetname: "fea" } plumbing { mfea4 { targetname: "MFEA_4" disable: false interface fxp0 { vif fxp0 { disable: false } } interface fxp1 { vif fxp1 { disable: false } } interface rl0 { vif rl0 { disable: false } } interface xl0 { vif xl0 { disable: false } } } } protocols { igmp { targetname: "IGMP" disable: false interface fxp0 { vif fxp0 { disable: false } } interface fxp1 { vif fxp1 { disable: false } } interface rl0 { vif rl0 { disable: false } } interface xl0 { vif xl0 { disable: false } } } } From pavlin@icir.org Thu Feb 9 03:47:24 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 08 Feb 2006 19:47:24 -0800 Subject: [Xorp-users] Multicast routing between interfaces In-Reply-To: Message from "lists" of "Wed, 08 Feb 2006 22:39:39 EST." <10701.209.87.229.138.1139456379.squirrel@pjb.homelinux.net> Message-ID: <200602090347.k193lOV9095999@possum.icir.org> > I recently set up a Xorp box which has four interfaces - site1, site2, > site3, site4. Each site is on a different subnet with appropriate subnet > mask. > > I am interested in multicast routing between these interfaces and believe > I have set Xorp up to do this. > > However, I believe that rather than routing multicast between the > interfaces, it is simply snooping on the multicast traffic on each > interface and not actually routing (the 'show igmp group' command does > show the multicast groups I expect on each interface correctly). > > Most of the multicast traffic is voice - and with two > transmitting/receiving PCs on a single subnet connected with a crossover > cable everything works OK (traffic is seen on 224.1.0.1 and 224.1.0.3). > However, if I put the first PC on fxp0 and the second on fxp1 (with > appropriate IP, netmask and gateway settings), I see groups 224.1.0.1 and > 224.1.0.3 on fxp0 and groups 224.1.0.1 and 224.1.0.3 on fxp1, but no data > is passed between the PCs. > > Any input would be greatly appreciated - my xorp.cfg (with part of the IPs > masked) is below: You must configure PIM-SM. Hence, you would also have to configure the fib2mrib module, and the register_vif interface inside mfea4. Pavlin > > /*XORP Configuration File, v1.0*/ > interfaces { > interface rl0 { > description: "site1" > vif rl0 { > disable: false > address xxx.xxx.84.206 { > prefix-length: 28 > disable: false > broadcast: xxx.xxx.84.207 > } > } > disable: false > discard: false > } > interface fxp0 { > description: "site2" > vif fxp0 { > disable: false > address xxx.xxx.84.30 { > prefix-length: 27 > disable: false > broadcast: xxx.xxx.84.31 > } > } > disable: false > discard: false > } > interface fxp1 { > description: "site3" > vif fxp1 { > disable: false > address xxx.xxx.84.94 { > prefix-length: 27 > disable: false > broadcast: xxx.xxx.84.95 > } > } > disable: false > discard: false > } > interface xl0 { > description: "site4" > vif xl0 { > disable: false > address xxx.xxx.84.174 { > prefix-length: 28 > disable: false > broadcast: xxx.xxx.84.175 > } > } > disable: false > discard: false > } > interface lo0 { > description: "Loopback interface" > vif lo0 { > disable: false > } > disable: false > discard: false > } > targetname: "fea" > } > fea { > unicast-forwarding4 { > disable: false > } > targetname: "fea" > } > plumbing { > mfea4 { > targetname: "MFEA_4" > disable: false > interface fxp0 { > vif fxp0 { > disable: false > } > } > interface fxp1 { > vif fxp1 { > disable: false > } > } > interface rl0 { > vif rl0 { > disable: false > } > } > interface xl0 { > vif xl0 { > disable: false > } > } > } > } > protocols { > igmp { > targetname: "IGMP" > disable: false > interface fxp0 { > vif fxp0 { > disable: false > } > } > interface fxp1 { > vif fxp1 { > disable: false > } > } > interface rl0 { > vif rl0 { > disable: false > } > } > interface xl0 { > vif xl0 { > disable: false > } > } > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Thu Feb 16 00:15:41 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 15 Feb 2006 16:15:41 -0800 Subject: [Xorp-users] Any idea when 1.2 as live CD will appear? In-Reply-To: Message from Kristian Larsson of "Wed, 08 Feb 2006 19:55:37 +0100." <20060208185537.GB32409@juniks.net> Message-ID: <200602160015.k1G0Ff40036919@possum.icir.org> > On Wed, Feb 08, 2006 at 04:18:23PM +0000, Dave Price wrote: > > Dear All, > > > > I currently have an old machine running xorp 1.0 off a liveCD > > and I was about to swap over to 1.1 but I notice xorp website > > has "jan 2006" as target date for 1.2 in roadmap. > > > > Any idea when it will appear as liveCD? Should I wait? > The release is a bit overdue and I would recommend > you to use the CVS version during the meantime. Hopefully very soon there will be a release candidate. Typically, two weeks after the release candidate is the release itself. Pavlin From riccardo.sciaccaluga@tin.it" Hi Is there already implemented in Xorp any traffic managing policy that gives a priority to ospf packet rather than IP packet in a traffic congestions situation? From bms@spc.org Tue Feb 21 17:29:13 2006 From: bms@spc.org (Bruce M Simpson) Date: Tue, 21 Feb 2006 17:29:13 +0000 Subject: [Xorp-users] traffic policy In-Reply-To: <17797379.1140515534677.JavaMail.root@pswm14.cp.tin.it> References: <17797379.1140515534677.JavaMail.root@pswm14.cp.tin.it> Message-ID: <20060221172913.GB87334@spc.org> On Tue, Feb 21, 2006 at 10:52:14AM +0100, riccardo.sciaccaluga@tin.it wrote: > Is there already implemented in Xorp any traffic managing policy > that gives a priority to ospf packet rather than IP packet in a traffic > congestions situation? XORP doesn't currently do this. I believe quagga does a setsockopt() of IP_TOS to IP_TOS_PREC_INTERNETCONTROL. To do it unconditionally is a small change, but this wouldn't be the correct behaviour -- the TOS bits should only be changed, in my opinion, with an explicit XRL call. I'd be more than happy to see patches for this. Regards, BMS From bms@spc.org Tue Feb 21 17:42:17 2006 From: bms@spc.org (Bruce M Simpson) Date: Tue, 21 Feb 2006 17:42:17 +0000 Subject: [Xorp-users] traffic policy In-Reply-To: <20060221172913.GB87334@spc.org> References: <17797379.1140515534677.JavaMail.root@pswm14.cp.tin.it> <20060221172913.GB87334@spc.org> Message-ID: <20060221174217.GN25822@spc.org> On Tue, Feb 21, 2006 at 05:29:13PM +0000, Bruce M Simpson wrote: > XORP doesn't currently do this. > I believe quagga does a setsockopt() of IP_TOS to IP_TOS_PREC_INTERNETCONTROL. Just for the record, Windows doesn't support explicitly setting the ToS bits any more: http://support.microsoft.com/kb/248611/en-us ... so doing this the 'old' way is non-portable, they deprecated it in favour of DiffServ. On a Layer 2 QoS note: It also appears that FreeBSD doesn't support 802.1p encapsulation properly. 802.1p causes sent and received Ethernet frames to be encapsulated with 802.1q VLAN tags having a vlan ID of 0. FreeBSD needs fixing to sort this one out, as currently it drops tagged frames if no vlans are configured. 802.1p traffic would trigger this. Regards, BMS From pavlin@icir.org Tue Feb 21 20:30:34 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 21 Feb 2006 12:30:34 -0800 Subject: [Xorp-users] traffic policy In-Reply-To: Message from Bruce M Simpson of "Tue, 21 Feb 2006 17:29:13 GMT." <20060221172913.GB87334@spc.org> Message-ID: <200602212030.k1LKUYcQ096728@possum.icir.org> > On Tue, Feb 21, 2006 at 10:52:14AM +0100, riccardo.sciaccaluga@tin.it wrote: > > Is there already implemented in Xorp any traffic managing policy > > that gives a priority to ospf packet rather than IP packet in a traffic > > congestions situation? > > XORP doesn't currently do this. > I believe quagga does a setsockopt() of IP_TOS to IP_TOS_PREC_INTERNETCONTROL. > > To do it unconditionally is a small change, but this wouldn't be the > correct behaviour -- the TOS bits should only be changed, in my opinion, > with an explicit XRL call. I don't know whether the original question was about the ip_tos IP header packet field, but the XORP raw socket XRL interface already supports setting ip_tos (see raw_packet4/0.1/send XRL). That XRL interface also supports setting the IP Router Alert option. Furthermore, if the IP Router Alert flag is enabled, but the ip_tos is unset, then the FEA internally will set the ip_tos to IPTOS_PREC_INTERNETCONTROL. FYI, currently the IP Router Alert option is disabled for OSPF, and is enabled for IGMP and PIM. If the original question was about something else, then the answer is that in the control plane we don't do anything special about traffic management. Pavlin From riccardo.sciaccaluga@tin.it" Sorry my question was bad done! I don't wanna know about priority within IP packet flows but about this: In a topology configuration like this ForwardingMachine---->Xorp machine---->>traffic destination machine. Xorp pc has two interfaces running OPSF protocol towards the Fw and destination machines. The Fw machine is forwarding an IP traffic flows higher then the forwarding ability of xorp pc. So, xorp pc will start to drop packets. I am asking my self if it drops just IP packets saving OPSF one (protecting the opsf link) or it drops IP packets and ospf packets without any difference? From bms@spc.org Wed Feb 22 08:45:12 2006 From: bms@spc.org (Bruce M Simpson) Date: Wed, 22 Feb 2006 08:45:12 +0000 Subject: [Xorp-users] question bad done In-Reply-To: <11809490.1140596058609.JavaMail.root@pswm5.cp.tin.it> References: <11809490.1140596058609.JavaMail.root@pswm5.cp.tin.it> Message-ID: <20060222084512.GC89218@spc.org> Hi there. This is a bit of a detailed explanation because I'm currently reviewing Layer 2 and Layer 3 QoS support across the board. On Wed, Feb 22, 2006 at 09:14:18AM +0100, riccardo.sciaccaluga@tin.it wrote: > Sorry my question was bad done! > I don't wanna know about priority > within IP packet flows but about this: > In a topology configuration like > this ForwardingMachine---->Xorp machine---->>traffic destination > machine. > Xorp pc has two interfaces running OPSF protocol towards the > Fw and destination machines. > The Fw machine is forwarding an IP traffic > flows higher then the forwarding ability of xorp pc. > So, xorp pc will > start to drop packets. > I am asking my self if it drops just IP packets > saving OPSF one (protecting the opsf link) or it drops IP packets and > ospf packets without any difference? This isn't really a XORP issue; XORP only provides a router control plane, not a forwarding plane or a TCP/IP stack. If the machine on which you are running XORP isn't configured to prioritize delivery of the OSPF traffic in some way, then yes, it is possible that the traffic could be dropped. This is a function of the TCP/IP stack in the host operating system, and the network card driver. If running Linux or BSD, you could configure some form of priority queueing e.g. in IPTABLES, IPFW or PF. Windows has support for RSVP and DiffServ since Windows 2000, but we don't currently do anything with it -- you'd have to configure an inbound flow explicitly with TCMON.EXE from the Resource Kit. This doesn't offer any guarantees that the traffic will actually be delivered to user-space, where XORP lives; if you saturate the buffers in your XORP PC's Ethernet card (I'm assuming you're using an Ethernet link layer here (+)), then traffic of any kind will be dropped, not just OSPF or indeed IPv4, and this condition will most likely manifest itself in the form of high interrupt load, creating bigger problems. The place to look for the drop, if it's badly affecting performance, is the network card and its driver. If the card supports 802.1p (*) Packet Priority in hardware, this might improve things, but Ethernet as a rule only offers best-effort delivery because of the nature of the MAC protocol. Regards, BMS (+) If you're running XORP with a non-Ethernet link layer, please tell us! (*) FreeBSD doesn't currently support 802.1p correctly -- you need to configure a VLAN for it to work. From atanu@ICSI.Berkeley.EDU Thu Feb 23 04:01:13 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 22 Feb 2006 20:01:13 -0800 Subject: [Xorp-users] Announcing XORP Release Candidate 1.2 Message-ID: <85266.1140667273@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.2 Release Candidate, which is now available from . Once the release candidate has proven to be stable, the actual 1.2 release will be prepared. This is planned to occur in the next two weeks. In the intervening period we will be fixing minor problems and updating the documentation. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.3 release; these are documented in the errata section below. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team P.S. Release notes and errata are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.2-RC (2006/02/22) ========================= ALL: [Note: this is XORP-1.2-RC release candidate and not all documentation is up to date. Also, the list below with the changes since the XORP-1.1 release is incomplete.] - Many improvements, bug fixes and cleanup. - The third-party ospfd implementation is replaced with a new OSPF implementation developed from scratch. CONFIGURATION: - Addition of new interface related configuration statement: * restore-original-config-on-shutdown: This optional statement is used to enable the restoring of the original network interface information on shutdown. - Addition of new PIM-SM related configuration statements: * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * cand-bsr-by-vif-addr: and * cand-rp-by-vif-addr: Those optional statements are used together with cand-bsr-by-vif-name and cand-rp-by-vif-name respectively to specify the particular IP address on the configured vif. If they are omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself. * hello-period: This optional statement is used to configure the PIM Hello messages period (in seconds). * hello-triggered-delay: This optional statement is used to configure the randomized triggered delay of the PIM Hello messages (in seconds). - Addition of new MLD/IGMP related configuration statements: * version: This optional statement is used to configure the MLD/IGMP protocol version per virtual interface. * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * query-interval: This optional statement is used to specify (per virtual interface) the interval between general queries. * query-last-member-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into group-specific queries sent in response to leave group messages. * query-response-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into the periodic general queries. * robust-count: This optional statement is used to specify (per virtual interface) the robustness variable count that allows tuning for the expected packet loss on a subnet. - Addition of support for user environmental variables CFLAGS_END and CXXFLAGS_END. Those variables can be used to specify the compiler flags (for the C and C++ compiler respectively) that must be after all other flags. LIBXORP: - Various improvements in the RunCommand implementation. LIBXIPC: - No significant changes. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Generalization of the %mandatory keyword syntax so now it can be used to specify any node or variable (multi-value nodes excluded) in the configuration tree. Previously it could be used to specify only configuration child nodes or variables. - Addition of support for read-only, permanent and user-hidden nodes (specified respectively by the new %read-only, %permanent and %user-hidden template commands). - Modification of the %allow and %allow-range semantics so a help string can be supplied for each allowed value or range. - Removal of the mechanism for specifying the hook for saving a configuration file (the "-s " command-line argument). The mechanism is broken and is superseded by the rtrmgr template support for running external programs. - Various other improvements and bug fixes. XORPSH: - Addition of support to run xorpsh in non-interactive mode. - Modification of the configurational mode "show" command so now it displays parameters only if their value is not same as the default value. - Addition of command "show -all" that shows the complete configuration including the parameters with default values. - Modification to the "show" command output: in configuration mode all deleted (and uncommitted) entries are prefixed with "-". - Modification of the default operational and configuration mode prompts to "user@hostname> " and "user@hostname# " respectively. - Addition of support to modify the operational and configuration mode prompts by environmental variables XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION respectively. - Addition of support for command-line completion for allowed values. - Various other improvements and bug fixes. POLICY: - Several bug fixes. FEA/MFEA: - Addition of RawSocket{4,6} generic abstraction that is not multicast-specific. RIB: - Addition of support for displaying the routing tables in brief, detailed and terse format. The default format is "brief". RIP: - The syntax for configuring the authentication mechanism has changed: OLD: authentication { type: "plaintext" password: "FOO" } OR authentication { type: "md5" password: "FOO" } NEW: authentication { simple-password: "FOO" } OR authentication { md5 1 { /* KeyID: [0, 255] */ password: "FOO" start-time: "YYYY-MM-DD.HH:MM" end-time: "YYYY-MM-DD.HH:MM" } } - Several bug fixes. OSPF: - Initial implementation of OSPF that replaces the third-party ospfd. BGP: - The network4/network6 directives have been deprecated. If you wish to inject static routes into BGP, you must now add these routes to the static_routes protocol block, and then configure the policy engine to redistribute them to BGP. - Proper support for policy filters. - Addition of support for route flap damping. - Addition of support for route aggregation. - Addition of support for route reflection. - Addition of support for confederations. - Bug fix to correctly handle connection collisions. - Addition of default support for NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED well-known communities. - Addition of the capability to reconfigure a peering (e.g., from IBGP to EBGP) which requires re-configuring the default filters. - Numerous bug fixes that should greatly improve stability. STATIC_ROUTES: - Several bug fixes. MLD/IGMP: - No significant changes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-11.{ps,txt}). - Addition of support to disable the "wrong iif" kernel upcall on interfaces we don't need to monitor. - Bug fix related to the handling of the deleted MRIB entries. - Bug fix related to transmitting AssertCancel message when a PIM configured interface is gracefully shutdown. FIB2MRIB: - No significant changes. CLI: - Various improvements and bug fixes. SNMP: - No significant changes. ------------------------------------------------------------------ XORP ERRATA ALL: - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines. The simplest work-around is to rerun gmake or not to use the -j flag. - The following compiler is known to be buggy, and should not be used to compile XORP: gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD] A newer compiler such as the following should be used instead: gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD] - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time, the propagation latency for the BGP routes to reach the kernel is increased. We are investigating the problem. LIBXORP: - No known issues. LIBXIPC: - No known issues. LIBFEACLIENT: - No known issues. XRL: - No known issues. RTRMGR: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi - Using the rtrmgr "-r" command-line option to restart processes that have failed does not work if a process fails while being reconfigured via xorpsh. If that happens, the rtrmgr itself may coredump. Therefore, using the "-r" command-line option is not recommended! Also, note that a process that has been killed by SIGTERM or SIGKILL will not be restarted (this is a feature rather than a bug). Ideally, we want to monitor the processes status using the finder rather than the forked children process status, therefore in the future when we have a more robust implementation the "-r" switch will be removed and will be enabled by default. XORPSH: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi FEA/MFEA: - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358), some of the tests may fail (with or without an error message), but no coredump image. Some of those failures can be contributed to a kernel problem. E.g., running "dmesg can show kernel "Oops" messages like: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 02235532 *pde = 00000000 Oops: 0000 [#15] CPU: 0 EIP: 0060:[<02235532>] Not tainted EFLAGS: 00010202 (2.6.5-1.358) EIP is at __dev_get_by_index+0x14/0x2b eax: 022db854 ebx: 1ae7aef8 ecx: 00000001 edx: 00000000 esi: 00000000 edi: 00008910 ebp: fee43e9c esp: 1ae7aef0 ds: 007b es: 007b ss: 0068 Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0) Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780 0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c 07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001 Call Trace: [<022365c7>] dev_ifname+0x30/0x66 [<02236e50>] dev_ioctl+0x83/0x283 [<0227a55b>] unix_create1+0xef/0xf7 [<021536b6>] alloc_inode+0xf9/0x175 [<0227c090>] unix_ioctl+0x72/0x7b [<022301a5>] sock_ioctl+0x268/0x280 [<0223054f>] sys_socket+0x2a/0x3d [<0214ea0e>] sys_ioctl+0x1f2/0x224 Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME) which itself is called by if_indextoname(3). Currently, there is no known solution of the problem except to use a kernel that does not have the problem (at this stage it is not known whether all 2.6 Linux kernels are affected or only specific versions). It seems that a very similar problem has been reported to the Linux kernel developers, but the problem is still unsolved: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 - The mechanism for tracking the network interface link status may not work for the following OS-es because the kernel for those systems does not provide a mechanism for asynchronous notification of userland programs when the link status changes: FreeBSD-5.2 and earlier and MacOS X (note: if the Windows kernel supports this feature, it is not used yet in XORP). Though, for those systems the link status should be read properly on startup. RIB: - In some rare cases, the RIB may fail to delete an existing route (See http://www.xorp.org/bugzilla/show_bug.cgi?id=62). We are aware of the issue and will attempt to fix it in the future. RIP: - No known issues. OSPF: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi BGP: - If the RIB bug above (failure to delete an existing route) is triggered by BGP, then the deletion failure error received by BGP from the RIB is considered by BGP as a fatal error. This is not a BGP problem, but a RIB problem that will be fixed in the future. - The BGP configuration mandates that an IPv4 nexthop must be supplied. Unfortunately it is necessary to provide an IPv4 nexthop even for an IPv6 only peering. Even more unfortunately it is not possible to force the IPv6 nexthop. - It is *essential* for an IPv6 peering that an IPv6 nexthop is provided. Unfortunately the configuration does not enforce this requrement. This will be fixed in the future. STATIC_ROUTES: - No known issues. MLD/IGMP: - If MLD/IGMP is started with a relatively large number of interfaces (e.g., on the order of 20), then it may fail with the following error: [ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666 mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2 on vif eth8: No buffer space available The solution is to increase the multicast group membership limit. E.g., to increase the value from 20 (the default) to 200, run as a root: echo 200 > /proc/sys/net/ipv4/igmp_max_memberships PIM-SM: - If the kernel does not support PIM-SM, or if PIM-SM is not enabled in the kernel, then running PIM-SM will fail with the following error message: [ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported - On Linux, if the unicast Reverse Path Forwarding information is different from the multicast Reverse Path Forwarding information, the Reverse Path Filtering should be disabled. E.g., as root: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter OR echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter ... Otherwise, the router will ignore packets if they don't arrive on the reverse-path interface. For more information about Reverse Path Filtering see http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html - Currently, the PIM-SM implementation does not support unnumbered point-to-point links. Furthermore, even on numbered point-to-point links the next-hop information in the routing entries should use an IP address instead of an interface name. For example, if we have a GRE tunnel on Linux and if we want to add a route that uses that tunnel, we should use a command like: route add -net gw instead of route add -net FIB2MRIB: - No known issues. CLI: - No known issues. SNMP: - On some versions of Linux, there are some bugs in net-snmp versions 5.0.8 and 5.0.9, which prevent dynamic loading from working. See http://www.xorp.org/snmp.html for links to the net-snmp patches that solve the problems. - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See http://www.xorp.org/snmp.html for a link to the net-snmp patch that solves the problems. From caluml@gmail.com Thu Feb 23 11:47:34 2006 From: caluml@gmail.com (Calum) Date: Thu, 23 Feb 2006 11:47:34 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <635498b70602230347p1720f893x4a6dbd63d42218b6@mail.gmail.com> Hello all, I'm new to xorp - been using Zebra, and then Quagga for all routing needs up until now. However, they don't have any multicast routing facilities. A few of us are trying to make a multicast network, but we're spread about the place, and we're using a mixture of tap and tun interfaces. We have the unicast routing protocols working fine. We're looking to get xorp doing our multicast routing for us - but I have a few questions. 1. Does xorp handle tap/tun interfaces created by other processes before xorp runs in just the same way as it handles "standard" Ethernet interfaces? 2. Is there anything special you have to enable to use it that way? 3. Why am I getting this? : Cannot enable vif tapxxxx: no such vif (As I say, I have literally compiled this a few minutes ago, so I'll probably work it out as soon as I hit send. (However, if xorp doesn't play with tap/tun, please let me know and save me hair-pulling hours!) :) Calum From bms@spc.org Thu Feb 23 15:05:02 2006 From: bms@spc.org (Bruce M Simpson) Date: Thu, 23 Feb 2006 15:05:02 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <635498b70602230347p1720f893x4a6dbd63d42218b6@mail.gmail.com> References: <635498b70602230347p1720f893x4a6dbd63d42218b6@mail.gmail.com> Message-ID: <20060223150502.GP25822@spc.org> On Thu, Feb 23, 2006 at 11:47:34AM +0000, Calum wrote: > 1. Does xorp handle tap/tun interfaces created by other processes > before xorp runs in just the same way as it handles "standard" > Ethernet interfaces? Yes. > 2. Is there anything special you have to enable to use it that way? No. > 3. Why am I getting this? : Cannot enable vif tapxxxx: no such vif (As > I say, I have literally compiled this a few minutes ago, so I'll > probably work it out as soon as I hit send. (However, if xorp doesn't > play with tap/tun, please let me know and save me hair-pulling hours!) > :) You must have a 'vif tunxxxx {}' statement in the interface configuration. BMS From dolarov@computervoice.com Thu Feb 23 20:49:05 2006 From: dolarov@computervoice.com (Dorin Olarov) Date: Thu, 23 Feb 2006 14:49:05 -0600 Subject: [Xorp-users] troubles with PIM-SM Message-ID: <199401c638ba$95e01140$381da8c0@dorino> This is a multi-part message in MIME format. ------=_NextPart_000_1991_01C63888.4B243690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all,=20 Sorry for the long introduction, but I think a bit of a background is = necessary: I have a GRE tunnel going over a VPN and multicast+PIM-SM traffic going = through this GRE tunnel.=20 The other side is a Cisco router, don't know exactly the model + IOS = release.=20 All of this is fully operational on my side on a Cisco router as well, = with the following configuration: 2611XM with an AIM VPN/BP encryption module, running = c2600-ik9o3s-mz.122-27.=20 The problem is that the CPU usage is very high on the Cisco on my end. Even though the specs say this setup should handle up to 10Mbps of = encrypted traffic (with packets at near-MTU size), I get this high CPU usage at much lower traffic rates, as in 1 to = 1.5Mbps.=20 Because of this, I tried to replicate the same configuration on a = Soekris net4801 box (with a vpn1411 VPN accelerator card),=20 running on OpenBSD 3.8. The only modification from the stock 3.8 kernel = was to add support for PIM:=20 option PIM # Protocol Independent Multicast The part concerning the VPN and the GRE tunnel works ok and was tested = just fine.=20 For the PIM-SM support under OpenBSD part everything pointed to xorp , = so I deployed the xorp-1.1 package from the 3.8 distribution.=20 This is how my config.boot file looks like: /*XORP Configuration File, v1.0*/ interfaces { targetname: "fea" interface sis0 { disable: false description: "This is the NIC facing the Internet" default-system-config } interface sis3 { disable: false description: "This is the NIC facing the LAN" default-system-config } interface gre0 { disable: false description: "This is the Tunnel set up between the Soekris = OpenBSD and the Cisco VPN router" default-system-config } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface sis3 { vif sis3 { disable: false } } interface gre0 { vif gre0 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { static { route4 YYY.164.7.0/26 { next-hop: 10.167.1.45 metric: 1 } mrib-route4 YYY.164.7.0/24 { next-hop: 10.167.1.45 metric: 1 } } igmp { targetname: "IGMP" disable: false interface sis3 { vif sis3 { disable: false } } interface gre0 { vif gre0 { disable: false } } traceoptions { flag all { disable: false } } } pimsm4 { targetname: "PIMSM_4" disable: false interface sis3 { vif sis3 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } interface gre0 { vif gre0 { disable: false } } static-rps { rp YYY.164.7.254 { group-prefix 233.119.160.0/24 { rp-priority: 192 hash-mask-len: 30 } } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } and this is how the relevant network interfaces are configured: ifconfig sis0 inet XXX.227.82.27 netmask 255.255.255.248 ifconfig sis3 inet 10.65.50.1 netmask 255.255.255.0 ifconfig sis3 inet alias 192.168.20.3 netmask 255.255.255.0 ifconfig lo1 inet 10.167.0.21 netmask 255.255.255.255 ifconfig gre0 tunnel 10.167.0.21 10.173.254.1 ifconfig gre0 inet 10.167.1.46 10.167.1.45 netmask 255.255.255.252 The configuration on the Cisco side looks like this (trimmed to the = relevant details, VPN part left aside, too): Current configuration : 2793 bytes ! version 12.2 ! ip multicast-routing ! ! interface Loopback0 ip address 10.167.0.21 255.255.255.255 ! interface Tunnel0 ip address 10.167.1.46 255.255.255.252 ip pim sparse-mode tunnel source 10.167.0.21 tunnel destination 10.173.254.1 ! interface Ethernet0/0 ip address 10.65.50.1 255.255.255.0 ip pim sparse-mode full-duplex no cdp enable ! interface Ethernet0/1 ip address XXX.227.82.27 255.255.255.248 full-duplex crypto map cvs2set ! ip classless ip route 0.0.0.0 0.0.0.0 XXX.227.82.25 ip route YYY.164.7.0 255.255.255.192 Tunnel0 no ip http server ip pim rp-address YYY.164.7.254 WAN_list ip mroute YYY.164.7.0 255.255.255.0 Tunnel0 ! ! ip access-list standard WAN_list permit 233.119.160.0 0.0.0.63 deny any ! end I think the problem in the OpenBSD setup starts with setting up the = routes for getting to the RP through the tunnel,=20 because other than some occasional IGMP group 224.0.0.13 traffic I don't = see anything else flowing through it.=20 My question is ... what would be the correct xorp equivalent for the two = cisco commands below:=20 ip route YYY.164.7.0 255.255.255.192 Tunnel0=20 ip mroute YYY.164.7.0 255.255.255.0 Tunnel0 I thought that's what I'd be doing by using=20 static { route4 YYY.164.7.0/26 { next-hop: 10.167.1.45 metric: 1 } mrib-route4 YYY.164.7.0/24 { next-hop: 10.167.1.45 metric: 1 } (10.167.1.45 being the peer on the other end of the GRE tunnel), however = this doesn't seem to work this way.=20 Another indication is this type of messages logged by xorp_rtrmgr: [ 2006/02/22 18:22:50 ERROR xorp_fea:5723 MFEA +1781 mfea_proto_comm.cc = proto_socket_write ] sendmsg(proto 103 from 10.167.1.46 to 224.0.0.13 on = vif gre 0) failed: No route to host. Any suggestions? Thank you,=20 Dorin. ------=_NextPart_000_1991_01C63888.4B243690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
 
Sorry for the long introduction, but I = think a bit=20 of a background is necessary:
I have a GRE tunnel going over a = VPN and=20 multicast+PIM-SM traffic going through this GRE=20 tunnel.
The other side is a Cisco router, don't = know=20 exactly the model + IOS release.
All of this is fully operational on my = side on a=20 Cisco router as well, with the following configuration:
2611XM with an AIM VPN/BP encryption = module, =20 running c2600-ik9o3s-mz.122-27.
 
The problem is that the CPU usage is = very high on=20 the Cisco on my end.
Even though the specs say this setup = should handle=20 up to 10Mbps of encrypted traffic (with packets at near-MTU = size),
I get this high CPU usage at much lower = traffic=20 rates, as in 1 to 1.5Mbps.
Because of this, I tried to replicate = the same=20 configuration on a Soekris net4801 box (with a vpn1411 VPN accelerator = card),=20
running on OpenBSD 3.8. The only = modification from=20 the stock 3.8 kernel was to add support for PIM:
option         =20 PIM           &nbs= p; #=20 Protocol Independent Multicast
 
The part concerning the VPN and the GRE = tunnel=20 works ok and was tested just fine.
For the PIM-SM support under OpenBSD = part=20 everything pointed to xorp , so I deployed the xorp-1.1 = package
from the 3.8 distribution. =
 
This is how my config.boot file looks=20 like:
/*XORP Configuration File, = v1.0*/
interfaces=20 {
    targetname: "fea"
    = interface sis0=20 {
        disable:=20 false
        description: "This = is the=20 NIC facing the Internet"
       =20 default-system-config
    }
    = interface=20 sis3 {
        disable:=20 false
        description: "This = is the=20 NIC facing the LAN"
       =20 default-system-config
    }
    = interface=20 gre0 {
        disable:=20 false
        description: "This = is the=20 Tunnel set up between the Soekris OpenBSD and the Cisco VPN=20 router"
       =20 default-system-config
    }
}
fea=20 {
        unicast-forwarding4=20 {
           &n= bsp;   =20 disable: false
        = }
}
plumbing=20 {
        mfea4=20 {
           &n= bsp;   =20 disable:=20 false
          &nbs= p;    =20 interface sis3=20 {
           &n= bsp;           =20 vif sis3=20 {
           &n= bsp;           &nb= sp;       =20 disable:=20 false
          &nbs= p;            = ;=20 }
           &n= bsp;   =20 }
           &n= bsp;   =20 interface gre0=20 {
           &n= bsp;           =20 vif gre0=20 {
           &n= bsp;           &nb= sp;       =20 disable:=20 false
          &nbs= p;            = ;=20 }
           &n= bsp;   =20 }
           &n= bsp;   =20 interface register_vif=20 {
           &n= bsp;           =20 vif register_vif=20 {
           &n= bsp;           =20 /* Note: this vif should be always enabled=20 */
           &= nbsp;           &n= bsp;       =20 disable:=20 false
          &nbs= p;            = ;=20 }
           &n= bsp;   =20 }
           &n= bsp;   =20 traceoptions=20 {
           &n= bsp;           =20 flag all=20 {
           &n= bsp;           &nb= sp;       =20 disable:=20 false
          &nbs= p;            = ;=20 }
           &n= bsp;   =20 }
        }
}
protocols=20 {
    static = {
       =20 route4 YYY.164.7.0/26=20 {
           &n= bsp;   =20 next-hop:=20 10.167.1.45
         &nbs= p;     =20 metric: 1
       =20 }
        mrib-route4 = YYY.164.7.0/24=20 {
           &n= bsp;   =20 next-hop:=20 10.167.1.45
         &nbs= p;     =20 metric: 1
        = }
   =20 }
    igmp = {
       =20 targetname: "IGMP"
        = disable:=20 false
        interface sis3=20 {
           &n= bsp;   =20 vif sis3=20 {
           &n= bsp;           =20 disable:=20 false
          &nbs= p;    =20 }
       =20 }
        interface gre0=20 {
           &n= bsp;   =20 vif gre0=20 {
           &n= bsp;           =20 disable:=20 false
          &nbs= p;    =20 }
       =20 }
        traceoptions=20 {
           &n= bsp;   =20 flag all=20 {
           &n= bsp;           =20 disable:=20 false
          &nbs= p;    =20 }
        }
   =20 }
    pimsm4 = {
       =20 targetname: "PIMSM_4"
        = disable:=20 false
        interface sis3=20 {
           &n= bsp;   =20 vif sis3=20 {
           &n= bsp;           =20 disable:=20 false
          &nbs= p;    =20 }
       =20 }
        interface register_vif=20 {
           &n= bsp;   =20 vif register_vif=20 {
           &n= bsp;           =20 /* Note: this vif should be always enabled=20 */
           &= nbsp;           =20 disable:=20 false
          &nbs= p;    =20 }
       =20 }
        interface gre0=20 {
           &n= bsp;   =20 vif gre0=20 {
           &n= bsp;           =20 disable:=20 false
          &nbs= p;    =20 }
       =20 }
        static-rps=20 {
           &n= bsp;   =20 rp YYY.164.7.254=20 {
           &n= bsp;           =20 group-prefix 233.119.160.0/24=20 {
           &n= bsp;           &nb= sp;       =20 rp-priority:=20 192
           =             &= nbsp;       =20 hash-mask-len:=20 30
           &= nbsp;           =20 }
           &n= bsp;   =20 }
        }
   =20 }
}

/*
 * = Note: fib2mrib=20 is needed for multicast only if the unicast protocols
 * don't = populate=20 the MRIB with multicast-specific routes.
 */
protocols=20 {
    fib2mrib = {
       =20 disable: false
    }
}
 
and this is how the relevant network interfaces are = configured:
ifconfig sis0 inet XXX.227.82.27 netmask=20 255.255.255.248
ifconfig sis3 inet 10.65.50.1 netmask=20 255.255.255.0
ifconfig sis3 inet alias 192.168.20.3 netmask=20 255.255.255.0
ifconfig lo1 inet 10.167.0.21 netmask=20 255.255.255.255
ifconfig gre0 tunnel 10.167.0.21=20 10.173.254.1
ifconfig gre0 inet 10.167.1.46 10.167.1.45 netmask=20 255.255.255.252

 
The configuration on the Cisco side looks like this (trimmed to the = relevant details, VPN part left aside, too):
Current configuration : 2793 = bytes
!
version=20 12.2
!
ip multicast-routing
!
!
interface = Loopback0
 ip=20 address 10.167.0.21 255.255.255.255
!
interface = Tunnel0
 ip=20 address 10.167.1.46 255.255.255.252
 ip pim = sparse-mode
 tunnel=20 source 10.167.0.21
 tunnel destination = 10.173.254.1
!
interface=20 Ethernet0/0
 ip address 10.65.50.1 255.255.255.0
 ip pim = sparse-mode
 full-duplex
 no cdp = enable
!
interface=20 Ethernet0/1
 ip address XXX.227.82.27=20 255.255.255.248
 full-duplex
 crypto map = cvs2set
!
ip=20 classless
ip route 0.0.0.0 0.0.0.0 XXX.227.82.25
ip route = YYY.164.7.0=20 255.255.255.192 Tunnel0
no ip http server
ip pim rp-address = YYY.164.7.254=20 WAN_list
ip mroute YYY.164.7.0 255.255.255.0 Tunnel0
!
!
ip=20 access-list standard WAN_list
 permit 233.119.160.0=20 0.0.0.63
 deny   any
!
end
 
I think the problem in the = OpenBSD=20 setup starts with setting up the routes for getting to the RP through = the=20 tunnel,
because other than some = occasional IGMP=20 group 224.0.0.13 traffic I don't see anything else flowing through = it.=20
My question is ... what = would be the=20 correct xorp equivalent for the two cisco commands below: =
ip route YYY.164.7.0 255.255.255.192=20 Tunnel0 
ip = mroute=20 YYY.164.7.0 255.255.255.0 Tunnel0
 
I thought that's what I'd = be doing by=20 using
    static=20 {
        route4 YYY.164.7.0/26=20 {
           &n= bsp;   =20 next-hop:=20 10.167.1.45
         &nbs= p;     =20 metric: 1
       =20 }
        mrib-route4 = YYY.164.7.0/24=20 {
           &n= bsp;   =20 next-hop:=20 10.167.1.45
         &nbs= p;     =20 metric: 1
        }
(10.167.1.45 being the peer on the other end of the GRE=20 tunnel), however = this doesn't=20 seem to work this way.
Another indication is this = type of=20 messages logged by xorp_rtrmgr:
[ 2006/02/22 18:22:50  ERROR = xorp_fea:5723 MFEA=20 +1781 mfea_proto_comm.cc proto_socket_write ] sendmsg(proto 103 from = 10.167.1.46=20 to 224.0.0.13 on vif gre
0) failed: No route to host.
 
Any suggestions?
 
Thank you,
Dorin.
 
------=_NextPart_000_1991_01C63888.4B243690-- From pavlin@icir.org Fri Feb 24 19:09:59 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Feb 2006 11:09:59 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Bruce M Simpson of "Thu, 23 Feb 2006 15:05:02 GMT." <20060223150502.GP25822@spc.org> Message-ID: <200602241909.k1OJ9xUF010476@possum.icir.org> > On Thu, Feb 23, 2006 at 11:47:34AM +0000, Calum wrote: > > 1. Does xorp handle tap/tun interfaces created by other processes > > before xorp runs in just the same way as it handles "standard" > > Ethernet interfaces? > > Yes. > > > 2. Is there anything special you have to enable to use it that way? > > No. > > > 3. Why am I getting this? : Cannot enable vif tapxxxx: no such vif (As > > I say, I have literally compiled this a few minutes ago, so I'll > > probably work it out as soon as I hit send. (However, if xorp doesn't > > play with tap/tun, please let me know and save me hair-pulling hours!) > > :) > > You must have a 'vif tunxxxx {}' statement in the interface configuration. Some additional information on the subject. To be able to use a tun/tap interface (or any network interface in general), it must be already created before starting XORP (though it doesn't need to be configured with IP address, etc). If you have the tun/tap interface already configured with an IP address you want to (re)use, then you can use the following statement in your configuration: interfaces { interface tun0 { default-system-config } } If the IP address is not configured or if you want to explicitly configure the address in your XORP configuration, then use a statement like: interfaces { interface tun0 { vif tun0 { address 10.10.10.10 { prefix-length: 24 } } } } See the XORP user documentation for more information about configuring network interfaces and for examples of configuring multicast routing. If you are still getting the above error, then please send your XORP configuration and the list of UNIX commands (if such) you used to configure the tap interface. Pavlin From caluml@gmail.com Fri Feb 24 20:37:37 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 20:37:37 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <200602241909.k1OJ9xUF010476@possum.icir.org> References: <20060223150502.GP25822@spc.org> <200602241909.k1OJ9xUF010476@possum.icir.org> Message-ID: <635498b70602241237x7dbea31fu6282e0cfba00199f@mail.gmail.com> Hello Pavlin, I've just tried out the xorpsh interface, and it's much easier (for me) to configure the system. I am trying to create a BGP peering, but am getting an error when I commit: # commit Commit Failed 102 Command failed AddressFamilyMismatch from line 64 of iptuple.cc: mismatch 10.0.0.122 hush[edit] I notice that when the interface asks for the local-ip (which I missed) ... # commit Missing mandatory configuration node "$(@.local-ip)" required by node "protocols bgp peer hush" The configuration has not been changed. Fix this error, and run "commit" again. # create protocols bgp peer hush local-ip Possible completions: Set the IP address on this router to use for this peering. # create protocols bgp peer hush local-ip 10.0.0.122 [edit] ..it asks for a "text" input rather than "" as it does for most of the other required IP addresses. E.g. # create protocols bgp peer hush next-hop ? Possible completions: IPv4 next-hop Is this text/IPv4 difference intentional? Here is my current (uncommited) config from show -all interfaces { interface taphush { default-system-config disable: false discard: false description: "" vif taphush { disable: false } } restore-original-config-on-shutdown: false } > protocols { > bgp { > peer hush { > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.121 > local-ip: "10.0.0.122" > } > local-as: 4 > bgp-id: 10.0.0.122 > } I see that the local-ip is as "10.0.0.122" - I think I tried editting it manually, and setting it to 10.0.0.122, and it didn't make it work. (I'm using "real" ASs rather than the ones set aside for testing because I'm lazy. :) ) Calum -- Ask me about Linux virtual servers. A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net From atanu@ICSI.Berkeley.EDU Fri Feb 24 20:43:40 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 24 Feb 2006 12:43:40 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Calum of "Fri, 24 Feb 2006 20:37:37 GMT." <635498b70602241237x7dbea31fu6282e0cfba00199f@mail.gmail.com> Message-ID: <13072.1140813820@tigger.icir.org> Hi, Try replacing "hush" with the actual IP address. Atanu. >>>>> "Calum" == Calum writes: Calum> Hello Pavlin, I've just tried out the xorpsh interface, and Calum> it's much easier (for me) to configure the system. Calum> I am trying to create a BGP peering, but am getting an error Calum> when I commit: Calum> # commit Commit Failed 102 Command failed Calum> AddressFamilyMismatch from line 64 of iptuple.cc: mismatch Calum> 10.0.0.122 hush[edit] Calum> I notice that when the interface asks for the local-ip (which Calum> I missed) ... Calum> # commit Missing mandatory configuration node "$(@.local-ip)" Calum> required by node "protocols bgp peer hush" The configuration Calum> has not been changed. Fix this error, and run "commit" Calum> again. # create protocols bgp peer hush local-ip Possible Calum> completions: Set the IP address on this router to use Calum> for this peering. # create protocols bgp peer hush local-ip Calum> 10.0.0.122 [edit] Calum> ..it asks for a "text" input rather than "" as it does Calum> for most of the other required IP addresses. E.g. Calum> # create protocols bgp peer hush next-hop ? Possible Calum> completions: IPv4 next-hop Calum> Is this text/IPv4 difference intentional? Calum> Here is my current (uncommited) config from show -all Calum> interfaces { interface taphush { default-system-config Calum> disable: false discard: false description: "" vif taphush { Calum> disable: false } } restore-original-config-on-shutdown: false Calum> } >> protocols { bgp { peer hush { as: 1 peer-port: 179 local-port: >> 179 holdtime: 90 delay-open-time: 0 client: false >> confederation-member: false disable: false ipv4-unicast: true >> ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false >> next-hop: 10.0.0.121 local-ip: "10.0.0.122" } local-as: 4 bgp-id: >> 10.0.0.122 } Calum> I see that the local-ip is as "10.0.0.122" - I think I tried Calum> editting it manually, and setting it to 10.0.0.122, and it Calum> didn't make it work. Calum> (I'm using "real" ASs rather than the ones set aside for Calum> testing because I'm lazy. :) ) Calum> Calum Calum> -- Ask me about Linux virtual servers. A80F D3A0 0EFA Calum> 23FE@wwwkeys.eu.pgp.net Calum> _______________________________________________ Xorp-users Calum> mailing list Xorp-users@xorp.org Calum> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Fri Feb 24 20:50:22 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 24 Feb 2006 12:50:22 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Calum of "Fri, 24 Feb 2006 20:37:37 GMT." <635498b70602241237x7dbea31fu6282e0cfba00199f@mail.gmail.com> Message-ID: <14396.1140814222@tigger.icir.org> >>>>> "Calum" == Calum writes: Calum> Hello Pavlin, I've just tried out the xorpsh interface, and Calum> it's much easier (for me) to configure the system. Calum> I am trying to create a BGP peering, but am getting an error Calum> when I commit: Calum> # commit Commit Failed 102 Command failed Calum> AddressFamilyMismatch from line 64 of iptuple.cc: mismatch Calum> 10.0.0.122 hush[edit] Calum> I notice that when the interface asks for the local-ip (which Calum> I missed) ... Calum> # commit Missing mandatory configuration node "$(@.local-ip)" Calum> required by node "protocols bgp peer hush" The configuration Calum> has not been changed. Fix this error, and run "commit" Calum> again. # create protocols bgp peer hush local-ip Possible Calum> completions: Set the IP address on this router to use Calum> for this peering. # create protocols bgp peer hush local-ip Calum> 10.0.0.122 [edit] Calum> ..it asks for a "text" input rather than "" as it does Calum> for most of the other required IP addresses. E.g. Calum> # create protocols bgp peer hush next-hop ? Possible Calum> completions: IPv4 next-hop Calum> Is this text/IPv4 difference intentional? The peer and local-ip arguments can be text to allow IPv4, IPv6 or hostname. Without looking at the code I suspect that hush has resolved to an IPv6 address and the provided local-ip is IPv4 hence the AddressFamilyMismatch. Atanu. From mhorn@vyatta.com Fri Feb 24 20:53:58 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 12:53:58 -0800 (PST) Subject: Fwd: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <32628298.7221140814438288.JavaMail.root@mail.vyatta.com> Hi Calum, Both the "next-hop" and "local-ip" addresses should be the local interface IP address (10.0.0.122 in your example). The peer "hush" should either be a resolvable hostname for your BGP peer (not recommended) or should be the IP address of your peer (recommended). Here is what the updated configuration would look like: > protocols { > bgp { > peer 10.0.0.121 { > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.122 > local-ip: "10.0.0.122" > } > local-as: 4 > bgp-id: 10.0.0.122 > } -mike ----- Original Message ----- From: Calum To: xorp-users@xorp.org Sent: Friday, February 24, 2006 1:37:37 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap Hello Pavlin, I've just tried out the xorpsh interface, and it's much easier (for me) to configure the system. I am trying to create a BGP peering, but am getting an error when I commit: # commit Commit Failed 102 Command failed AddressFamilyMismatch from line 64 of iptuple.cc: mismatch 10.0.0.122 hush[edit] I notice that when the interface asks for the local-ip (which I missed) ... # commit Missing mandatory configuration node "$(@.local-ip)" required by node "protocols bgp peer hush" The configuration has not been changed. Fix this error, and run "commit" again. # create protocols bgp peer hush local-ip Possible completions: Set the IP address on this router to use for this peering. # create protocols bgp peer hush local-ip 10.0.0.122 [edit] ..it asks for a "text" input rather than "" as it does for most of the other required IP addresses. E.g. # create protocols bgp peer hush next-hop ? Possible completions: IPv4 next-hop Is this text/IPv4 difference intentional? Here is my current (uncommited) config from show -all interfaces { interface taphush { default-system-config disable: false discard: false description: "" vif taphush { disable: false } } restore-original-config-on-shutdown: false } > protocols { > bgp { > peer hush { > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.121 > local-ip: "10.0.0.122" > } > local-as: 4 > bgp-id: 10.0.0.122 > } I see that the local-ip is as "10.0.0.122" - I think I tried editting it manually, and setting it to 10.0.0.122, and it didn't make it work. (I'm using "real" ASs rather than the ones set aside for testing because I'm lazy. :) ) Calum -- Ask me about Linux virtual servers. A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From caluml@gmail.com Fri Feb 24 20:59:49 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 20:59:49 +0000 Subject: Fwd: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <635498b70602241259k5c1d8ba3i767f0d838840c77c@mail.gmail.com> References: <635498b70602241237x7dbea31fu6282e0cfba00199f@mail.gmail.com> <13072.1140813820@tigger.icir.org> <635498b70602241259k5c1d8ba3i767f0d838840c77c@mail.gmail.com> Message-ID: <635498b70602241259j245ad2ccma41376af06590663@mail.gmail.com> On 2/24/06, Atanu Ghosh wrote: > Hi, > > Try replacing "hush" with the actual IP address. > > Atanu. > Hello, thanks for that. I think it is a little confusing to use a input where it needs to be an IP address. # create protocols bgp peer ? Possible completions: <[Enter]> Execute this command Configure a peering session with another router. ? Anyway. show bgp routes shows lots of routes, but they aren't appearing in the local system routing table. Any ideas? (I've poked at fea, and enabled unicast forwarding, but nothing.) C -- Ask me about Linux virtual servers. A80F D3A0 0EFA23FE@wwwkeys.eu.pgp.net From mhorn@vyatta.com Fri Feb 24 21:05:28 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 13:05:28 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <17284012.7311140815128103.JavaMail.root@mail.vyatta.com> Hi Calum, It sounds like the NEXT_HOP that you are learning in the BGP updates might not be resolvable (e.g. there is not a route in the RIB for the NEXT_HOP). Can you send a copy of "show route" and "show bgp routes" (only need the first few lines). -mike ----- Original Message ----- From: Calum To: xorp-users@xorp.org Sent: Friday, February 24, 2006 1:59:49 PM GMT-0700 Subject: Fwd: [Xorp-users] Xorp, pimsm and ethertap On 2/24/06, Atanu Ghosh wrote: > Hi, > > Try replacing "hush" with the actual IP address. > > Atanu. > Hello, thanks for that. I think it is a little confusing to use a input where it needs to be an IP address. # create protocols bgp peer ? Possible completions: <[Enter]> Execute this command Configure a peering session with another router. ? Anyway. show bgp routes shows lots of routes, but they aren't appearing in the local system routing table. Any ideas? (I've poked at fea, and enabled unicast forwarding, but nothing.) C -- Ask me about Linux virtual servers. A80F D3A0 0EFA23FE@wwwkeys.eu.pgp.net _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From caluml@gmail.com Fri Feb 24 21:20:35 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 21:20:35 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <17284012.7311140815128103.JavaMail.root@mail.vyatta.com> References: <17284012.7311140815128103.JavaMail.root@mail.vyatta.com> Message-ID: <635498b70602241320t886cd2evab0e1bcdabb0b36b@mail.gmail.com> Hello all, thanks for that. Here is my current config. interfaces { interface taphush { default-system-config disable: false discard: false description: "" vif taphush { disable: false } } restore-original-config-on-shutdown: false } protocols { bgp { bgp-id: 10.0.0.122 local-as: 4 peer "10.0.0.121" { as: 1 peer-port: 179 local-port: 179 holdtime: 90 delay-open-time: 0 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.0.0.121 local-ip: "10.0.0.122" } } } fea { unicast-forwarding4 { disable: false } } I actually can't ping my local IP now. # ping 10.0.0.121 PING 10.0.0.121 (10.0.0.121) 56(84) bytes of data. 64 bytes from 10.0.0.121: icmp_seq=1 ttl=64 time=1.29 ms 64 bytes from 10.0.0.121: icmp_seq=2 ttl=64 time=0.893 ms --- 10.0.0.121 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 0.893/1.095/1.297/0.202 ms # ping 10.0.0.122 PING 10.0.0.122 (10.0.0.122) 56(84) bytes of data. --- 10.0.0.122 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3012ms Which is weird. It's a /30 tap link that's been brought up by OpenVPN, and I'm trying to avoid any config done by XORP for that. -- Ask me about Linux virtual servers. A80F D3A0 0EFA23FE@wwwkeys.eu.pgp.net From mhorn@vyatta.com Fri Feb 24 21:28:37 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 13:28:37 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <13401086.7371140816517659.JavaMail.root@mail.vyatta.com> Hi Calum, I'm not sure why you are not able to ping your local IP, can you send the output from ifconfig? Also, if you kill the XORP processes are you able to ping your local IP? I noticed in your BGP configurat that you still need to change your BGP configuration from "next-hop: 10.0.0.121" to "next-hop: 10.0.0.122" (this is the next-hop used when sending updates to BGP peers). -mike ----- Original Message ----- From: Calum To: Mike Horn Cc: xorp-users@xorp.org Sent: Friday, February 24, 2006 2:20:35 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap Hello all, thanks for that. Here is my current config. interfaces { interface taphush { default-system-config disable: false discard: false description: "" vif taphush { disable: false } } restore-original-config-on-shutdown: false } protocols { bgp { bgp-id: 10.0.0.122 local-as: 4 peer "10.0.0.121" { as: 1 peer-port: 179 local-port: 179 holdtime: 90 delay-open-time: 0 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.0.0.121 local-ip: "10.0.0.122" } } } fea { unicast-forwarding4 { disable: false } } I actually can't ping my local IP now. # ping 10.0.0.121 PING 10.0.0.121 (10.0.0.121) 56(84) bytes of data. 64 bytes from 10.0.0.121: icmp_seq=1 ttl=64 time=1.29 ms 64 bytes from 10.0.0.121: icmp_seq=2 ttl=64 time=0.893 ms --- 10.0.0.121 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 0.893/1.095/1.297/0.202 ms # ping 10.0.0.122 PING 10.0.0.122 (10.0.0.122) 56(84) bytes of data. --- 10.0.0.122 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3012ms Which is weird. It's a /30 tap link that's been brought up by OpenVPN, and I'm trying to avoid any config done by XORP for that. -- Ask me about Linux virtual servers. A80F D3A0 0EFA23FE@wwwkeys.eu.pgp.net From caluml@gmail.com Fri Feb 24 21:52:49 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 21:52:49 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <13401086.7371140816517659.JavaMail.root@mail.vyatta.com> References: <13401086.7371140816517659.JavaMail.root@mail.vyatta.com> Message-ID: <635498b70602241352v2b12dc6awc997c4a16ef00142@mail.gmail.com> Hello Mike, I'm not sure about changing next-hop. That leaves my config looking like: protocols { bgp { bgp-id: 10.0.0.122 <-------- this is the local IP, right? local-as: 4 peer "10.0.0.121" { <-------- This is the remote IP? as: 1 peer-port: 179 local-port: 179 holdtime: 90 delay-open-time: 0 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.0.0.122 <----- This should be the remote IP? local-ip: "10.0.0.122" <------ This is the local IP ? } } which looks odd with the same next-hop and local-ip. To me, anyway. My current setup is local = 10.0.0.122 (running xorp) ----tapinterface---- remote = 10.0.0.121 (running quagga bgpd) I have an established BGP session up as shown on 10.0.0.121 quagga: # sh ip bgp neighbors 10.0.0.122 BGP neighbor is 10.0.0.122, remote AS 4, local AS 1, external link BGP version 4, remote router ID 10.0.0.122 BGP state = Established, up for 00:00:48 Showing the advertised routes on that hosts shows the routes. xorp# show bgp routes on the xorp box shows them all received. They're just not making it into the kernel on 10.0.0.122 xorp-box > show bgp peers Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 xorp-box # ifconfig taphush taphush Link encap:Ethernet HWaddr CE:BC:C7:A6:C4:ED inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 How does xorp handle an interface disappearing, and coming back, out of interest? From mhorn@vyatta.com Fri Feb 24 22:01:39 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 14:01:39 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <9412821.7401140818499553.JavaMail.root@mail.vyatta.com> Hi Calum, It might look a bit strange, but yes your "local-ip" and "next-hop" need to be the same address for this configuration to work. The only reference to the remote IP address is "peer ". Can you send the output from "show bgp peers detail", the "show bgp peers" command just shows you what is configured, not whether the session is actually established. Look for the "Peer State:" line. When you ask "How does xorp handle an interface disappearing, and coming back, out of interest?", do you mean the link state is changing, or that the interface itself is being deleted and re-added? -mike ----- Original Message ----- From: Calum To: Mike Horn Cc: xorp-users@xorp.org Sent: Friday, February 24, 2006 2:52:49 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap Hello Mike, I'm not sure about changing next-hop. That leaves my config looking like: protocols { bgp { bgp-id: 10.0.0.122 <-------- this is the local IP, right? local-as: 4 peer "10.0.0.121" { <-------- This is the remote IP? as: 1 peer-port: 179 local-port: 179 holdtime: 90 delay-open-time: 0 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.0.0.122 <----- This should be the remote IP? local-ip: "10.0.0.122" <------ This is the local IP ? } } which looks odd with the same next-hop and local-ip. To me, anyway. My current setup is local = 10.0.0.122 (running xorp) ----tapinterface---- remote = 10.0.0.121 (running quagga bgpd) I have an established BGP session up as shown on 10.0.0.121 quagga: # sh ip bgp neighbors 10.0.0.122 BGP neighbor is 10.0.0.122, remote AS 4, local AS 1, external link BGP version 4, remote router ID 10.0.0.122 BGP state = Established, up for 00:00:48 Showing the advertised routes on that hosts shows the routes. xorp# show bgp routes on the xorp box shows them all received. They're just not making it into the kernel on 10.0.0.122 xorp-box > show bgp peers Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 xorp-box # ifconfig taphush taphush Link encap:Ethernet HWaddr CE:BC:C7:A6:C4:ED inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 How does xorp handle an interface disappearing, and coming back, out of interest? From caluml@gmail.com Fri Feb 24 22:18:12 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 22:18:12 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <9412821.7401140818499553.JavaMail.root@mail.vyatta.com> References: <9412821.7401140818499553.JavaMail.root@mail.vyatta.com> Message-ID: <635498b70602241418j18113e7bjd00a836b63c84f05@mail.gmail.com> > show bgp peers detail Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 Peer ID: 10.0.0.1 Peer State: ESTABLISHED Admin State: START Negotiated BGP Version: 4 Peer AS Number: 1 Updates Received: 8, Updates Sent: 0 Messages Received: 73, Messages Sent: 74 Time since last received update: 129 seconds Number of transitions to ESTABLISHED: 2 Time since last entering ESTABLISHED state: 1870 seconds Retry Interval: 120 seconds Hold Time: 90 seconds, Keep Alive Time: 30 seconds Configured Hold Time: 90 seconds, Configured Keep Alive Time: 30 seconds Minimum AS Origination Interval: 0 seconds Minimum Route Advertisement Interval: 0 seconds And yes, I mean if the process that opens the tun/tap is killed off, or restarts, the interface will disappear. > show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.0.0.0/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.4/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.8/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.20/30 10.0.0.121 10.0.0.1 1 i .... snip I just don't understand why those routes aren't appearing in route -n at a root shell. :/ C On 2/24/06, Mike Horn wrote: > Hi Calum, > > It might look a bit strange, but yes your "local-ip" and "next-hop" need to be the same address for this configuration to work. The only reference to the remote IP address is "peer ". > > Can you send the output from "show bgp peers detail", the "show bgp peers" command just shows you what is configured, not whether the session is actually established. Look for the "Peer State:" line. > > When you ask "How does xorp handle an interface disappearing, and coming back, out of interest?", do you mean the link state is changing, or that the interface itself is being deleted and re-added? > > > -mike > > ----- Original Message ----- > From: Calum > To: Mike Horn > Cc: xorp-users@xorp.org > Sent: Friday, February 24, 2006 2:52:49 PM GMT-0700 > Subject: Re: [Xorp-users] Xorp, pimsm and ethertap > > Hello Mike, > > I'm not sure about changing next-hop. > That leaves my config looking like: > protocols { > bgp { > bgp-id: 10.0.0.122 <-------- this is the local IP, right? > local-as: 4 > peer "10.0.0.121" { <-------- This is the remote IP? > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.122 <----- This should be the remote IP? > local-ip: "10.0.0.122" <------ This is the local IP ? > } > } > > which looks odd with the same next-hop and local-ip. To me, anyway. > > My current setup is > > local = 10.0.0.122 (running xorp) > ----tapinterface---- > remote = 10.0.0.121 (running quagga bgpd) > > I have an established BGP session up as shown on 10.0.0.121 > quagga: # sh ip bgp neighbors 10.0.0.122 > BGP neighbor is 10.0.0.122, remote AS 4, local AS 1, external link > BGP version 4, remote router ID 10.0.0.122 > BGP state = Established, up for 00:00:48 > Showing the advertised routes on that hosts shows the routes. > xorp# show bgp routes on the xorp box shows them all received. > They're just not making it into the kernel on 10.0.0.122 > > xorp-box > show bgp peers > Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 > > > xorp-box # ifconfig taphush > taphush Link encap:Ethernet HWaddr CE:BC:C7:A6:C4:ED > inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 > > > How does xorp handle an interface disappearing, and coming back, out > of interest? > -- http://zapee.com - Linux virtual servers, IPv4+6 web hosting A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net From mhorn@vyatta.com Fri Feb 24 22:49:29 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 14:49:29 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <19604460.7491140821369763.JavaMail.root@mail.vyatta.com> Hi Calum, Usually this is due to a the next-hop not being resolvable, can you send the output for "route -n". If your tunnel network is not showing up properly as a connected route this could create an issue. Can you send the "show interfaces" output from configuration-mode on xorpsh? Here is a copy of a local system I have running BGP peering to a Cisco router: rl@DUT-1> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- *> 10.0.0.0/30 10.0.0.75 192.168.2.33 75 ? *> 10.0.0.4/30 10.0.0.75 192.168.2.33 75 ? rl@DUT-1> ~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.4 10.0.0.75 255.255.255.252 UG 0 0 0 eth0 10.0.0.0 10.0.0.75 255.255.255.252 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 ~ # -mike ----- Original Message ----- From: Calum To: Mike Horn Cc: xorp-users@xorp.org Sent: Friday, February 24, 2006 3:18:12 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap > show bgp peers detail Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 Peer ID: 10.0.0.1 Peer State: ESTABLISHED Admin State: START Negotiated BGP Version: 4 Peer AS Number: 1 Updates Received: 8, Updates Sent: 0 Messages Received: 73, Messages Sent: 74 Time since last received update: 129 seconds Number of transitions to ESTABLISHED: 2 Time since last entering ESTABLISHED state: 1870 seconds Retry Interval: 120 seconds Hold Time: 90 seconds, Keep Alive Time: 30 seconds Configured Hold Time: 90 seconds, Configured Keep Alive Time: 30 seconds Minimum AS Origination Interval: 0 seconds Minimum Route Advertisement Interval: 0 seconds And yes, I mean if the process that opens the tun/tap is killed off, or restarts, the interface will disappear. > show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.0.0.0/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.4/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.8/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.20/30 10.0.0.121 10.0.0.1 1 i .... snip I just don't understand why those routes aren't appearing in route -n at a root shell. :/ C On 2/24/06, Mike Horn wrote: > Hi Calum, > > It might look a bit strange, but yes your "local-ip" and "next-hop" need to be the same address for this configuration to work. The only reference to the remote IP address is "peer ". > > Can you send the output from "show bgp peers detail", the "show bgp peers" command just shows you what is configured, not whether the session is actually established. Look for the "Peer State:" line. > > When you ask "How does xorp handle an interface disappearing, and coming back, out of interest?", do you mean the link state is changing, or that the interface itself is being deleted and re-added? > > > -mike > > ----- Original Message ----- > From: Calum > To: Mike Horn > Cc: xorp-users@xorp.org > Sent: Friday, February 24, 2006 2:52:49 PM GMT-0700 > Subject: Re: [Xorp-users] Xorp, pimsm and ethertap > > Hello Mike, > > I'm not sure about changing next-hop. > That leaves my config looking like: > protocols { > bgp { > bgp-id: 10.0.0.122 <-------- this is the local IP, right? > local-as: 4 > peer "10.0.0.121" { <-------- This is the remote IP? > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.122 <----- This should be the remote IP? > local-ip: "10.0.0.122" <------ This is the local IP ? > } > } > > which looks odd with the same next-hop and local-ip. To me, anyway. > > My current setup is > > local = 10.0.0.122 (running xorp) > ----tapinterface---- > remote = 10.0.0.121 (running quagga bgpd) > > I have an established BGP session up as shown on 10.0.0.121 > quagga: # sh ip bgp neighbors 10.0.0.122 > BGP neighbor is 10.0.0.122, remote AS 4, local AS 1, external link > BGP version 4, remote router ID 10.0.0.122 > BGP state = Established, up for 00:00:48 > Showing the advertised routes on that hosts shows the routes. > xorp# show bgp routes on the xorp box shows them all received. > They're just not making it into the kernel on 10.0.0.122 > > xorp-box > show bgp peers > Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 > > > xorp-box # ifconfig taphush > taphush Link encap:Ethernet HWaddr CE:BC:C7:A6:C4:ED > inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 > > > How does xorp handle an interface disappearing, and coming back, out > of interest? > -- http://zapee.com - Linux virtual servers, IPv4+6 web hosting A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Fri Feb 24 22:52:37 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Feb 2006 14:52:37 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Calum of "Fri, 24 Feb 2006 21:20:35 GMT." <635498b70602241320t886cd2evab0e1bcdabb0b36b@mail.gmail.com> Message-ID: <200602242252.k1OMqb9n012139@possum.icir.org> > interfaces { > interface taphush { > default-system-config > disable: false > discard: false > description: "" > vif taphush { > disable: false > } > } > restore-original-config-on-shutdown: false > } FYI, if you are using the default-system-config statement for interface taphush, then you shouldn't specify "vif tarhush". Though, I am not sure that it matters for the problem you have with pinging the local IP address. As Mike asked already, what is the output of "ifconfig -a" (or "ip addr" in case of Linux). This should be the starting point in clearing the pinging the local IP mistery. Pavlin > protocols { > bgp { > bgp-id: 10.0.0.122 > local-as: 4 > peer "10.0.0.121" { > as: 1 > peer-port: 179 > local-port: 179 > holdtime: 90 > delay-open-time: 0 > client: false > confederation-member: false > disable: false > ipv4-unicast: true > ipv4-multicast: false > ipv6-unicast: false > ipv6-multicast: false > next-hop: 10.0.0.121 > local-ip: "10.0.0.122" > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > } > > > I actually can't ping my local IP now. > > # ping 10.0.0.121 > PING 10.0.0.121 (10.0.0.121) 56(84) bytes of data. > 64 bytes from 10.0.0.121: icmp_seq=1 ttl=64 time=1.29 ms > 64 bytes from 10.0.0.121: icmp_seq=2 ttl=64 time=0.893 ms > > --- 10.0.0.121 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1004ms > rtt min/avg/max/mdev = 0.893/1.095/1.297/0.202 ms > # ping 10.0.0.122 > PING 10.0.0.122 (10.0.0.122) 56(84) bytes of data. > > --- 10.0.0.122 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3012ms > > Which is weird. It's a /30 tap link that's been brought up by OpenVPN, > and I'm trying to avoid any config done by XORP for that. > > > -- > Ask me about Linux virtual servers. > A80F D3A0 0EFA23FE@wwwkeys.eu.pgp.net > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From caluml@gmail.com Fri Feb 24 23:01:18 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 23:01:18 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <19604460.7491140821369763.JavaMail.root@mail.vyatta.com> References: <19604460.7491140821369763.JavaMail.root@mail.vyatta.com> Message-ID: <635498b70602241501h3670615fl739416a12b57b3eb@mail.gmail.com> Hello Mike, (Thanks for your help with this, btw). You did ask me to change next-hop to 10.0.0.122 which is the address of the local host. (I have changed next hop to 10.0.0.121 but no difference). I think the peering is OK, as I receive the routes in "show bgp routes". (But I'm new to xorp, so maybe not..) Here is route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.76 0.0.0.0 255.255.255.252 U 0 0 0 tapanother 10.0.0.120 0.0.0.0 255.255.255.252 U 0 0 0 taphush 82.x.x.x 0.0.0.0 255.255.255.248 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 82.x.x.x 0.0.0.0 UG 0 0 0 eth0 > show interfaces taphush/taphush: Flags: mtu 1500 physical index 12 ether 4a:12:38:a6:de:7c The problem being unable to ping .122 (local) was just a firewall rule. The link is up, and fine: # ping 10.0.0.121 PING 10.0.0.121 (10.0.0.121) 56(84) bytes of data. 64 bytes from 10.0.0.121: icmp_seq=1 ttl=64 time=1.19 ms 64 bytes from 10.0.0.121: icmp_seq=2 ttl=64 time=0.735 ms --- 10.0.0.121 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.735/0.962/1.190/0.229 ms From pavlin@icir.org Fri Feb 24 23:06:53 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Feb 2006 15:06:53 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Calum of "Fri, 24 Feb 2006 21:52:49 GMT." <635498b70602241352v2b12dc6awc997c4a16ef00142@mail.gmail.com> Message-ID: <200602242306.k1ON6rSk012317@possum.icir.org> > How does xorp handle an interface disappearing, and coming back, out > of interest? If the interface status changes (e.g., UP/DOWN, IP addresses added/deleted), and you are using the default-system-config statement, then XORP is tracking the changes. If the interface disappears completely (e.g., you cannot see it by "ifconfig -a" or "ip link"), then I am afraid XORP may not be able to track it properly (translation: I haven't tested it). If your case is the latter, what are the exact UNIX commands (or setup) you use to get the interface disappear and add it back again? Pavlin From mhorn@vyatta.com Fri Feb 24 23:14:55 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 24 Feb 2006 15:14:55 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <16883090.7551140822895983.JavaMail.root@mail.vyatta.com> Hi Calum, No problem, hopefully we'll get this figured out. Changing the "next-hop" to the peer address will only affect BGP updates sourced from this router (the peer router won't like the updates because they have a NEXT_HOP of it's own address) so I would changee it to 10.0.0.122. If you can send the output from "show" in configuration-mode, I want to see how the tunnel interface is configured in XORP and the FEA configuration. I'm thinking there is something related to how XORP is registering the interface that is causing the issue, but we'll need to dig further to find out. -mike ----- Original Message ----- From: Calum To: Mike Horn Cc: xorp-users@xorp.org Sent: Friday, February 24, 2006 4:01:18 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap Hello Mike, (Thanks for your help with this, btw). You did ask me to change next-hop to 10.0.0.122 which is the address of the local host. (I have changed next hop to 10.0.0.121 but no difference). I think the peering is OK, as I receive the routes in "show bgp routes". (But I'm new to xorp, so maybe not..) Here is route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.76 0.0.0.0 255.255.255.252 U 0 0 0 tapanother 10.0.0.120 0.0.0.0 255.255.255.252 U 0 0 0 taphush 82.x.x.x 0.0.0.0 255.255.255.248 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 82.x.x.x 0.0.0.0 UG 0 0 0 eth0 > show interfaces taphush/taphush: Flags: mtu 1500 physical index 12 ether 4a:12:38:a6:de:7c The problem being unable to ping .122 (local) was just a firewall rule. The link is up, and fine: # ping 10.0.0.121 PING 10.0.0.121 (10.0.0.121) 56(84) bytes of data. 64 bytes from 10.0.0.121: icmp_seq=1 ttl=64 time=1.19 ms 64 bytes from 10.0.0.121: icmp_seq=2 ttl=64 time=0.735 ms --- 10.0.0.121 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.735/0.962/1.190/0.229 ms From caluml@gmail.com Fri Feb 24 23:36:17 2006 From: caluml@gmail.com (Calum) Date: Fri, 24 Feb 2006 23:36:17 +0000 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: <200602242306.k1ON6rSk012317@possum.icir.org> References: <635498b70602241352v2b12dc6awc997c4a16ef00142@mail.gmail.com> <200602242306.k1ON6rSk012317@possum.icir.org> Message-ID: <635498b70602241536u72021d4ex8b463f20918356d5@mail.gmail.com> Hello Pavlin, The "unable to ping" problem was just a firewall rule, and isn't an issue any more. Yes, the thing I am thinking about is not just up/down, but actually killing the process that creates the tap. Let me try it out, and see what happens: bash # kill 24904 bash # ifconfig taphush taphush: error fetching interface information: Device not found bash # ip link show taphush Device "taphush" does not exist. bash # Nothing untoward appeared in the window that is running xorp_rtrmgr in. However, xorp seems to be unaware that it's gone. # bin/xorpsh Welcome to XORP on torro root@torro> show interfaces taphush/taphush: Flags: mtu 1500 physical index 12 ether 4a:12:38:a6:de:7c Running commit causes this sort of thing: [ 2006/02/24 23:23:08 INFO xorp_bgp BGP ] Sending: Notification Packet: Hold Timer Expired(4) [ 2006/02/24 23:23:08 ERROR xorp_bgp:25341 LIBCOMM +354 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.0.0.122, my_port = 0): Cannot assign requested address Which is fair enough. If I start the process back up... # ./start-tap # ifconfig taphush taphush Link encap:Ethernet HWaddr 42:98:7F:BF:54:95 inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 > show bgp peers detail Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 Peer ID: 10.0.0.1 Peer State: ESTABLISHED Admin State: START So it seems to pick it back up fairly painlessly. Anyway, back to the main problem. :) I've set the next-hop and local-ip both to 1.0.0.122, but I'm not seeing any routes via route -n. Do I need to specify what routes I will allow to be accepted or something? Or do I need to add a network statement for the /30 link between the two routers or something like that? C > show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.0.0.0/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.4/30 10.0.0.121 10.0.0.1 1 i ...... snip lots of lines. So I'm getting the routes in from AS 1 ( 10.0.0.121). But route -n at the shell doesn't show any of them. From pavlin@icir.org Fri Feb 24 23:58:25 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Feb 2006 15:58:25 -0800 Subject: [Xorp-users] Xorp, pimsm and ethertap In-Reply-To: Message from Calum of "Fri, 24 Feb 2006 23:36:17 GMT." <635498b70602241536u72021d4ex8b463f20918356d5@mail.gmail.com> Message-ID: <200602242358.k1ONwPAF012746@possum.icir.org> > Yes, the thing I am thinking about is not just up/down, but actually > killing the process that creates the tap. > Let me try it out, and see what happens: > > bash # kill 24904 > bash # ifconfig taphush > taphush: error fetching interface information: Device not found > bash # ip link show taphush > Device "taphush" does not exist. > bash # > > Nothing untoward appeared in the window that is running xorp_rtrmgr in. > > However, xorp seems to be unaware that it's gone. > # bin/xorpsh > Welcome to XORP on torro > root@torro> show interfaces > taphush/taphush: Flags: mtu 1500 > physical index 12 > ether 4a:12:38:a6:de:7c > > Running commit causes this sort of thing: > > [ 2006/02/24 23:23:08 INFO xorp_bgp BGP ] Sending: Notification > Packet: Hold Timer Expired(4) > [ 2006/02/24 23:23:08 ERROR xorp_bgp:25341 LIBCOMM +354 comm_sock.c > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = > 10.0.0.122, my_port = 0): Cannot assign requested address > > Which is fair enough. > If I start the process back up... > > # ./start-tap > # ifconfig taphush > taphush Link encap:Ethernet HWaddr 42:98:7F:BF:54:95 > inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 > > > show bgp peers detail > Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 > Peer ID: 10.0.0.1 > Peer State: ESTABLISHED > Admin State: START > > So it seems to pick it back up fairly painlessly. Yes, so far in the implementation we didn't consider the case when the interface disappears completely, hence "show interfaces" is still displaying the deleted interface. Please submit a bugzilla entry about the issue with the above information, but please don't forget to include the content of your "start-tap" script. A possible work-around is for you to have a script to delete the tap interface, and in that script the first thing to do is to use xorpsh in non-interactive mode to delete the taphush interface from the XORP config. E.g., #!/bin/sh xorpsh < of "Thu, 23 Feb 2006 14:49:05 CST." <199401c638ba$95e01140$381da8c0@dorino> Message-ID: <200602250049.k1P0nYAl013181@possum.icir.org> > Sorry for the long introduction, but I think a bit of a background is = > necessary: > I have a GRE tunnel going over a VPN and multicast+PIM-SM traffic going = > through this GRE tunnel.=20 > The other side is a Cisco router, don't know exactly the model + IOS = > release.=20 > All of this is fully operational on my side on a Cisco router as well, = > with the following configuration: > 2611XM with an AIM VPN/BP encryption module, running = > c2600-ik9o3s-mz.122-27.=20 > > The problem is that the CPU usage is very high on the Cisco on my end. > Even though the specs say this setup should handle up to 10Mbps of = > encrypted traffic (with packets at near-MTU size), > I get this high CPU usage at much lower traffic rates, as in 1 to = > 1.5Mbps.=20 > Because of this, I tried to replicate the same configuration on a = > Soekris net4801 box (with a vpn1411 VPN accelerator card),=20 > running on OpenBSD 3.8. The only modification from the stock 3.8 kernel = > was to add support for PIM:=20 > option PIM # Protocol Independent Multicast I don't remember what the default OpenBSD kernel configuration is, but make sure that you have the following option as well: option MROUTING # Multicast router In addition, add the following lines to /etc/rc.conf.local and reboot: # Enable multicast routing (see netstart(8) for details). multicast_host=NO multicast_router=YES The above should be covered in the PIM-SM section of the XORP user manual. This should fix the "No route to host" for the multicast sendmsg(). The remaining issue(s) should be addressed after the above changes. FYI, two days ago the XORP-1.2-RC (Release Candidate) was released so I'd recommend to use it instead of XORP-1.1, because the PIM-SM implementation has a number of fixes since 1.1. Pavlin > [ 2006/02/22 18:22:50 ERROR xorp_fea:5723 MFEA +1781 mfea_proto_comm.cc = > proto_socket_write ] sendmsg(proto 103 from 10.167.1.46 to 224.0.0.13 on = > vif gre > 0) failed: No route to host. From deathdealer@gmx.net Sat Feb 25 08:08:13 2006 From: deathdealer@gmx.net (Patrick Marc Preuss) Date: Sat, 25 Feb 2006 09:08:13 +0100 Subject: [Xorp-users] troubles with PIM-SM In-Reply-To: <199401c638ba$95e01140$381da8c0@dorino> References: <199401c638ba$95e01140$381da8c0@dorino> Message-ID: <4400106D.6060502@gmx.net> Hello Dorin, Dorin Olarov said the following on 23.02.2006 21:49: > Hello all, > > Sorry for the long introduction, but I think a bit of a background is > necessary: > I have a GRE tunnel going over a VPN and multicast+PIM-SM traffic > going through this GRE tunnel. > The other side is a Cisco router, don't know exactly the model + IOS > release. > All of this is fully operational on my side on a Cisco router as well, > with the following configuration: > 2611XM with an AIM VPN/BP encryption module, running > c2600-ik9o3s-mz.122-27. Witch kind of VPN you are using? Lan-2-Lan How is encryption handelt? How is fragmentation handelt? Before IPsec or after ipsec Can you mail a "show process cpu sorted" form the cisco? What is running on the Cisco? Netflow, cef, etc. Is the encryption aim enabled? > > The problem is that the CPU usage is very high on the Cisco on my end. > Even though the specs say this setup should handle up to 10Mbps of > encrypted traffic (with packets at near-MTU size), > I get this high CPU usage at much lower traffic rates, as in 1 to 1.5Mbps. Sounds the cisco is doing the encryption in software or you have a high fragementaion rate on the router Have you access to other cisco ios versions? if yes can you try to use a release 12.4.xx Than you can set "int e0/0" ip tcp mss-adjust 1350" the problem on the ciscos is how fragmentation is handelt, before ipsec, gre or after maybe lower the mtu on the gre tunnel to 1350. > Any suggestions? > > Thank you, > Dorin. > regards Patrick Marc From mhorn@vyatta.com Sat Feb 25 08:21:23 2006 From: mhorn@vyatta.com (Mike Horn) Date: Sat, 25 Feb 2006 00:21:23 -0800 (PST) Subject: [Xorp-users] Xorp, pimsm and ethertap Message-ID: <28501562.8241140855683295.JavaMail.root@mail.vyatta.com> Hi Calum, You do not need to explicitly allow routes in BGP, the implicit policy is to allow all. The problem you are seeing typically occurs when the nexthop lookup fails for the BGP route entry and therefore the route is not installed in the RIB. Since we can see the connected route for 10.0.0.120/30 in the routing table this does not appear to be the issue. Fortunately I have a theory, I think that XORP might not be properly registering the link state of the tunnel interface, so even though the route exists they are not being installed in the RIB. Is it possible for you to test via a non-tunneled connection to another device running BGP? This would help narrow down whether the issue is the tunnel interface or something more fundamental on your system. Unfortunately I won't be able to test a tunnel interface until Tuesday, but hopefully we'll have it figured out by then. -mike ----- Original Message ----- From: Calum To: Pavlin Radoslavov Cc: Mike Horn , xorp-users@xorp.org Sent: Friday, February 24, 2006 4:36:17 PM GMT-0700 Subject: Re: [Xorp-users] Xorp, pimsm and ethertap Hello Pavlin, The "unable to ping" problem was just a firewall rule, and isn't an issue any more. Yes, the thing I am thinking about is not just up/down, but actually killing the process that creates the tap. Let me try it out, and see what happens: bash # kill 24904 bash # ifconfig taphush taphush: error fetching interface information: Device not found bash # ip link show taphush Device "taphush" does not exist. bash # Nothing untoward appeared in the window that is running xorp_rtrmgr in. However, xorp seems to be unaware that it's gone. # bin/xorpsh Welcome to XORP on torro root@torro> show interfaces taphush/taphush: Flags: mtu 1500 physical index 12 ether 4a:12:38:a6:de:7c Running commit causes this sort of thing: [ 2006/02/24 23:23:08 INFO xorp_bgp BGP ] Sending: Notification Packet: Hold Timer Expired(4) [ 2006/02/24 23:23:08 ERROR xorp_bgp:25341 LIBCOMM +354 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 10.0.0.122, my_port = 0): Cannot assign requested address Which is fair enough. If I start the process back up... # ./start-tap # ifconfig taphush taphush Link encap:Ethernet HWaddr 42:98:7F:BF:54:95 inet addr:10.0.0.122 Bcast:10.0.0.123 Mask:255.255.255.252 > show bgp peers detail Peer 1: local 10.0.0.122/179 remote 10.0.0.121/179 Peer ID: 10.0.0.1 Peer State: ESTABLISHED Admin State: START So it seems to pick it back up fairly painlessly. Anyway, back to the main problem. :) I've set the next-hop and local-ip both to 1.0.0.122, but I'm not seeing any routes via route -n. Do I need to specify what routes I will allow to be accepted or something? Or do I need to add a network statement for the /30 link between the two routers or something like that? C > show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.0.0.0/30 10.0.0.121 10.0.0.1 1 i * 10.0.0.4/30 10.0.0.121 10.0.0.1 1 i ...... snip lots of lines. So I'm getting the routes in from AS 1 ( 10.0.0.121). But route -n at the shell doesn't show any of them. _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From caluml@gmail.com Sat Feb 25 11:50:08 2006 From: caluml@gmail.com (Calum) Date: Sat, 25 Feb 2006 11:50:08 +0000 Subject: [Xorp-users] Vifs Message-ID: <635498b70602250350m388d8a2bxdab9b56a6f2cf24c@mail.gmail.com> Hello all, I configured my interfaces like this: interfaces { interface taphush { default-system-config disable: false discard: false description: "" vif taphush { disable: false } } restore-original-config-on-shutdown: false } but upon reading the user doc, it says: "If the default-system-config statement is used ...... In that case, the vif and address sections must not be configured." So I remove the vif statement: # delete interfaces interface taphush vif taphush Deleting: taphush { } OK # commit Commit Failed 102 Command failed Failed executing: "RemoveInterfaceVif: taphush taphush"[edit] Does this mean that I **do** need to have the vif statement in there? Or is it a problem related to tap/tun interfaces? Trying to save gives me this: # save config.boot Finder disconnected. No Finder? ERROR: Save failed. Failed to communicate save command to rtrmgr. Transport failed >From the logs: [ 2006/02/25 11:44:39 ERROR xorp_rtrmgr:10705 RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Failed executing: "RemoveInterfaceVif: taphush taphush" *** glibc detected *** double free or corruption (!prev): 0x0000555555e803a0 *** Aborted and the xorp_rtrmgr dies. However, xorp_fea,rib,policy, and bgp remain running. Calum -- http://zapee.com - Linux virtual servers, IPv4+6 web hosting A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net From caluml@gmail.com Sat Feb 25 12:01:21 2006 From: caluml@gmail.com (Calum) Date: Sat, 25 Feb 2006 12:01:21 +0000 Subject: [Xorp-users] BGP network statements Message-ID: <635498b70602250401g546a524bx9cd4627042ff1f9a@mail.gmail.com> Hello again, Since I removed that vif statement, my BGP routes have appeared in my kernel routing table - which is good news :) However, I can't work out from the docs how to add a network 10.20.30.0/24 route to be advertised. I would expect it to be something like create protocols bgp network 10.20.30.0/24, or perhaps peer-specific? Can anyone tell me where this option lives? Calum -- http://zapee.com - Linux virtual servers, IPv4+6 web hosting A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net From tdurack@gmail.com Sat Feb 25 15:58:22 2006 From: tdurack@gmail.com (Tim Durack) Date: Sat, 25 Feb 2006 10:58:22 -0500 Subject: [Xorp-users] BGP network statements In-Reply-To: <635498b70602250401g546a524bx9cd4627042ff1f9a@mail.gmail.com> References: <635498b70602250401g546a524bx9cd4627042ff1f9a@mail.gmail.com> Message-ID: <9e246b4d0602250758i1c9a1110je720e8115705e83@mail.gmail.com> ------=_Part_4655_26100577.1140883102233 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 2/25/06, Calum wrote: > > Hello again, > > Since I removed that vif statement, my BGP routes have appeared in my > kernel routing table - which is good news :) Makes sense - sounds like the route for the next hop was never installed, which is why the BGP routes did not show up. I have been running a tunnel setup, using gre tunnels to simulate direct connections between virtual XORP routers. The tunnels are created by a linux script outside of XORP. The tunnel interface is then configured in XORP simply to give it an ip. It then looks like a real interface in the config. Running BGP in this scenario works fine. However, I can't work out from the docs how to add a network > 10.20.30.0/24 route to be advertised. > > I would expect it to be something like create protocols bgp network > 10.20.30.0/24, or perhaps peer-specific? > Can anyone tell me where this option lives? I believe for 1.2rc you should create a static route, and export static int= o BGP using policy: protocols { static { =09route4 10.20.30.0/24 { =09 next-hop: 10.20.30.1 } } } policy { policy-statement static-routes { term export { from { protocol: "static" } } } } protocols { bgp { bgp-id: 10.0.1.1 local-as: 65014 peer 192.168.0.2 { local-ip: 192.168.0.1 as: 65004 next-hop: 192.168.0.1 } export: "static-routes" } } This was adapted from advice Atanu gave on redistributing connected routes, but the same concept should apply to static. Tim:> ------=_Part_4655_26100577.1140883102233 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 2/25/06, Calum <caluml@gmail.com<= /a>> wrote:
Hello again,

Since I removed that vif statement, my BGP routes have = appeared in my
kernel routing table  - which is good news :)

Makes sense - sounds like the route for the next hop wa= s never installed, which is why the BGP routes did not show up.

I have been running a tunnel setup, using gre tunnels to simulate d= irect connections between virtual XORP routers.

The tunnels are crea= ted by a linux script outside of XORP. The tunnel interface is then configu= red in XORP simply to give it an ip. It then looks like a real interface in= the config.

Running BGP in this scenario works fine.

However, I can't work out from= the docs how to add a network
10.20.30.0/24 route to be advertis= ed.

I would expect it to be something like create protocols bgp netw= ork
10.20.30.0/24, or perhaps peer-spe= cific?
Can anyone tell me where this option lives?

I beli= eve for 1.2rc you should create a static route, and export static into BGP = using policy:
protocols {
    static {
=09route4 
10.20.30.0/24 {
=09    next-hop: 10.20=
.30.1
        }
    }
}

policy {
    polic=
y-statement static-routes {

        term export {
       &nbs=
p;    from {
              =
  protocol: "static"
           =
 }
        }
    }
}

pro=
tocols {
    bgp {
        bgp-id: 
10.0.1.1
        local-as: 65014

   =
     peer 192.168.0.2 {<=
br>            local-ip: 
192.168.0.1
            as: 65004
 =
           next-hop: 192.168.0.1
        }
        
   =
     export: "
static-routes"
    }
}
This was adapted from advice Atanu gave on redist= ributing connected routes, but the same concept should apply to static.
=
Tim:>

------=_Part_4655_26100577.1140883102233-- From mhorn@vyatta.com Mon Feb 27 16:16:14 2006 From: mhorn@vyatta.com (Mike Horn) Date: Mon, 27 Feb 2006 08:16:14 -0800 (PST) Subject: [Xorp-users] BGP network statements Message-ID: <11602045.871141056974416.JavaMail.root@mail.vyatta.com> Hi Calum, Glad to hear that you were able to get your BGP routes working. The best way to advertise a network into BGP is to use a policy that you then apply to the BGP process (XORP is working on adding the capability to apply policies per-peer). For you example here is what should be done: <<< CREATE STATIC ROUTE >>> create protocols static route4 10.20.30.0/24 next-hop A.B.C.D <<< CREATE POLICY >>> create policy policy-statement REDIST_STATIC term 1 from protocols static create policy policy-statement REDIST_STATIC term 1 then accept (if you want to limit the redistribution to *just* the network discussed add:) create policy policy-statement REDIST_STATIC term 1 from network4 10.20.30.0/24 <<< commit >>> I prefer to commit before applying to BGP to make sure if there were any issues with the policy that I can fix them first. commit <<< APPLY POLICY TO BGP >>> create protocols bgp export REDIST_STATIC commit Let me know if you have any problems with this configuration in your environment. -mike ----- Original Message ----- From: Calum To: xorp-users@xorp.org Sent: Saturday, February 25, 2006 5:01:21 AM GMT-0700 Subject: [Xorp-users] BGP network statements Hello again, Since I removed that vif statement, my BGP routes have appeared in my kernel routing table - which is good news :) However, I can't work out from the docs how to add a network 10.20.30.0/24 route to be advertised. I would expect it to be something like create protocols bgp network 10.20.30.0/24, or perhaps peer-specific? Can anyone tell me where this option lives? Calum -- http://zapee.com - Linux virtual servers, IPv4+6 web hosting A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Tue Feb 28 01:43:35 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 27 Feb 2006 17:43:35 -0800 Subject: [Xorp-users] Vifs In-Reply-To: Message from Calum of "Sat, 25 Feb 2006 11:50:08 GMT." <635498b70602250350m388d8a2bxdab9b56a6f2cf24c@mail.gmail.com> Message-ID: <200602280143.k1S1hZCN065090@possum.icir.org> > I configured my interfaces like this: > > interfaces { > interface taphush { > default-system-config > disable: false > discard: false > description: "" > vif taphush { > disable: false > } > } > restore-original-config-on-shutdown: false > } > > but upon reading the user doc, it says: > > "If the default-system-config statement is used ...... In that case, > the vif and address sections must not be configured." > > So I remove the vif statement: > > # delete interfaces interface taphush vif taphush > Deleting: > taphush { > } > > OK > # commit > Commit Failed > 102 Command failed Failed executing: "RemoveInterfaceVif: taphush taphush"[edit] > > Does this mean that I **do** need to have the vif statement in there? > Or is it a problem related to tap/tun interfaces? You shouldn't have added the vif statement in your configuration even during the startup. FYI, I tried to repeat your experiment, but I couldn't trigger the above error (and the rtrmgr crash below). What version of XORP are you using and what OS? In my experiment I was using the lastest XORP code from CVS and Linux (Fedora Core 4). Pavlin > > Trying to save gives me this: > > # save config.boot > Finder disconnected. No Finder? > ERROR: Save failed. > Failed to communicate save command to rtrmgr. > Transport failed > > >From the logs: > > [ 2006/02/25 11:44:39 ERROR xorp_rtrmgr:10705 RTRMGR +671 > master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command > failed Failed executing: "RemoveInterfaceVif: taphush taphush" > *** glibc detected *** double free or corruption (!prev): 0x0000555555e803a0 *** > Aborted > > and the xorp_rtrmgr dies. > However, xorp_fea,rib,policy, and bgp remain running. > > Calum > > > -- > http://zapee.com - Linux virtual servers, IPv4+6 web hosting > A80F D3A0 0EFA 23FE@wwwkeys.eu.pgp.net > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users