From caluml@gmail.com Sat Apr 1 15:24:13 2006 From: caluml@gmail.com (Calum) Date: Sat, 1 Apr 2006 16:24:13 +0100 Subject: [Xorp-users] Multicast problems Message-ID: <635498b70604010724j577c49abr46d3a22905500eec@mail.gmail.com> Hello all, I have a very simple network here (as I don't have enough machines to make a more complicated one!). Source | Router | Client Source and Router are running XORP - they are neighbors in show pim neighbors and seem to be exchanging information fine (holding RP elections, etc) Source is sending traffic out to a multicast address, and that traffic can be seen at Router (on the interface connected to Source). Client joins the group (using a c program), and Router sees the join: [ 2006/04/01 16:19:52 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.0.0.30 to 229.9.9.9 on vif eth2 [ 2006/04/01 16:19:52 TRACE xorp_pimsm4 PIM ] Add membership for (0.0.0.0, 229.9.9.9) on vif eth2 [ 2006/04/01 16:19:52 TRACE xorp_pimsm4 PIM ] Add MFC entry: (10.0.0.121, 229.9.9.9) iif = 1 olist = O.O olist_disable_wrongvif = .O. [ 2006/04/01 16:19:54 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.0.0.30 to 229.9.9.9 on vif eth2 However, Router doesn't start forwarding the traffic from Source to 229.9.9.9 to Client. It still comes in, but doesn't get forwarded anywhere. What's that stuff about "disable_wrongvif", by the way? Calum From pavlin@icir.org Sat Apr 1 19:18:14 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 01 Apr 2006 11:18:14 -0800 Subject: [Xorp-users] Multicast problems In-Reply-To: Message from Calum of "Sat, 01 Apr 2006 16:24:13 +0100." <635498b70604010724j577c49abr46d3a22905500eec@mail.gmail.com> Message-ID: <200604011918.k31JIE8n098952@possum.icir.org> > I have a very simple network here (as I don't have enough machines to > make a more complicated one!). > > Source > | > Router > | > Client > > > Source and Router are running XORP - they are neighbors in show pim > neighbors and seem to be exchanging information fine (holding RP > elections, etc) > > Source is sending traffic out to a multicast address, and that traffic > can be seen at Router (on the interface connected to Source). > > > Client joins the group (using a c program), and Router sees the join: > > [ 2006/04/01 16:19:52 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 10.0.0.30 to 229.9.9.9 on vif eth2 > [ 2006/04/01 16:19:52 TRACE xorp_pimsm4 PIM ] Add membership for > (0.0.0.0, 229.9.9.9) on vif eth2 > [ 2006/04/01 16:19:52 TRACE xorp_pimsm4 PIM ] Add MFC entry: > (10.0.0.121, 229.9.9.9) iif = 1 olist = O.O olist_disable_wrongvif = > .O. > [ 2006/04/01 16:19:54 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT from 10.0.0.30 to 229.9.9.9 on vif eth2 > > However, Router doesn't start forwarding the traffic from Source to > 229.9.9.9 to Client. > It still comes in, but doesn't get forwarded anywhere. Two generic potential problems (they should go into the FAQ): 1. Check the TTL of the multicast data traffic at the sender is large enough. By default, the TTL is 1 and packets with such TTL won't be forwarded. 2. Check that there are no firewall rules in the Router that prevent it from forwarding the multicast data packes. > What's that stuff about "disable_wrongvif", by the way? This is to disable the "IGMPMSG_WRONGVIF" kernel signal on particular interfaces, but it is no-op on Linux. See multicast(4) on a recent BSD system for details. E.g.: http://www.freebsd.org/cgi/man.cgi?query=multicast&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Pavlin From eezhao@msn.com Sun Apr 2 08:53:10 2006 From: eezhao@msn.com (Eddie Zhao) Date: Sat, 01 Apr 2006 23:53:10 -0800 Subject: [Xorp-users] Is there a doc talking about how to compile XORP for windows plaftform? Message-ID: Hi! There: Is there a detailed doc talking about how to compile the XORP source code I downloaded from XORP website or Windows Platform. I already downloaded the XORP source code and the MinGW required for windows compiling. But I don't know the exact steps about compiling it. the steps for Linux OS is pretty simple, but how to do that for windows? thanks Eddie From bms@spc.org Sun Apr 2 11:00:28 2006 From: bms@spc.org (Bruce M Simpson) Date: Sun, 2 Apr 2006 11:00:28 +0100 Subject: [Xorp-users] Is there a doc talking about how to compile XORP for windows plaftform? In-Reply-To: References: Message-ID: <20060402100028.GF80492@spc.org> On Sat, Apr 01, 2006 at 11:53:10PM -0800, Eddie Zhao wrote: > Is there a detailed doc talking about how to compile the XORP source code I > downloaded from XORP website or Windows Platform. Please see the BUILD_NOTES document in the root of the source tree. BMS From peter@maersk-moller.net Tue Apr 4 02:33:40 2006 From: peter@maersk-moller.net (Peter Maersk-Moller) Date: Tue, 04 Apr 2006 03:33:40 +0200 Subject: [Xorp-users] Problem with filtering BGP Message-ID: <4431CCF4.1000705@maersk-moller.net> Hi I'm trying to export a few networks to all my external BGP peers and import all their advertised routes. However all received routes on ebgp are not included into the internal (final) routing table. So obviously I'm doing something wrong, but what ? Here is my policy. The list "tobeincluded are the networks to be announced to ebgp peers. I do receive a lot of announcements from peers, but none of them ends up in the final table and subsequenly can't be seen by the unix command # route -n What am I doing wrong ? The term drop is used to make sure I don't advertise to ebgp peers any routes learned from other ebgp peers, but obviously my policy fails. What should I do instead ? Kind regards --PMM policy { network4-list tobeincluded { elements: "83.137.32.0/24,83.137.33.0/24" } policy-statement bgpconnected { term acceptown { from { protocol: "connected" network4-list: "tobeincluded" } then { accept } } term drop { from { protocol: "bgp" } then { reject } } } } protocols { bgp { bgp-id: 192.38.7.16 local-as: 31397 /* export: "static" */ export: "bgpconnected" ..... -- +----------------------------------------------------------+ | Kabel-TV over Internettet -- http://www.streamtv.dk/ | +----------------------------------------------------------+ From mhorn@vyatta.com Tue Apr 4 18:39:04 2006 From: mhorn@vyatta.com (Mike Horn) Date: Tue, 4 Apr 2006 10:39:04 -0700 (PDT) Subject: [Xorp-users] Problem with filtering BGP Message-ID: <22473789.14181144172344019.JavaMail.root@mail.vyatta.com> Hi Peter, Can you send the output from "show bgp routes", "ifconfig", and "route -n". In general policies should not stop prefixes that are in the BGP table from being installed in the routing table (the policies should restrict what goes into & out of the BGP table). Prefixes from the BGP table not getting installed in the routing table is usually caused by an unreachable next-hop. If you send the requested information we should be able to determine what is not working. -mike ----- Original Message ----- From: Peter Maersk-Moller To: xorp-users@xorp.org Sent: Monday, April 3, 2006 7:33:40 PM GMT-0700 Subject: [Xorp-users] Problem with filtering BGP Hi I'm trying to export a few networks to all my external BGP peers and import all their advertised routes. However all received routes on ebgp are not included into the internal (final) routing table. So obviously I'm doing something wrong, but what ? Here is my policy. The list "tobeincluded are the networks to be announced to ebgp peers. I do receive a lot of announcements from peers, but none of them ends up in the final table and subsequenly can't be seen by the unix command # route -n What am I doing wrong ? The term drop is used to make sure I don't advertise to ebgp peers any routes learned from other ebgp peers, but obviously my policy fails. What should I do instead ? Kind regards --PMM policy { network4-list tobeincluded { elements: "83.137.32.0/24,83.137.33.0/24" } policy-statement bgpconnected { term acceptown { from { protocol: "connected" network4-list: "tobeincluded" } then { accept } } term drop { from { protocol: "bgp" } then { reject } } } } protocols { bgp { bgp-id: 192.38.7.16 local-as: 31397 /* export: "static" */ export: "bgpconnected" ..... -- +----------------------------------------------------------+ | Kabel-TV over Internettet -- http://www.streamtv.dk/ | +----------------------------------------------------------+ _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From acb@cs.princeton.edu Tue Apr 4 18:59:19 2006 From: acb@cs.princeton.edu (Andy Bavier) Date: Tue, 04 Apr 2006 13:59:19 -0400 Subject: [Xorp-users] OSPF network advertisements Message-ID: <4432B3F7.6080102@cs.princeton.edu> Hi, I am trying to configure XORP to advertise routes to a local network using OSPF. My problem is that only the interface *address* appears to be advertised, and not the entire network -- in other words, only a /32 address is inserted into the routing table and not a /24. My question is, how to get OSPF to advertise and route to the /24? My OSPF configuration looks like this. Interface 'eth0' is on a /24 network. I expected that by setting eth0 as 'passive' I could get OSPF to advertise routes for the attached network, without actually running OSPF on this interface: protocols { ospf4 { router-id: 128.112.139.96 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.32.11.2 { interface-cost: 1 passive: true } } } interface eth1 { vif eth1 { address 192.168.1.2 { interface-cost: 1 } } } interface eth2 { vif eth2 { address 192.168.2.2 { interface-cost: 1 } } } } } } OSPF appears to be working correctly, and 'eth0' is being advertised. However, all of the installed routes have masks of 255.255.255.255: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 192.168.2.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 10.32.11.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 [...] From what I can tell, it looks like this mask is being propagated in the LSAs themselves: root@planetlab-3.cs.princeton.edu> show ospf4 database detail OSPF link state database, Area 0.0.0.0 Router-LSA: LS age 283 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 128.112.139.96 Advertising Router 128.112.139.96 LS sequence number 0x80000002 LS checksum 0x7da7 length 72 Nt-bit false V-bit false E-bit false B-bit false Type 3 Stub network Subnet number 10.32.11.2 Mask 255.255.255.255 Metric 0 Type 3 Stub network Subnet number 192.168.1.2 Mask 255.255.255.255 Metric 0 Type 3 Stub network Subnet number 192.168.2.2 Mask 255.255.255.255 Metric 0 Does anyone have insights or suggestions on what I need to do to advertise a 255.255.255.0 netmask for eth0? Thanks, Andy From peter@maersk-moller.net Tue Apr 4 22:34:16 2006 From: peter@maersk-moller.net (Peter Maersk-Moller) Date: Tue, 04 Apr 2006 23:34:16 +0200 Subject: [Xorp-users] Problem with filtering BGP In-Reply-To: <22473789.14181144172344019.JavaMail.root@mail.vyatta.com> References: <22473789.14181144172344019.JavaMail.root@mail.vyatta.com> Message-ID: <4432E658.1040100@maersk-moller.net> Hi Mike I think I found the problem and a solution to the problem. Got a little hint from a damn clever guy in Stockholm. The main task of the router config was to establish BGP peerings with external peers. However since I din't want to announce networks learned from each external peer to each other external peer, I needed a "reject" in the export policy for ebgp peerings of all routes learned through (e)bgp. However, as documented in 10.8 of the manual "An export filter [for BGP] is placed on the RIB branch too" I read that as an export filter for (e)bgp peerings is also used for installing routes into the RIB learned through (e)bgp peerings. Since my bgp export policy needed to reject all routes learned through (other) bgp peerings, no routes would be installed into the RIB. An interesting thing though was that while xorp was starting up and learned routes from bgp peers, these routes was actually visible (through the unix route command) for a short while 1-5 seconds and the removed by xorp again. Now the solution as stated in 10.8 in the manual is to add a policy to install the learned routes into the RIB. 10.8 suggest a policy like from installintorib { to { neighbor: 0.0.0.0 } then { accept } } However - that doesn't work. No routes gets installed. I don't understand why. After a series of trial and errors I found that this solution works. from installintorib { to { neighbor: 127.0.0.1 } then { accept } } So, is the documentation wrong ? Or do I have a peculiar setup ? Or do we have a hickup in the source ? BTW, I'm using version xorp 1.2 on Linux 2.6.12.3 SMP. Mike, if you want, I can still send you the suggested info. Just drop me a line saying so. Kind regards Peter Maersk-Moller PS, my policy is now policy { network4-list tobeincluded { elements: "x.y.z.w/n, a.b.c.d/p" } policy-statement bgpconnected { term acceptown { from { protocol: "connected" network4-list: "tobeincluded" } then { accept } } term torib { to { neighbor: 127.0.0.1 } then { accept } } term rejectall { then { reject } } } I would recommend that an example similar to my policy is included in the documentation since bgp peering with peers (without announcing networks from other peers) is a common task for xorp. Mike Horn wrote: > Hi Peter, > Can you send the output from "show bgp routes", "ifconfig", and "route -n". In general policies should not stop prefixes that are in the BGP table from being installed in the routing table (the policies should restrict what goes into & out of the BGP table). Prefixes from the BGP table not getting installed in the routing table is usually caused by an unreachable next-hop. > If you send the requested information we should be able to determine what is not working. > > -mike > > ----- Original Message ----- > From: Peter Maersk-Moller > To: xorp-users@xorp.org > Sent: Monday, April 3, 2006 7:33:40 PM GMT-0700 > Subject: [Xorp-users] Problem with filtering BGP > > Hi > > I'm trying to export a few networks to all my external BGP peers > and import all their advertised routes. However all received > routes on ebgp are not included into the internal (final) routing table. > So obviously I'm doing something wrong, but what ? > > Here is my policy. > > The list "tobeincluded are the networks to be announced to ebgp peers. > I do receive a lot of announcements from peers, but none of them ends > up in the final table and subsequenly can't be seen by the unix > command # route -n > > What am I doing wrong ? > > The term drop is used to make sure I don't advertise to ebgp peers > any routes learned from other ebgp peers, but obviously my policy fails. > > What should I do instead ? > > Kind regards > > --PMM > > policy { > network4-list tobeincluded { > elements: "83.137.32.0/24,83.137.33.0/24" > } > policy-statement bgpconnected { > term acceptown { > from { > protocol: "connected" > network4-list: "tobeincluded" > } > then { > accept > } > } > term drop { > from { > protocol: "bgp" > } > then { > reject > } > } > } > } > protocols { > bgp { > bgp-id: 192.38.7.16 > local-as: 31397 > > /* export: "static" */ > export: "bgpconnected" > ..... > > -- +----------------------------------------------------------+ | Kabel-TV over Internettet -- http://www.streamtv.dk/ | +----------------------------------------------------------+ From peter@maersk-moller.net Tue Apr 4 23:15:13 2006 From: peter@maersk-moller.net (Peter Maersk-Moller) Date: Wed, 05 Apr 2006 00:15:13 +0200 Subject: [Xorp-users] Problem with filtering BGP In-Reply-To: <4432E658.1040100@maersk-moller.net> References: <22473789.14181144172344019.JavaMail.root@mail.vyatta.com> <4432E658.1040100@maersk-moller.net> Message-ID: <4432EFF1.7020805@maersk-moller.net> Hi Mike Turned out I was to fast. The ebgp learned routes are installed (into the kernel), but removed shortly after. Here is the requested data. Suggestions are very welcome. Can't figure out what is wrong. My policy is policy { network4-list tobeincluded { elements: "83.137.32.0/24,83.137.33.0/24" } policy-statement bgpconnected { term acceptown { from { protocol: "connected" network4-list: "tobeincluded" } then { accept } } term torib { to { neighbor: 0.0.0.0..127.0.0.1 } then { accept } } term rejectall { then { reject } } } -------------------------------------------------------------------- root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# xorpsh Welcome to XORP on dix root@dix> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- *> 81.161.128.0/18 192.38.7.12 82.211.224.37 31661 i *> 82.211.224.0/19 192.38.7.12 82.211.224.37 31661 i *> 87.72.0.0/16 192.38.7.12 82.211.224.37 31661 i *> 195.135.216.0/22 192.38.7.12 82.211.224.37 31661 i *> 81.88.0.0/20 192.38.7.75 172.16.16.31 15782 i *> 81.186.240.0/20 192.38.7.75 172.16.16.31 15782 i *> 85.235.0.0/20 192.38.7.75 172.16.16.31 15782 34965 34965 i *> 85.235.16.0/20 192.38.7.75 172.16.16.31 15782 i *> 193.108.42.0/23 192.38.7.75 172.16.16.31 15782 20574 i *> 193.235.206.0/24 192.38.7.75 172.16.16.31 15782 i *> 194.126.249.0/24 192.38.7.75 172.16.16.31 15782 34936 i *> 213.185.0.0/19 192.38.7.75 172.16.16.31 15782 i *> 217.72.48.0/20 192.38.7.75 172.16.16.31 15782 i *> 62.61.134.0/24 192.38.7.64 62.61.128.99 15516 i *> 62.61.135.0/24 192.38.7.64 62.61.128.99 15516 i *> 62.61.128.0/19 192.38.7.64 62.61.128.99 15516 i *> 82.147.224.0/19 192.38.7.64 62.61.128.99 15516 i *> 85.24.0.0/17 192.38.7.64 62.61.128.99 15516 i *> 83.137.32.0/24 83.137.32.1 0.0.0.0 i *> 83.137.33.0/24 83.137.33.146 0.0.0.0 i *> 80.89.16.0/20 192.38.7.58 10.10.3.3 31027 i *> 83.97.96.0/21 192.38.7.58 10.10.3.3 31027 31130 i *> 83.136.88.0/21 192.38.7.58 10.10.3.3 31027 i *> 83.151.128.0/18 192.38.7.58 10.10.3.3 31027 i *> 85.27.128.0/20 192.38.7.58 10.10.3.3 31027 34705 i *> 85.218.128.0/18 192.38.7.58 10.10.3.3 31027 i *> 87.116.0.0/18 192.38.7.58 10.10.3.3 31027 35637 35589 i *> 88.83.64.0/19 192.38.7.58 10.10.3.3 31027 35637 ? *> 193.0.56.0/22 192.38.7.58 10.10.3.3 31027 25111 i *> 193.0.60.0/24 192.38.7.58 10.10.3.3 31027 25111 i *> 193.17.206.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.27.2.0/24 192.38.7.58 10.10.3.3 31027 31130 i *> 193.43.216.0/23 192.38.7.58 10.10.3.3 31027 35637 ? *> 193.47.71.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.47.191.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.163.84.0/22 192.38.7.58 10.10.3.3 31027 i *> 193.163.88.0/21 192.38.7.58 10.10.3.3 31027 i *> 195.10.207.0/24 192.38.7.58 10.10.3.3 31027 ? *> 195.14.14.0/24 192.38.7.58 10.10.3.3 31027 39026 i *> 195.140.132.0/22 192.38.7.58 10.10.3.3 31027 34932 i *> 217.195.176.0/20 192.38.7.58 10.10.3.3 31027 34932 i root@dix> root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A8 inet addr:83.137.33.146 Bcast:83.137.33.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:682479403 errors:4 dropped:0 overruns:0 frame:2 TX packets:3870319 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4173392875 (3980.0 Mb) TX bytes:827260665 (788.9 Mb) Base address:0xa000 Memory:f4020000-f4040000 eth0:1 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A8 inet addr:10.0.0.3 Bcast:10.0.0.7 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Base address:0xa000 Memory:f4020000-f4040000 eth1 Link encap:Ethernet HWaddr 00:03:47:07:E0:AD inet addr:192.38.7.16 Bcast:192.38.7.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13214027 errors:0 dropped:0 overruns:0 frame:0 TX packets:1147594 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1664918278 (1587.7 Mb) TX bytes:845140487 (805.9 Mb) Memory:f5000000-f5020000 eth2 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A9 inet addr:83.137.32.1 Bcast:83.137.32.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:123458390 errors:2 dropped:0 overruns:0 frame:1 TX packets:206576783 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1575500647 (1502.5 Mb) TX bytes:2693271218 (2568.5 Mb) Base address:0xb400 Memory:f2020000-f2040000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:91393729 errors:0 dropped:0 overruns:0 frame:0 TX packets:91393729 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3020260663 (2880.3 Mb) TX bytes:3020260663 (2880.3 Mb) pimreg Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP RUNNING NOARP MTU:1472 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 130.226.1.23 83.137.32.2 255.255.255.255 UGH 0 0 0 eth2 130.226.1.22 83.137.32.2 255.255.255.255 UGH 0 0 0 eth2 239.255.0.22 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 239.255.0.13 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 130.226.1.22 83.137.33.4 255.255.255.254 UG 1 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.248 U 0 0 0 eth0 130.226.208.128 83.137.33.2 255.255.255.128 UG 1 0 0 eth0 83.137.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 83.137.32.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.38.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 83.137.33.2 0.0.0.0 UG 50 0 0 eth0 root@dix> show route table ipv4 unicast final 0.0.0.0/0 [static(1)/50] > to 83.137.33.2 via eth0/eth0 83.137.32.0/24 [connected(0)/0] > via eth2/eth2 83.137.33.0/24 [connected(0)/0] > via eth0/eth0 192.38.7.0/24 [connected(0)/0] > via eth1/eth1 130.226.208.128/25 [static(1)/1] > to 83.137.33.2 via eth0/eth0 130.226.1.22/31 [static(1)/1] > to 83.137.33.4 via eth0/eth0 127.0.0.1/32 [connected(0)/0] > via discard0/discard0 root@dix> root@dix> show route table ipv4 unicast ebgp root@dix> NOTE THIS IS EMPTY <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Peter Maersk-Moller wrote: > Hi Mike > > I think I found the problem and a solution to the problem. Got > a little hint from a damn clever guy in Stockholm. > > The main task of the router config was to establish BGP peerings with > external peers. However since I din't want to announce networks learned > from each external peer to each other external peer, I needed a "reject" > in the export policy for ebgp peerings of all routes learned through > (e)bgp. > However, as documented in 10.8 of the manual > > "An export filter [for BGP] is placed on the RIB branch too" > > I read that as an export filter for (e)bgp peerings is also used > for installing routes into the RIB learned through (e)bgp peerings. > Since my bgp export policy needed to reject all routes learned > through (other) bgp peerings, no routes would be installed into the > RIB. An interesting thing though was that while xorp was starting up > and learned routes from bgp peers, these routes was actually > visible (through the unix route command) for a short while 1-5 seconds > and the removed by xorp again. > > Now the solution as stated in 10.8 in the manual is to add a policy > to install the learned routes into the RIB. 10.8 suggest a policy like > > from installintorib { > to { > neighbor: 0.0.0.0 > } > then { > accept > } > } > > However - that doesn't work. No routes gets installed. I don't > understand why. > After a series of trial and errors I found that this solution works. > > from installintorib { > to { > neighbor: 127.0.0.1 > } > then { > accept > } > } > > So, is the documentation wrong ? Or do I have a peculiar setup ? > Or do we have a hickup in the source ? BTW, I'm using version xorp 1.2 > on Linux 2.6.12.3 SMP. > > Mike, if you want, I can still send you the suggested info. Just drop > me a line saying so. > > Kind regards > > Peter Maersk-Moller > PS, my policy is now > > policy { > network4-list tobeincluded { > elements: "x.y.z.w/n, a.b.c.d/p" > } > policy-statement bgpconnected { > term acceptown { > from { > protocol: "connected" > network4-list: "tobeincluded" > } > then { > accept > } > } > term torib { > to { > neighbor: 127.0.0.1 > } > then { > accept > } > } > term rejectall { > then { > reject > } > } > } > > I would recommend that an example similar to my policy is included > in the documentation since bgp peering with peers (without announcing > networks from other peers) is a common task for xorp. -- +----------------------------------------------------------+ | Kabel-TV over Internettet -- http://www.streamtv.dk/ | +----------------------------------------------------------+ From pavlin@icir.org Wed Apr 5 17:51:03 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 05 Apr 2006 09:51:03 -0700 Subject: [Xorp-users] questions about xorp In-Reply-To: Message from "MANJON@terra.es" of "Thu, 30 Mar 2006 14:37:45 +0200." <20460512.1143722265651.JavaMail.root@cps3> Message-ID: <200604051651.k35Gp31P093368@possum.icir.org> [Note: a follow-up of a slightly old email thread] > > My other question is about an error in my /var/log/messages, when my > xorp d= > > ied > > > > Mar 28 02:01:41 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:41 ERROR > xorp_rtrmgr:2= > > 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive > timeout= > > =20 I don't know whether this will help you, but can you try to increase the keepalive value. To do so you need to edit libxipc/xrl_pf_stcp.cc and recompile. You would need to change only the value of DEFAULT_SENDER_KEEPALIVE_MS. Currently it is 10000 (i.e., 10 seconds). Try, say, 30000 (i.e., 30 seconds). Recently, Dave Price had seen similar keepalive error messages, but so far after increasing the keepalive value he doesn't have them anymore (problem investigation still in progress). Pavlin From mhorn@vyatta.com Wed Apr 5 19:02:43 2006 From: mhorn@vyatta.com (Mike Horn) Date: Wed, 5 Apr 2006 11:02:43 -0700 (PDT) Subject: [Xorp-users] Problem with filtering BGP Message-ID: <2440335.14801144260163450.JavaMail.root@mail.vyatta.com> Hi Peter, Have you tested a configuration with a single BGP peer and no policy? In that case are the BGP routes installed in the RIB? That would help to narrow the issue down to whether issue is related to the policy or something else on the system. My understanding of applying a policy as an "export" to protocol is that this identifies the routes of interest from the RIB to be included in routing updates by the protocol (typically referred to as redistribution). I have had limited success using the policies as route filters within a single protocol (e.g. filter routes learned from one BGP peer to another, see XORP bug 577 as an example). Just to confirm what you are trying to do, you have multiple eBGP peers and you want to learn routes from all of them, but you don't want to announce prefixes learned from one peer to the other peers, is that correct? Depending on who your peers are, another way to try and accomplish this is to have your peers advertise the prefixes to you with the NO_EXPORT community (I have not tested this, but Atanu at XORP thinks it should work). -mike ----- Original Message ----- From: Peter Maersk-Moller To: Mike Horn Cc: xorp-users@xorp.org Sent: Tuesday, April 4, 2006 4:15:13 PM GMT-0700 Subject: Re: [Xorp-users] Problem with filtering BGP Hi Mike Turned out I was to fast. The ebgp learned routes are installed (into the kernel), but removed shortly after. Here is the requested data. Suggestions are very welcome. Can't figure out what is wrong. My policy is policy { network4-list tobeincluded { elements: "83.137.32.0/24,83.137.33.0/24" } policy-statement bgpconnected { term acceptown { from { protocol: "connected" network4-list: "tobeincluded" } then { accept } } term torib { to { neighbor: 0.0.0.0..127.0.0.1 } then { accept } } term rejectall { then { reject } } } -------------------------------------------------------------------- root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# xorpsh Welcome to XORP on dix root@dix> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- *> 81.161.128.0/18 192.38.7.12 82.211.224.37 31661 i *> 82.211.224.0/19 192.38.7.12 82.211.224.37 31661 i *> 87.72.0.0/16 192.38.7.12 82.211.224.37 31661 i *> 195.135.216.0/22 192.38.7.12 82.211.224.37 31661 i *> 81.88.0.0/20 192.38.7.75 172.16.16.31 15782 i *> 81.186.240.0/20 192.38.7.75 172.16.16.31 15782 i *> 85.235.0.0/20 192.38.7.75 172.16.16.31 15782 34965 34965 i *> 85.235.16.0/20 192.38.7.75 172.16.16.31 15782 i *> 193.108.42.0/23 192.38.7.75 172.16.16.31 15782 20574 i *> 193.235.206.0/24 192.38.7.75 172.16.16.31 15782 i *> 194.126.249.0/24 192.38.7.75 172.16.16.31 15782 34936 i *> 213.185.0.0/19 192.38.7.75 172.16.16.31 15782 i *> 217.72.48.0/20 192.38.7.75 172.16.16.31 15782 i *> 62.61.134.0/24 192.38.7.64 62.61.128.99 15516 i *> 62.61.135.0/24 192.38.7.64 62.61.128.99 15516 i *> 62.61.128.0/19 192.38.7.64 62.61.128.99 15516 i *> 82.147.224.0/19 192.38.7.64 62.61.128.99 15516 i *> 85.24.0.0/17 192.38.7.64 62.61.128.99 15516 i *> 83.137.32.0/24 83.137.32.1 0.0.0.0 i *> 83.137.33.0/24 83.137.33.146 0.0.0.0 i *> 80.89.16.0/20 192.38.7.58 10.10.3.3 31027 i *> 83.97.96.0/21 192.38.7.58 10.10.3.3 31027 31130 i *> 83.136.88.0/21 192.38.7.58 10.10.3.3 31027 i *> 83.151.128.0/18 192.38.7.58 10.10.3.3 31027 i *> 85.27.128.0/20 192.38.7.58 10.10.3.3 31027 34705 i *> 85.218.128.0/18 192.38.7.58 10.10.3.3 31027 i *> 87.116.0.0/18 192.38.7.58 10.10.3.3 31027 35637 35589 i *> 88.83.64.0/19 192.38.7.58 10.10.3.3 31027 35637 ? *> 193.0.56.0/22 192.38.7.58 10.10.3.3 31027 25111 i *> 193.0.60.0/24 192.38.7.58 10.10.3.3 31027 25111 i *> 193.17.206.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.27.2.0/24 192.38.7.58 10.10.3.3 31027 31130 i *> 193.43.216.0/23 192.38.7.58 10.10.3.3 31027 35637 ? *> 193.47.71.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.47.191.0/24 192.38.7.58 10.10.3.3 31027 ? *> 193.163.84.0/22 192.38.7.58 10.10.3.3 31027 i *> 193.163.88.0/21 192.38.7.58 10.10.3.3 31027 i *> 195.10.207.0/24 192.38.7.58 10.10.3.3 31027 ? *> 195.14.14.0/24 192.38.7.58 10.10.3.3 31027 39026 i *> 195.140.132.0/22 192.38.7.58 10.10.3.3 31027 34932 i *> 217.195.176.0/20 192.38.7.58 10.10.3.3 31027 34932 i root@dix> root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A8 inet addr:83.137.33.146 Bcast:83.137.33.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:682479403 errors:4 dropped:0 overruns:0 frame:2 TX packets:3870319 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4173392875 (3980.0 Mb) TX bytes:827260665 (788.9 Mb) Base address:0xa000 Memory:f4020000-f4040000 eth0:1 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A8 inet addr:10.0.0.3 Bcast:10.0.0.7 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Base address:0xa000 Memory:f4020000-f4040000 eth1 Link encap:Ethernet HWaddr 00:03:47:07:E0:AD inet addr:192.38.7.16 Bcast:192.38.7.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13214027 errors:0 dropped:0 overruns:0 frame:0 TX packets:1147594 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1664918278 (1587.7 Mb) TX bytes:845140487 (805.9 Mb) Memory:f5000000-f5020000 eth2 Link encap:Ethernet HWaddr 00:E0:81:56:B2:A9 inet addr:83.137.32.1 Bcast:83.137.32.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:123458390 errors:2 dropped:0 overruns:0 frame:1 TX packets:206576783 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1575500647 (1502.5 Mb) TX bytes:2693271218 (2568.5 Mb) Base address:0xb400 Memory:f2020000-f2040000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:91393729 errors:0 dropped:0 overruns:0 frame:0 TX packets:91393729 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3020260663 (2880.3 Mb) TX bytes:3020260663 (2880.3 Mb) pimreg Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP RUNNING NOARP MTU:1472 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) root@dix:/usr/local/depot/2.6.6-i686/xorp-1.2/etc# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 130.226.1.23 83.137.32.2 255.255.255.255 UGH 0 0 0 eth2 130.226.1.22 83.137.32.2 255.255.255.255 UGH 0 0 0 eth2 239.255.0.22 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 239.255.0.13 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 130.226.1.22 83.137.33.4 255.255.255.254 UG 1 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.248 U 0 0 0 eth0 130.226.208.128 83.137.33.2 255.255.255.128 UG 1 0 0 eth0 83.137.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 83.137.32.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.38.7.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 83.137.33.2 0.0.0.0 UG 50 0 0 eth0 root@dix> show route table ipv4 unicast final 0.0.0.0/0 [static(1)/50] > to 83.137.33.2 via eth0/eth0 83.137.32.0/24 [connected(0)/0] > via eth2/eth2 83.137.33.0/24 [connected(0)/0] > via eth0/eth0 192.38.7.0/24 [connected(0)/0] > via eth1/eth1 130.226.208.128/25 [static(1)/1] > to 83.137.33.2 via eth0/eth0 130.226.1.22/31 [static(1)/1] > to 83.137.33.4 via eth0/eth0 127.0.0.1/32 [connected(0)/0] > via discard0/discard0 root@dix> root@dix> show route table ipv4 unicast ebgp root@dix> NOTE THIS IS EMPTY <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Peter Maersk-Moller wrote: > Hi Mike > > I think I found the problem and a solution to the problem. Got > a little hint from a damn clever guy in Stockholm. > > The main task of the router config was to establish BGP peerings with > external peers. However since I din't want to announce networks learned > from each external peer to each other external peer, I needed a "reject" > in the export policy for ebgp peerings of all routes learned through > (e)bgp. > However, as documented in 10.8 of the manual > > "An export filter [for BGP] is placed on the RIB branch too" > > I read that as an export filter for (e)bgp peerings is also used > for installing routes into the RIB learned through (e)bgp peerings. > Since my bgp export policy needed to reject all routes learned > through (other) bgp peerings, no routes would be installed into the > RIB. An interesting thing though was that while xorp was starting up > and learned routes from bgp peers, these routes was actually > visible (through the unix route command) for a short while 1-5 seconds > and the removed by xorp again. > > Now the solution as stated in 10.8 in the manual is to add a policy > to install the learned routes into the RIB. 10.8 suggest a policy like > > from installintorib { > to { > neighbor: 0.0.0.0 > } > then { > accept > } > } > > However - that doesn't work. No routes gets installed. I don't > understand why. > After a series of trial and errors I found that this solution works. > > from installintorib { > to { > neighbor: 127.0.0.1 > } > then { > accept > } > } > > So, is the documentation wrong ? Or do I have a peculiar setup ? > Or do we have a hickup in the source ? BTW, I'm using version xorp 1.2 > on Linux 2.6.12.3 SMP. > > Mike, if you want, I can still send you the suggested info. Just drop > me a line saying so. > > Kind regards > > Peter Maersk-Moller > PS, my policy is now > > policy { > network4-list tobeincluded { > elements: "x.y.z.w/n, a.b.c.d/p" > } > policy-statement bgpconnected { > term acceptown { > from { > protocol: "connected" > network4-list: "tobeincluded" > } > then { > accept > } > } > term torib { > to { > neighbor: 127.0.0.1 > } > then { > accept > } > } > term rejectall { > then { > reject > } > } > } > > I would recommend that an example similar to my policy is included > in the documentation since bgp peering with peers (without announcing > networks from other peers) is a common task for xorp. -- +----------------------------------------------------------+ | Kabel-TV over Internettet -- http://www.streamtv.dk/ | +----------------------------------------------------------+ _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Wed Apr 5 20:11:14 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 05 Apr 2006 12:11:14 -0700 Subject: [Xorp-users] OSPF network advertisements In-Reply-To: Message from Andy Bavier of "Tue, 04 Apr 2006 13:59:19 EDT." <4432B3F7.6080102@cs.princeton.edu> Message-ID: <53557.1144264274@tigger.icir.org> Hi, This is a known problem . Enabling passive sets the interface in the state Loopback, which requires that that host route is announced. There should probably be distinct loopback and passive switches. This patch should solve your problem. ---------------------------------------- Index: peer.cc =================================================================== RCS file: /usr/local/www/data/cvs/xorp/ospf/peer.cc,v retrieving revision 1.237 diff -u -r1.237 peer.cc --- peer.cc 28 Mar 2006 03:06:54 -0000 1.237 +++ peer.cc 5 Apr 2006 19:05:23 -0000 @@ -2164,7 +2164,7 @@ // XXX - We should be checking to see if this is p2p unnumbered. router_link.set_type(RouterLink::stub); router_link.set_link_id(ntohl(get_interface_address().addr())); - router_link.set_link_data(0xffffffff); + router_link.set_link_data(get_network_mask()); router_link.set_metric(0); router_links.push_back(router_link); return; ---------------------------------------- Atanu. >>>>> "Andy" == Andy Bavier writes: Andy> Hi, Andy> I am trying to configure XORP to advertise routes to a local network Andy> using OSPF. My problem is that only the interface *address* appears Andy> to be advertised, and not the entire network -- in other words, only a Andy> /32 address is inserted into the routing table and not a /24. My Andy> question is, how to get OSPF to advertise and route to the /24? Andy> My OSPF configuration looks like this. Interface 'eth0' is on a /24 Andy> network. I expected that by setting eth0 as 'passive' I could get Andy> OSPF to advertise routes for the attached network, without actually Andy> running OSPF on this interface: Andy> protocols { Andy> ospf4 { Andy> router-id: 128.112.139.96 Andy> area 0.0.0.0 { Andy> interface eth0 { Andy> vif eth0 { Andy> address 10.32.11.2 { Andy> interface-cost: 1 Andy> passive: true Andy> } Andy> } Andy> } Andy> interface eth1 { Andy> vif eth1 { Andy> address 192.168.1.2 { Andy> interface-cost: 1 Andy> } Andy> } Andy> } Andy> interface eth2 { Andy> vif eth2 { Andy> address 192.168.2.2 { Andy> interface-cost: 1 Andy> } Andy> } Andy> } Andy> } Andy> } Andy> } Andy> OSPF appears to be working correctly, and 'eth0' is being Andy> advertised. However, all of the installed routes have masks of Andy> 255.255.255.255: Andy> # route Andy> Kernel IP routing table Andy> Destination Gateway Genmask Flags Metric Ref Andy> Use Iface Andy> 192.168.1.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 Andy> 192.168.2.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 Andy> 10.32.11.2 192.168.2.2 255.255.255.255 UGH 1 0 0 eth2 Andy> [...] Andy> From what I can tell, it looks like this mask is being propagated in Andy> the LSAs themselves: Andy> root@planetlab-3.cs.princeton.edu> show ospf4 database detail Andy> OSPF link state database, Area 0.0.0.0 Andy> Router-LSA: Andy> LS age 283 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Andy> Link State ID 128.112.139.96 Advertising Router 128.112.139.96 LS Andy> sequence number 0x80000002 LS checksum 0x7da7 length 72 Andy> Nt-bit false Andy> V-bit false Andy> E-bit false Andy> B-bit false Andy> Type 3 Stub network Subnet number 10.32.11.2 Mask Andy> 255.255.255.255 Metric 0 Andy> Type 3 Stub network Subnet number 192.168.1.2 Mask Andy> 255.255.255.255 Metric 0 Andy> Type 3 Stub network Subnet number 192.168.2.2 Mask Andy> 255.255.255.255 Metric 0 Andy> Does anyone have insights or suggestions on what I need to do to Andy> advertise a 255.255.255.0 netmask for eth0? Andy> Thanks, Andy> Andy Andy> _______________________________________________ Andy> Xorp-users mailing list Andy> Xorp-users@xorp.org Andy> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From frenwick@cengen.com Tue Apr 11 05:46:14 2006 From: frenwick@cengen.com (Frank E. Renwick) Date: Mon, 10 Apr 2006 21:46:14 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF Message-ID: Hello, I am a new user to XORP and I am attempting to redistribute the system kernel route table into XORP OSPF. I see redistribution support for connected and static routes, but not for the kernel route table, as is available in Quagga. In my case, the system kernel route table is being written by another routing protocol (Optimized Link State Routing) into which XORP has no visibility. The "connected" and "static" features are not sufficient to satisfy my objectives. Any assistance with this matter would be greatly appreciated. Frank Renwick From bms@spc.org Tue Apr 11 17:20:51 2006 From: bms@spc.org (Bruce M Simpson) Date: Tue, 11 Apr 2006 17:20:51 +0100 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: References: Message-ID: <20060411162051.GA54955@spc.org> On Mon, Apr 10, 2006 at 09:46:14PM -0700, Frank E. Renwick wrote: > I am a new user to XORP and I am attempting to redistribute the system > kernel route table into XORP OSPF. I see redistribution support for > connected and static routes, but not for the kernel route table, as is > available in Quagga. In my case, the system kernel route table is being > written by another routing protocol (Optimized Link State Routing) into > which XORP has no visibility. The "connected" and "static" features are not > sufficient to satisfy my objectives. > > Any assistance with this matter would be greatly appreciated. There's an OLSR implementation for XORP somewhere but it would need a bit of cleaning up before it could be integrated with the main line of development. I'd love to see this happen! Regards, BMS From frenwick@cengen.com Tue Apr 11 18:34:05 2006 From: frenwick@cengen.com (Frank E. Renwick) Date: Tue, 11 Apr 2006 10:34:05 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <20060411162051.GA54955@spc.org> Message-ID: Bruce, Thanks for the response. If you have any leads as to where the implementation is, I have a software developer who could likely clean it up. Thanks again, Frank -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Bruce M Simpson Sent: Tuesday, April 11, 2006 9:21 AM To: Frank E. Renwick Cc: xorp-users@xorp.org Subject: Re: [Xorp-users] Redistributing the system kernel route table into OSPF On Mon, Apr 10, 2006 at 09:46:14PM -0700, Frank E. Renwick wrote: > I am a new user to XORP and I am attempting to redistribute the system > kernel route table into XORP OSPF. I see redistribution support for > connected and static routes, but not for the kernel route table, as is > available in Quagga. In my case, the system kernel route table is > being written by another routing protocol (Optimized Link State > Routing) into which XORP has no visibility. The "connected" and > "static" features are not sufficient to satisfy my objectives. > > Any assistance with this matter would be greatly appreciated. There's an OLSR implementation for XORP somewhere but it would need a bit of cleaning up before it could be integrated with the main line of development. I'd love to see this happen! Regards, BMS _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Tue Apr 11 18:35:47 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 11 Apr 2006 10:35:47 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: Message from "Frank E. Renwick" of "Mon, 10 Apr 2006 21:46:14 PDT." Message-ID: <200604111735.k3BHZl6r034075@possum.icir.org> > I am a new user to XORP and I am attempting to redistribute the system > kernel route table into XORP OSPF. I see redistribution support for > connected and static routes, but not for the kernel route table, as is > available in Quagga. In my case, the system kernel route table is being > written by another routing protocol (Optimized Link State Routing) into > which XORP has no visibility. The "connected" and "static" features are not > sufficient to satisfy my objectives. You won't be able to do this out-of-the-box, but there is a semi-hackish way around it. The basic idea is to use the fib2mrib module in XORP. That module typically is used to snoop the unicast routes from the kernel so they can be used for multicast purpose (the Reverse Path Forwarding check in PIM-SM). In your case you will redistribute them to OSPF. 1. Get the latest XORP code from the anonymous CVS, and make sure that file xrl/targets/fib2mrib_base.hh is ref. 1.12 (at least). The instructions for the anonymous CVS access are available from http://www.xorp.org/cvs.html 2. Apply the patch at the end of this email to the checked-out code. Basically, this patch adds the necessary hooks to the etc/templates/policy.tp and etc/templats/fib2mrib.tp so fib2mrib can be used as part of the policy framework. Also, it adds a hack to ospf/xrl_target.cc so OSPF will accept the routes that would come from fib2mrib. If you want to export the fib2mrib routes to some other protocol (BGP or RIP), then you may have to apply a similar hack to the particular protocol. 3. You can export the fib2mrib routes by using the following in your XORP configuration: policy { policy-statement export_fib2mrib { term export { from { protocol: "fib2mrib" } } } } protocols { ospf4 { export: "export_fib2mrib" .... } } protocols { fib2mrib { disable: false } } FYI, I tried the above mechanism, and it appears to work for me, but please let me know if you run into some issues. Pavlin Index: etc/templates/fib2mrib.tp =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/fib2mrib.tp,v retrieving revision 1.10 diff -u -p -r1.10 fib2mrib.tp --- etc/templates/fib2mrib.tp 22 Feb 2006 02:26:10 -0000 1.10 +++ etc/templates/fib2mrib.tp 11 Apr 2006 17:10:58 -0000 @@ -8,11 +8,22 @@ protocols { } } +policy { + policy-statement @: txt { + term @: txt { + from { + metric: u32range; + } + } + } +} + protocols { fib2mrib { %help: short "Configure the FIB2MRIB module"; %modinfo: provides fib2mrib; %modinfo: depends rib; + %modinfo: depends policy; %modinfo: path "fib2mrib/xorp_fib2mrib"; %modinfo: default_targetname "fib2mrib"; %modinfo: status_method xrl "$(fib2mrib.targetname)/common/0.1/get_status->status:u32&reason:txt"; @@ -43,3 +54,21 @@ protocols { } } } + +policy { + %create: xrl "$(policy.targetname)/policy/0.1/set_proto_target?protocol:txt=fib2mrib&target:txt=fib2mrib"; + %create: xrl "$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&variable:txt=network4&type:txt=ipv4net&access:txt=r&id:u32=10"; + %create: xrl "$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&variable:txt=metric&type:txt=u32&access:txt=rw&id:u32=14"; + + policy-statement @: txt { + term @: txt { + from { + metric { + %help: short "Set the metric value"; + %set: xrl "$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-statement.@)&term:txt=$(term.@)&block:u32=0&order:txt=$(#)&statement:txt=metric $(<>) $(@);"; + %delete: xrl "$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-statement.@)&term:txt=$(term.@)&block:u32=0&order:txt=$(#)&statement:txt="; + } + } + } + } +} Index: etc/templates/policy.tp =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/policy.tp,v retrieving revision 1.20 diff -u -p -r1.20 policy.tp --- etc/templates/policy.tp 3 Apr 2006 23:35:14 -0000 1.20 +++ etc/templates/policy.tp 11 Apr 2006 17:10:58 -0000 @@ -73,6 +73,7 @@ policy { %help: short "Protocol from which route was learned"; %allow: $(@) "bgp" %help: "BGP routes"; %allow: $(@) "connected" %help: "Directly connected sub-network routes"; + %allow: $(@) "fib2mrib" %help: "FIB2MRIB routes"; %allow: $(@) "ospf4" %help: "OSPF IPv4 routes"; %allow: $(@) "rip" %help: "RIP routes"; %allow: $(@) "ripng" %help: "RIPng routes"; Index: ospf/xrl_target.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/ospf/xrl_target.cc,v retrieving revision 1.36 diff -u -p -r1.36 xrl_target.cc --- ospf/xrl_target.cc 28 Mar 2006 03:06:55 -0000 1.36 +++ ospf/xrl_target.cc 11 Apr 2006 17:10:59 -0000 @@ -278,8 +278,10 @@ XrlOspfV2Target::policy_redist4_0_1_add_ cstring(network), cstring(nexthop), pb(unicast), pb(multicast), metric); +#if 0 if (!unicast) return XrlCmdError::OKAY(); +#endif if (!_ospf.originate_route(network, nexthop, metric, policytags)) { return XrlCmdError::COMMAND_FAILED("Network: " + network.str()); @@ -296,8 +298,10 @@ XrlOspfV2Target::policy_redist4_0_1_dele debug_msg("Net: %s Unicast: %s Multicast %s\n", cstring(network), pb(unicast), pb(multicast)); +#if 0 if (!unicast) return XrlCmdError::OKAY(); +#endif if (!_ospf.withdraw_route(network)) { return XrlCmdError::COMMAND_FAILED("Network: " + network.str()); From kristian@juniks.net Wed Apr 12 06:55:52 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 12 Apr 2006 07:55:52 +0200 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: References: <20060411162051.GA54955@spc.org> Message-ID: <20060412055552.GD8323@juniks.net> On Tue, Apr 11, 2006 at 10:34:05AM -0700, Frank E. Renwick wrote: > Bruce, > > Thanks for the response. If you have any leads as to where the > implementation is, I have a software developer who could likely clean it up. I did some google research ("OLSR XORP") and came up with... http://kunz-pc.sce.carleton.ca/Thesis/OLSRXORP.tar.gz There seems to be several people working on it OLSR for XORP. Perhaps it's possible to join forces and make something great out of this. Always exciting with new functionality in XORP :) Kristian. > -----Original Message----- > From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf > Of Bruce M Simpson > Sent: Tuesday, April 11, 2006 9:21 AM > To: Frank E. Renwick > Cc: xorp-users@xorp.org > Subject: Re: [Xorp-users] Redistributing the system kernel route table into > OSPF > > On Mon, Apr 10, 2006 at 09:46:14PM -0700, Frank E. Renwick wrote: > > I am a new user to XORP and I am attempting to redistribute the system > > kernel route table into XORP OSPF. I see redistribution support for > > connected and static routes, but not for the kernel route table, as is > > available in Quagga. In my case, the system kernel route table is > > being written by another routing protocol (Optimized Link State > > Routing) into which XORP has no visibility. The "connected" and > > "static" features are not sufficient to satisfy my objectives. > > > > Any assistance with this matter would be greatly appreciated. > > There's an OLSR implementation for XORP somewhere but it would need a bit of > cleaning up before it could be integrated with the main line of development. > I'd love to see this happen! > > Regards, > BMS > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms@spc.org Wed Apr 12 09:19:23 2006 From: bms@spc.org (Bruce M Simpson) Date: Wed, 12 Apr 2006 09:19:23 +0100 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: References: <20060411162051.GA54955@spc.org> Message-ID: <20060412081923.GE80492@spc.org> On Tue, Apr 11, 2006 at 10:34:05AM -0700, Frank E. Renwick wrote: > Thanks for the response. If you have any leads as to where the > implementation is, I have a software developer who could likely clean it up. It's here: http://www.sce.carleton.ca/wmc/code.html OLSR in XORP would be interesting as an experiment in getting the new decentralized MANET protocols (OLSR, AODV, DSR etc) to talk to the old centralized hierarchical protocols (OSPF, BGP, IS-IS). Although doing layer 3 routing to build large wireless LANs is still a silly idea for various reasons you are no doubt aware of, that doesn't stop people from trying! For exchanging routes via the RIB between centralized and decentralized protocols, an event-driven trigger will be required. Most of XORP is event and table driven. Many of the MANET protocols are table driven, and some are purely on-demand such as AODV. Currently the XORP framework implements BGP, OSPF and RIP which as you probably know are timer and event driven, and all are table driven. There are basic hooks in the FEA and RIB for dealing with the notifications generated by the forwarding layer when routes are missing when running in an on-demand environment, but only tested on FreeBSD. Linux doesn't have this capability in its FIB interface which is why the in-kernel AODV implementation available for it... is in-kernel. Now that the policy engine has been implemented by Andrea, the right bits in the framework are there, it's just a case of someone having time to sit down and put them all together. BMS From frenwick@cengen.com Sat Apr 15 01:05:27 2006 From: frenwick@cengen.com (Frank E. Renwick) Date: Fri, 14 Apr 2006 17:05:27 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <200604111735.k3BHZl6r034075@possum.icir.org> Message-ID: Pavlin, I have a couple of questions about the patch: 1) Should this work in a Windows 2003 build of XORP, or is the functionality of fib2mrib tied to multicast support, and in turn presents a problem? 2) In the patch you sent me, there are three lines that I believe should be made into one line: + %create: xrl +"$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&varia +ble:txt=metric&type:txt=u32&access:txt=rw&id:u32=14"; I want to make sure it is accepatble to concatenate these three entries in a single line. Thanks, frank -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Pavlin Radoslavov Sent: Tuesday, April 11, 2006 10:36 AM To: Frank E. Renwick Cc: xorp-users@xorp.org Subject: Re: [Xorp-users] Redistributing the system kernel route table into OSPF > I am a new user to XORP and I am attempting to redistribute the system > kernel route table into XORP OSPF. I see redistribution support for > connected and static routes, but not for the kernel route table, as is > available in Quagga. In my case, the system kernel route table is > being written by another routing protocol (Optimized Link State > Routing) into which XORP has no visibility. The "connected" and > "static" features are not sufficient to satisfy my objectives. You won't be able to do this out-of-the-box, but there is a semi-hackish way around it. The basic idea is to use the fib2mrib module in XORP. That module typically is used to snoop the unicast routes from the kernel so they can be used for multicast purpose (the Reverse Path Forwarding check in PIM-SM). In your case you will redistribute them to OSPF. 1. Get the latest XORP code from the anonymous CVS, and make sure that file xrl/targets/fib2mrib_base.hh is ref. 1.12 (at least). The instructions for the anonymous CVS access are available from http://www.xorp.org/cvs.html 2. Apply the patch at the end of this email to the checked-out code. Basically, this patch adds the necessary hooks to the etc/templates/policy.tp and etc/templats/fib2mrib.tp so fib2mrib can be used as part of the policy framework. Also, it adds a hack to ospf/xrl_target.cc so OSPF will accept the routes that would come from fib2mrib. If you want to export the fib2mrib routes to some other protocol (BGP or RIP), then you may have to apply a similar hack to the particular protocol. 3. You can export the fib2mrib routes by using the following in your XORP configuration: policy { policy-statement export_fib2mrib { term export { from { protocol: "fib2mrib" } } } } protocols { ospf4 { export: "export_fib2mrib" .... } } protocols { fib2mrib { disable: false } } FYI, I tried the above mechanism, and it appears to work for me, but please let me know if you run into some issues. Pavlin Index: etc/templates/fib2mrib.tp =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/fib2mrib.tp,v retrieving revision 1.10 diff -u -p -r1.10 fib2mrib.tp --- etc/templates/fib2mrib.tp 22 Feb 2006 02:26:10 -0000 1.10 +++ etc/templates/fib2mrib.tp 11 Apr 2006 17:10:58 -0000 @@ -8,11 +8,22 @@ protocols { } } +policy { + policy-statement @: txt { + term @: txt { + from { + metric: u32range; + } + } + } +} + protocols { fib2mrib { %help: short "Configure the FIB2MRIB module"; %modinfo: provides fib2mrib; %modinfo: depends rib; + %modinfo: depends policy; %modinfo: path "fib2mrib/xorp_fib2mrib"; %modinfo: default_targetname "fib2mrib"; %modinfo: status_method xrl "$(fib2mrib.targetname)/common/0.1/get_status->status:u32&reason:txt"; @@ -43,3 +54,21 @@ protocols { } } } + +policy { + %create: xrl "$(policy.targetname)/policy/0.1/set_proto_target?protocol:txt=fib2mrib&targ et:txt=fib2mrib"; + %create: xrl "$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&variable:t xt=network4&type:txt=ipv4net&access:txt=r&id:u32=10"; + %create: xrl +"$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&varia +ble:txt=metric&type:txt=u32&access:txt=rw&id:u32=14"; + + policy-statement @: txt { + term @: txt { + from { + metric { + %help: short "Set the metric value"; + %set: xrl "$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-state ment.@)&term:txt=$(term.@)&block:u32=0&order:txt=$(#)&statement:txt=metric $(<>) $(@);"; + %delete: xrl "$(policy.targetname)/policy/0.1/update_term_block?policy:txt=$(policy-state ment.@)&term:txt=$(term.@)&block:u32=0&order:txt=$(#)&statement:txt="; + } + } + } + } +} Index: etc/templates/policy.tp =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/etc/templates/policy.tp,v retrieving revision 1.20 diff -u -p -r1.20 policy.tp --- etc/templates/policy.tp 3 Apr 2006 23:35:14 -0000 1.20 +++ etc/templates/policy.tp 11 Apr 2006 17:10:58 -0000 @@ -73,6 +73,7 @@ policy { %help: short "Protocol from which route was learned"; %allow: $(@) "bgp" %help: "BGP routes"; %allow: $(@) "connected" %help: "Directly connected sub-network routes"; + %allow: $(@) "fib2mrib" %help: "FIB2MRIB routes"; %allow: $(@) "ospf4" %help: "OSPF IPv4 routes"; %allow: $(@) "rip" %help: "RIP routes"; %allow: $(@) "ripng" %help: "RIPng routes"; Index: ospf/xrl_target.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/ospf/xrl_target.cc,v retrieving revision 1.36 diff -u -p -r1.36 xrl_target.cc --- ospf/xrl_target.cc 28 Mar 2006 03:06:55 -0000 1.36 +++ ospf/xrl_target.cc 11 Apr 2006 17:10:59 -0000 @@ -278,8 +278,10 @@ XrlOspfV2Target::policy_redist4_0_1_add_ cstring(network), cstring(nexthop), pb(unicast), pb(multicast), metric); +#if 0 if (!unicast) return XrlCmdError::OKAY(); +#endif if (!_ospf.originate_route(network, nexthop, metric, policytags)) { return XrlCmdError::COMMAND_FAILED("Network: " + network.str()); @@ -296,8 +298,10 @@ XrlOspfV2Target::policy_redist4_0_1_dele debug_msg("Net: %s Unicast: %s Multicast %s\n", cstring(network), pb(unicast), pb(multicast)); +#if 0 if (!unicast) return XrlCmdError::OKAY(); +#endif if (!_ospf.withdraw_route(network)) { return XrlCmdError::COMMAND_FAILED("Network: " + network.str()); _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Sat Apr 15 01:15:26 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 14 Apr 2006 17:15:26 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: Message from "Frank E. Renwick" of "Fri, 14 Apr 2006 17:05:27 PDT." Message-ID: <200604150015.k3F0FQe8087416@possum.icir.org> > 1) Should this work in a Windows 2003 build of XORP, or is the functionality > of fib2mrib tied to multicast support, and in turn presents a problem? It won't work on Windows, but for a different reason. The fib2mrib mechanism is tied to the ability of the FEA to observe third-party changes to the unicast forwarding table in the kernel. Currently, the FEA doesn't support this for Windows. I am not even sure whether the Windows API supports asynchronous notifications to userland if the forwarding table is modified; Bruce M. Simpson would be the right person to answer that question. > 2) In the patch you sent me, there are three lines that I believe should be > made into one line: > > + %create: xrl > +"$(policy.targetname)/policy/0.1/add_varmap?protocol:txt=fib2mrib&varia > +ble:txt=metric&type:txt=u32&access:txt=rw&id:u32=14"; > > I want to make sure it is accepatble to concatenate these three entries in a > single line. Yes, they should be a single line. Probaby it got corrupted in the email. Pavlin From bms@spc.org Sat Apr 15 01:30:40 2006 From: bms@spc.org (Bruce M Simpson) Date: Sat, 15 Apr 2006 01:30:40 +0100 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <200604150015.k3F0FQe8087416@possum.icir.org> References: <200604150015.k3F0FQe8087416@possum.icir.org> Message-ID: <20060415003040.GH94628@spc.org> On Fri, Apr 14, 2006 at 05:15:26PM -0700, Pavlin Radoslavov wrote: > It won't work on Windows, but for a different reason. > The fib2mrib mechanism is tied to the ability of the FEA to observe > third-party changes to the unicast forwarding table in the kernel. fib2mrib isn't terribly useful without multicast routing protocols and vice versa. It will compile on Windows but isn't useful [yet]. > Currently, the FEA doesn't support this for Windows. I am not even > sure whether the Windows API supports asynchronous notifications to > userland if the forwarding table is modified; Bruce M. Simpson would > be the right person to answer that question. 'Sort of'. It depends whether one registers for changes via the IP Helper calls (using an Event object) or via RTMv2 messages. XORP currently does neither because Microsoft's internal APIs are still in a state of change. BMS From bms@spc.org Sat Apr 15 11:16:29 2006 From: bms@spc.org (Bruce M Simpson) Date: Sat, 15 Apr 2006 11:16:29 +0100 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <20060415003040.GH94628@spc.org> References: <200604150015.k3F0FQe8087416@possum.icir.org> <20060415003040.GH94628@spc.org> Message-ID: <20060415101629.GA28496@spc.org> On Sat, Apr 15, 2006 at 01:30:40AM +0100, Bruce M Simpson wrote: > > Currently, the FEA doesn't support this for Windows. I am not even > > sure whether the Windows API supports asynchronous notifications to > > userland if the forwarding table is modified; Bruce M. Simpson would > > be the right person to answer that question. > XORP currently does neither because Microsoft's internal APIs are still in > a state of change. The problem with the original approach (run olsr outside of XORP) is that it relies on the routing protocol(s) being able to co-exist within the kernel forwarding table -- it isn't quite the same as trying to use the kernel FIB as a RIB. The best way to make headway with your original application would be to get the OLSR implementation for XORP cleaned up and integrated into the tree. This would mean that OLSR itself wouldn't need to know how to talk to the kernel forwarding table, and the XORP RIB can be used for supplying the kernel with the correct paths, making things platform independent. It also means being able to use the XORP configuration interface for OLSR, and not having to worry about system specific means of implementing timers, etc, as well as the rest of XORP being aware of OLSR. Then as the base support for various OSes improves, functionality such as on-demand path lookup can be added; the FreeBSD FIB supports this with no kernel modifications; the Linux in-kernel AODV implementation modifies the kernel in order to obtain such notifications. Regards, BMS From frenwick@cengen.com Sat Apr 15 16:31:11 2006 From: frenwick@cengen.com (Frank E. Renwick) Date: Sat, 15 Apr 2006 08:31:11 -0700 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <20060415101629.GA28496@spc.org> Message-ID: <8BF473128B5E4FD1829412EE8A3DFD5F.MAI@cengen.com> Bruce, I wholeheartedly agree with your assessment that the optimized approach when redistributing between routing protocols (such as OLSR and OSPF) includes instantiating both under a common routing daemon, like XORP or Quagga. However, there is much that can be done if one only has the capability of interchanging information using the kernel as a "middle man." For example, in Windows, I currently use OLSR coupled with OSPF from RRAS. By defining an ASBR, the Windows box is able to create Type 5 LSAs (albeit only External Type 2) from entries in the kernel route table. (I was attracted to XORP OSPF because it appears to be able to inject External Type 1 LSAs, which are much preferred.) As a network engineer who is not a software developer, I was after the "low hanging fruit." I was under the assumption that XORP routing protocols (OSPF,BGP, etc.) would be able to interchange with the kernel route table, without worrying about where the kernel entries originated. I also assumed that this mechanism would be easier to implement than a full route redistribution between two routing protocols, one of which is not currently part of XORP. As it turns out, with the version of OLSR I am using, if I had the ability to redistribute kernel routes into OSPF, I would be able to provide full bi-directional route redistribution between an OLSR domain and an OSPF domain. Assuming that XORP offers External Type 1 redistribution, I would be able to include multiple redistribution points in the network without fear of routing loops, by "sharing" the metric across the redistribution boundary. All this said, I do not expect that XORP should develop a capability just to meet my needs. I appreciate the discussion, and I will meet with my team to discuss the option of participating in the development of OLSR as a XORP routing protocol. Frank -----Original Message----- From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf Of Bruce M Simpson Sent: Saturday, April 15, 2006 3:16 AM To: Pavlin Radoslavov Cc: Frank E. Renwick; xorp-users@xorp.org Subject: Re: [Xorp-users] Redistributing the system kernel route table into OSPF On Sat, Apr 15, 2006 at 01:30:40AM +0100, Bruce M Simpson wrote: > > Currently, the FEA doesn't support this for Windows. I am not even > > sure whether the Windows API supports asynchronous notifications to > > userland if the forwarding table is modified; Bruce M. Simpson would > > be the right person to answer that question. > XORP currently does neither because Microsoft's internal APIs are > still in a state of change. The problem with the original approach (run olsr outside of XORP) is that it relies on the routing protocol(s) being able to co-exist within the kernel forwarding table -- it isn't quite the same as trying to use the kernel FIB as a RIB. The best way to make headway with your original application would be to get the OLSR implementation for XORP cleaned up and integrated into the tree. This would mean that OLSR itself wouldn't need to know how to talk to the kernel forwarding table, and the XORP RIB can be used for supplying the kernel with the correct paths, making things platform independent. It also means being able to use the XORP configuration interface for OLSR, and not having to worry about system specific means of implementing timers, etc, as well as the rest of XORP being aware of OLSR. Then as the base support for various OSes improves, functionality such as on-demand path lookup can be added; the FreeBSD FIB supports this with no kernel modifications; the Linux in-kernel AODV implementation modifies the kernel in order to obtain such notifications. Regards, BMS _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms@spc.org Sat Apr 15 22:14:16 2006 From: bms@spc.org (Bruce M Simpson) Date: Sat, 15 Apr 2006 22:14:16 +0100 Subject: [Xorp-users] Redistributing the system kernel route table into OSPF In-Reply-To: <8BF473128B5E4FD1829412EE8A3DFD5F.MAI@cengen.com> References: <20060415101629.GA28496@spc.org> <8BF473128B5E4FD1829412EE8A3DFD5F.MAI@cengen.com> Message-ID: <20060415211416.GD94630@spc.org> Hello there, A few more thoughts spring to mind. On Sat, Apr 15, 2006 at 08:31:11AM -0700, Frank E. Renwick wrote: > All this said, I do not expect that XORP should develop a capability just to > meet my needs. I appreciate the discussion, and I will meet with my team to > discuss the option of participating in the development of OLSR as a XORP > routing protocol. This would indeed be the ideal solution. You can still run XORP and OLSR independently at the same time; XORP itself just won't see the updates in Windows' routing table. Three points. 1. Seeing updates would require the use of and integration of the IP Helper functions NotifyAddrChange() and NotifyRouteChange(). These functions are known to use Win32 Event objects to signal completion. The XORP event loop code on Windows is an interesting synthesis because it attempts to manage Win32 objects which signal completion via WFMO in a single thread. They only tell you that *something* in the Windows interface stack or the IPv4 forwarding table changed. They don't tell you what. So an entire rescan would be needed. 2. Protocols which use IP Helper for route management are tricky because we can't differentiate their routes from XORP's; as per the documentation for CreateIpForwardEntry(), any MIB_IPFORWARDROW structures passed must have the owning protocol set to PROTO_IP_NETMGMT. There's a minor risk of update collisions. Until XORP manages to grow support for RRAS, there's no real way of differentiating forwarding entries managed by one protocol versus another, so there is a danger of update collisions. You or your team may be aware that the Win32 APIs involved will fill out the metric with the interface metric as a default if it isn't specified, providing a crude form of administrative distance. We recently committed some fixes for dealing with the situation where multiple routing protocols in XORP manage routes to the same destination; when using IP Helper (which in turn indirectly uses MPR) it's necessary to fill out the MIB_IPFORWARDROW structure *fully* to add/delete the entry correctly. The RIB and FEA still assume a single next-hop for a single prefix as is the case in most PATRICIA trie based RIBs such as 4.4BSD (see Keith Sklower's original paper) -- there is no multipath support... yet! 3. Currently XORP detects if RRAS is running and will print a warning if so, as the IP Helper route management APIs may behave inconsistently. The purpose of this is to enable us to grow support for RRAS eventually. As you can probably infer from the above commentary, IP Helper isn't an ideal API for a routing daemon on Windows, nor was it intended to be -- but in the absence of better hints / documentation, it's what everyone in open source land has ended up using; I haven't seen any open source RRAS examples other than what Microsoft started shipping in their SDK. Patches for any of the above gratefully accepted! HTH, BMS From Chris.Robson@nrl.navy.mil Tue Apr 18 15:59:13 2006 From: Chris.Robson@nrl.navy.mil (Chris Robson NRL) Date: Tue, 18 Apr 2006 10:59:13 -0400 Subject: [Xorp-users] IPv6 Multicast ? Message-ID: <6.2.1.2.2.20060418103744.02221ea0@ginger.cmf.nrl.navy.mil> On a stock Fedora Core 5 linux-2.6.16-1.2080 distro with MRD6 running do you still need to install Hoerdt's IPv6 multicast patches? Otherwise why is the following error occurring: [ 2006/04/18 10:52:34 ERROR xorp_fea:2912 MFEA +986 mfea_mrouter.cc add_multicast_vif ] add_multicast_vif() failed: IPv6 multicast routing not supported [ 2006/04/18 10:52:34 ERROR xorp_fea:2912 MFEA +908 mfea_node.cc start_vif ] Cannot start vif eth1: cannot add the multicast vif to the kernel Part of the config.boot file below: mfea6 { disable: false interface eth0 { vif eth0 { disable: true } } interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { disable: false } } interface eth3 { vif eth3 { disable: true } } interface register_vif { vif register_vif { disable: false } } traceoptions { thanks Christopher L. Robson GS-1550-NP-IV (V/C) 202-404-3138 EMAIL: Chris.Robson@nrl.navy.mil GIG-EF SIP: Chris.Robson@nrl.gigef.net DoN, NRL, Code 5590 4555 Overlook Ave Washington, D.C. 20375 From pavlin@icir.org Tue Apr 18 20:04:54 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 18 Apr 2006 12:04:54 -0700 Subject: [Xorp-users] IPv6 Multicast ? In-Reply-To: Message from Chris Robson NRL of "Tue, 18 Apr 2006 10:59:13 EDT." <6.2.1.2.2.20060418103744.02221ea0@ginger.cmf.nrl.navy.mil> Message-ID: <200604181904.k3IJ4ssX058715@possum.icir.org> > On a stock Fedora Core 5 linux-2.6.16-1.2080 distro with MRD6 running do > you still need to install Hoerdt's IPv6 multicast patches? Otherwise why > is the following error occurring: Yes, in case of XORP yu must have Hoerdt's IPv6 multicast patches in your kernel. They are already in the USAGI tree so you may want to install one of their recent snapshots. I believe in case of MRD6 the multicast forwarding is performed in user-space hence it doesn't need the IPv6 multicast patches. Pavlin > [ 2006/04/18 10:52:34 ERROR xorp_fea:2912 MFEA +986 mfea_mrouter.cc > add_multicast_vif ] add_multicast_vif() failed: IPv6 multicast routing not > supported > [ 2006/04/18 10:52:34 ERROR xorp_fea:2912 MFEA +908 mfea_node.cc start_vif > ] Cannot start vif eth1: cannot add the multicast vif to the kernel > > > > Part of the config.boot file below: > > mfea6 { > disable: false > interface eth0 { > vif eth0 { > disable: true > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > > interface eth2 { > vif eth2 { > disable: false > } > } > interface eth3 { > vif eth3 { > disable: true > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > traceoptions { > > thanks > > Christopher L. Robson > GS-1550-NP-IV > (V/C) 202-404-3138 > EMAIL: Chris.Robson@nrl.navy.mil > GIG-EF SIP: Chris.Robson@nrl.gigef.net > DoN, NRL, Code 5590 > 4555 Overlook Ave > Washington, D.C. 20375 > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Thu Apr 20 09:22:44 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 20 Apr 2006 01:22:44 -0700 Subject: [Xorp-users] HEADS UP: "create" and "set" configuration commands are merged Message-ID: <200604200822.k3K8Miwr047396@possum.icir.org> Due to popular demand, the "create" and "set" configuration commands are merged, so now the new "set" command can be used for setting values and for creating new configuration nodes. (Strictly speaking, the new "set" command is actually the old "create" command which was already capable of setting values and creating new configuration nodes). For backward compatibility, the obsoleted "create" command is preserved as an alias for the new "set" command, though it may be removed in the future. This change is in XORP-current and will be in the forthcoming XORP-1.3 release. For details about the decision to merge those commands see the xorp-hackers email exchange with Subject: "BG 172": http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2006-March/thread.html and Bugzilla entry #172: http://www.xorp.org/bugzilla/show_bug.cgi?id=172 Please let me know if you find any issues because of this change. Pavlin From dave@vyatta.com Thu Apr 20 17:10:36 2006 From: dave@vyatta.com (Dave Roberts) Date: Thu, 20 Apr 2006 09:10:36 -0700 Subject: [Xorp-users] HEADS UP: "create" and "set" configuration commands are merged In-Reply-To: <200604200822.k3K8Miwr047396@possum.icir.org> References: <200604200822.k3K8Miwr047396@possum.icir.org> Message-ID: <4447B27C.1030100@vyatta.com> And a great cheer went up in all the land, and there was feasting and revelry... ;-) -- Dave Pavlin Radoslavov wrote: > Due to popular demand, the "create" and "set" configuration > commands are merged, so now the new "set" command can be used for > setting values and for creating new configuration nodes. > > (Strictly speaking, the new "set" command is actually the old > "create" command which was already capable of setting values and > creating new configuration nodes). > > For backward compatibility, the obsoleted "create" command is > preserved as an alias for the new "set" command, though it may be > removed in the future. > > > This change is in XORP-current and will be in the forthcoming > XORP-1.3 release. > > For details about the decision to merge those commands see > the xorp-hackers email exchange with Subject: "BG 172": > http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2006-March/thread.html > > and Bugzilla entry #172: > http://www.xorp.org/bugzilla/show_bug.cgi?id=172 > > Please let me know if you find any issues because of this change. > > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From orante2003@yahoo.it Wed Apr 26 13:17:46 2006 From: orante2003@yahoo.it (ORANTE TUCCERI) Date: Wed, 26 Apr 2006 14:17:46 +0200 (CEST) Subject: [Xorp-users] Informations requested Message-ID: <20060426121746.37550.qmail@web26809.mail.ukl.yahoo.com> --0-1978622269-1146053866=:35676 Content-Type: text/plain; charset=iso-8859-1 Which the timers of OSPF? they are configurables from customer? how? which the OSPF door (in order to create socket)? thanks --------------------------------- Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-1978622269-1146053866=:35676 Content-Type: text/html; charset=iso-8859-1 
Which the timers of OSPF?  they are configurables from
customer? how?

which the OSPF door (in order to create socket)?

thanks
 
 <orante2003@yahoo.it>






Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-1978622269-1146053866=:35676-- From mhorn@vyatta.com Wed Apr 26 17:18:55 2006 From: mhorn@vyatta.com (Mike Horn) Date: Wed, 26 Apr 2006 09:18:55 -0700 (PDT) Subject: [Xorp-users] Informations requested Message-ID: <19549363.151146068335671.JavaMail.root@mail.vyatta.com> Hi Orante, Here are some of the more common OSPF timers along with the commands to configure them (I used the backbone area - 0.0.0.0 for these examples, but you can configure these for any area). hello interval - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 hello-interval 30 dead interval - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 router-dead-interval 120 retransmit interval - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 retransmit-interval 10 I'm not sure I understand your question about the OSPF door, can you explain what you are looking for? -mike ----- Original Message ----- From: ORANTE TUCCERI To: xorp-users@xorp.org Sent: Wednesday, April 26, 2006 6:17:46 AM GMT-0700 Subject: [Xorp-users] Informations requested Which the timers of OSPF? they are configurables from customer? how? which the OSPF door (in order to create socket)? thanks < orante2003@yahoo.it > Yahoo! Mail : gratis 1GB per i messaggi, antispam, antivirus, POP3 From kristian@juniks.net Wed Apr 26 18:18:32 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 26 Apr 2006 19:18:32 +0200 Subject: [Xorp-users] Informations requested In-Reply-To: <19549363.151146068335671.JavaMail.root@mail.vyatta.com> References: <19549363.151146068335671.JavaMail.root@mail.vyatta.com> Message-ID: <20060426171831.GA23160@juniks.net> On Wed, Apr 26, 2006 at 09:18:55AM -0700, Mike Horn wrote: > Hi Orante, > > Here are some of the more common OSPF timers along with the commands to configure them (I used the backbone area - 0.0.0.0 for these examples, but you can configure these for any area). > These look all right, but I would advice against using 'create' since it is deprecated. 'set' is it's replacement, just like on JunOS :) > hello interval > - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 hello-interval 30 > > dead interval > - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 router-dead-interval 120 > > retransmit interval > - create protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.0.1 retransmit-interval 10 > > I'm not sure I understand your question about the OSPF door, can you explain what you are looking for? > > -mike > > > ----- Original Message ----- > From: ORANTE TUCCERI > To: xorp-users@xorp.org > Sent: Wednesday, April 26, 2006 6:17:46 AM GMT-0700 > Subject: [Xorp-users] Informations requested > > Which the timers of OSPF? they are configurables from > customer? how? > > which the OSPF door (in order to create socket)? > > thanks > > < orante2003@yahoo.it > > > > > > > > > > > Yahoo! Mail : gratis 1GB per i messaggi, antispam, antivirus, POP3 > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pvillanu@site.uottawa.ca Wed Apr 26 21:52:14 2006 From: pvillanu@site.uottawa.ca (pvillanu@site.uottawa.ca) Date: Wed, 26 Apr 2006 16:52:14 -0400 (EDT) Subject: [Xorp-users] Implementing on-demand ad hoc routing protocols using XORP... Message-ID: <1051.127.0.0.1.1146084734.squirrel@127.0.0.1> Hello, I want to use some of the XORP processes (FEA and probably RIB as well) for implementing ad hoc routing protocols such as DSR (Dynamic Source Routing). My reason to use the FEA is to make my implementation portable. So, I want to explain my approach and ask for your feedback about its feasibility. My plan is to implement the ad hoc routing protocols using C/C++ and then make use of the FEA classes 1)To forward Table management, 2) To send and receive raw packets and, 3) To send and receive TCP/UDP packets. So far is it OK?, I mean, is it possible to make use of the FEA classes, from any other C/C++ program, without making use of any other process that is part of the XORP architecture? My second question is that for on-demand ad-hoc routing protocols such as DSR, when a data packet is going to be sent by the source node (presumably in a multi-hop fashion) it might be the case that there is no path to the destination node, in such a case, the Route Discovery component of the routing protocol has to be initiated, and after hopefully obtaining a path towards the destination (or the next-hop at least), the data packet can be sent. However, my concern is that when the data packet is going to be sent and the forwarding engine does not find a next-hop for the destination in the forwarding table it won't send the packet. What I need is to be able to initiate the route discovery before the data packet reaches the forwarding engine (just in the case there is no known route), and once the route has been discovered the packet can proceed to the forwarding engine. Is that possible? Is there something in the FEA that would allow me to do that while the implementation is still portable? If not, any suggestion? Thanks a lot and sorry for the long posting... Pedro Villanueva PhD student Ottawa University From pavlin@icir.org Thu Apr 27 06:30:07 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 26 Apr 2006 22:30:07 -0700 Subject: [Xorp-users] HEADS UP: Mailman upgrade this Saturday (April 29th) Message-ID: <200604270530.k3R5U7IH065668@possum.icir.org> All, This Saturday (April 29th) the ICSI administrators are going to upgrade the Mailman software on the server that manages all XORP mailing lists. Please don't send any emails during the update to any of the XORP MLs. Also, please postpone any subscription related changes (preferences, unsubscribe requests, etc) until the upgrade is completed. I will send another email after everything is back to normal. There is chance that right after the upgrade some of the Mailman configuration options may be reset. This may result in some unwanted spam. If this happens we should fix the problem promptly. In the mean time please have some patience. Thank you, Pavlin From pavlin@icir.org Thu Apr 27 18:20:04 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 27 Apr 2006 10:20:04 -0700 Subject: [Xorp-users] Implementing on-demand ad hoc routing protocols using XORP... In-Reply-To: Message from pvillanu@site.uottawa.ca of "Wed, 26 Apr 2006 16:52:14 EDT." <1051.127.0.0.1.1146084734.squirrel@127.0.0.1> Message-ID: <200604271720.k3RHK4H4071597@possum.icir.org> > I want to use some of the XORP processes (FEA and probably RIB as well) > for implementing ad hoc routing protocols such as DSR (Dynamic Source > Routing). My reason to use the FEA is to make my implementation portable. > So, I want to explain my approach and ask for your feedback about its > feasibility. > > My plan is to implement the ad hoc routing protocols using C/C++ and then > make use of the FEA classes 1)To forward Table management, 2) To send and > receive raw packets and, 3) To send and receive TCP/UDP packets. So far is > it OK?, I mean, is it possible to make use of the FEA classes, from any > other C/C++ program, without making use of any other process that is part > of the XORP architecture? I presume you just want to link your code with (some of) the FEA code rather than running your protocol within the XORP framework? Yes, it should be possible (and yes, you won't need the rest of the XORP processes), but you should be aware of the following: * All operations for manipulating the network interfaces are transaction-based, so you need to make sure that you call start_transaction/commit_transaction back-end code inside the FEA. * The operations for manipulating the forwarding table are also transaction-based, so here again you need to call the appropriate start_transaction/commit_transaction back-end code inside the FEA. * The FEA classes haven't been designed to be used in complete isolation. E.g., the classes for sending/receiving raw packets need to have access to the network interface information managed by the interface-related classes. Hence, you have to be careful if you choose to pick-up only some of the FEA classes. * The FEA code needs to be linked with a number of libraries (see the xorp_fea_LDADD files inside fea/Makefile.am) so you may need to do lots of trimming if you don't want to depend on those libraries as well. * If the FEA internals are modified in the future, quite likely you won't be able to link with the newer versions without modifying/refactoring your implementation. In other words, depends on the particular solution you choose, you may have to go through lots of hassle to isolate only the pieces you need. FYI, eventually in the future we will have a single top-level FEA class (with an uniform API) that collects all the smaller pieces, but for the time being this is a low priority task. Rather than trying to do such low-level linking/reusing of the FEA code, I'd recommend to implement your protocol with the XORP framework in mind. E.g., have a top-layer communication API that eventually will use XRLs to interact with the FEA and RIB. Then, you could always reuse your core implementation in some other way. > My second question is that for on-demand ad-hoc routing protocols such as > DSR, when a data packet is going to be sent by the source node (presumably > in a multi-hop fashion) it might be the case that there is no path to the > destination node, in such a case, the Route Discovery component of the > routing protocol has to be initiated, and after hopefully obtaining a path > towards the destination (or the next-hop at least), the data packet can be > sent. However, my concern is that when the data packet is going to be sent > and the forwarding engine does not find a next-hop for the destination in > the forwarding table it won't send the packet. What I need is to be able > to initiate the route discovery before the data packet reaches the > forwarding engine (just in the case there is no known route), and once the > route has been discovered the packet can proceed to the forwarding engine. > Is that possible? Is there something in the FEA that would allow me to do > that while the implementation is still portable? If not, any suggestion? Are the data packets forwarded in userland or only by the kernel? If the former, then your protocol should queue them until the path is discovered. If the data packets are forwarded only by the kernel, the traditional UNIX forwarding path doesn't provide the mechanism to queue the packets until the path is resolved. Though, it may be worth doing some search if there are any kernel extentions/modules that provide that functionality. Otherwise, you may try to implement this feature in Click and then use the Click forwarding path (either in user or kernel mode) to queue/forward the packets and interact with your protocol. Hope that helps, Pavlin From pavlin at icir.org Sat Apr 29 18:13:32 2006 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 29 Apr 2006 18:13:32 -0700 Subject: [Xorp-users] [Xorp-hackers] HEADS UP: Mailman upgrade this Saturday (April 29th) In-Reply-To: Message from Pavlin Radoslavov of "Wed, 26 Apr 2006 22:30:07 PDT." <200604270530.k3R5U7IH065668@possum.icir.org> Message-ID: <200604300113.k3U1DW9L058475@possum.icir.org> > All, > > This Saturday (April 29th) the ICSI administrators are going to > upgrade the Mailman software on the server that manages all XORP > mailing lists. > > Please don't send any emails during the update to any of the XORP > MLs. Also, please postpone any subscription related changes > (preferences, unsubscribe requests, etc) until the upgrade is > completed. I will send another email after everything is back to > normal. > > There is chance that right after the upgrade some of the > Mailman configuration options may be reset. This may result in some > unwanted spam. If this happens we should fix the problem promptly. > In the mean time please have some patience. The upgrade is completed and everything should be back to normal. Please let me know if you find any Mailman-related problems. Thanks, Pavlin