From James Courtier-Dutton Sun May 1 16:02:33 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sun, 1 May 2005 16:02:33 +0100 Subject: [Xorp-users] Possible bug in Point-to-Point code in XORP Message-ID: Using "route add -host 158.234.90.23 off0" Xorp> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 158.234.90.23/32 0.0.0.0 off0 1 254 65535 192.168.1.0/24 192.168.1.6 eth0 0 0 0 192.168.10.0/24 192.168.10.2 off0 1 0 0 192.168.10.2/32 192.168.10.2 off0 1 0 0 One gets the error message: [ 2005/05/01 12:30:09 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true: upstream neighbor for RP 158.234.90.23 for group 233.64.38.50: not found Using "route add -host 158.234.90.23 gw 192.168.10.1" Xorp> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 158.234.90.23/32 192.168.10.1 off0 1 254 65535 192.168.1.0/24 192.168.1.6 eth0 0 0 0 192.168.10.0/24 192.168.10.2 off0 1 0 0 192.168.10.2/32 192.168.10.2 off0 1 0 0 The WARNING disappears, and the upstream neighbor is found. So, I conclude that XORP has a problem with Point-to-Point links where one uses the interface name in the route entry instead of the IP address. Luckily I am using numbered Point-to-Point links, but XORP would fail to function if un-numbered point-to-point links were being used. James From pavlin@icir.org Sun May 1 18:12:53 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 01 May 2005 10:12:53 -0700 Subject: [Xorp-users] Possible bug in Point-to-Point code in XORP In-Reply-To: Message from James Courtier-Dutton of "Sun, 01 May 2005 16:02:33 BST." Message-ID: <200505011712.j41HCrD9081679@possum.icir.org> > Using "route add -host 158.234.90.23 off0" > Xorp> show pim mrib > DestPrefix NextHopRouter VifName VifIndex MetricPref Metric > 158.234.90.23/32 0.0.0.0 off0 1 254 65535 > 192.168.1.0/24 192.168.1.6 eth0 0 0 0 > 192.168.10.0/24 192.168.10.2 off0 1 0 0 > 192.168.10.2/32 192.168.10.2 off0 1 0 0 > One gets the error message: > [ 2005/05/01 12:30:09 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = > true: upstream neighbor for RP 158.234.90.23 for group 233.64.38.50: > not found > > Using "route add -host 158.234.90.23 gw 192.168.10.1" > Xorp> show pim mrib > DestPrefix NextHopRouter VifName VifIndex MetricPref Metric > 158.234.90.23/32 192.168.10.1 off0 1 254 65535 > 192.168.1.0/24 192.168.1.6 eth0 0 0 0 > 192.168.10.0/24 192.168.10.2 off0 1 0 0 > 192.168.10.2/32 192.168.10.2 off0 1 0 0 > > The WARNING disappears, and the upstream neighbor is found. > > So, I conclude that XORP has a problem with Point-to-Point links where > one uses the interface name in the route entry instead of the IP > address. > > Luckily I am using numbered Point-to-Point links, but XORP would fail > to function if un-numbered point-to-point links were being used. Yes, currently the PIM-SM implementation doesn't support unnumbered point-to-point links. Indeed, even on numbered p2p links the next-hop information should be an IP address (except for the subnet of the p2p link itself). This should be fixed in the future, but for the time being you need to use a solution as the one you describe above. Now the ERRATA file contains an entry for this issue. Thanks for the observation, Pavlin From James Courtier-Dutton Sun May 1 19:04:23 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sun, 1 May 2005 19:04:23 +0100 Subject: [Xorp-users] xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. Message-ID: I have tried to get xorp to route multicast traffic using PIM-SM, but it has failed. I have 2 hosts A and B with a GRE tunnel over the internet between them. The tunnel name is called off0. The multicast traffic is sourced on the ethernet interface of xorp A. On xorp B I have the following: In the xorp_rtrmgr window I see: [ 2005/05/01 18:55:39 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 192.168.10.1 to 224.0.0.13 on vif off0 But on xorp B: tcpdump -i off0 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on off0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 18:55:38.495167 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 77 18:55:38.571164 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 67 18:55:38.653146 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 111 18:55:38.728131 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 50 18:55:38.810118 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 114 18:55:38.886102 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 78 18:55:38.967095 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 93 18:55:39.028094 IP 192.168.10.1 > PIM-ROUTERS.MCAST.NET: pim v2 Hello (Hold-time 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms override-interval=2500ms) (DR-Priority: 1) (Genid: 0x248bf4be) 18:55:39.041087 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 96 So, the strange thing is that xorp is seeing the pim v2 hello, but just not seeing the multicast stream 233.64.38.50:2000. Does anyone have any idea's why. To help me track this down, could someone please point me to the section of code that opens the socket for the multicast stream, and the section of code that receives multicast stream packets. At the moment, I have concluded that the Linux module ip_gre has a bug, whereby xorp does not think it is multicast capable. On xorp A (home0 is the GRE tunnel): ip mroute show (158.234.90.23, 233.64.38.50) Iif: eth1 Oifs: home0 (158.234.90.20, 233.64.38.50) Iif: eth1 Oifs: home0 On xorp B (off0 is the GRE tunnel) ip mroute show i.e. empty. I am hoping for some sort of route between off0 and eth0, as the PC requesting this multicast group is on eth0 at site B. Can anyone help? From James Courtier-Dutton Sun May 1 21:00:15 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sun, 1 May 2005 21:00:15 +0100 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: References: Message-ID: I found the fix for this. :-) On Linux one has to do: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter The reverse path filter was dropping all the multicast packets coming over the tunnel. Maybe this could be added to a FAQ or something like that. James On 5/1/05, James Courtier-Dutton wrote: > I have tried to get xorp to route multicast traffic using PIM-SM, but > it has failed. > I have 2 hosts A and B with a GRE tunnel over the internet between them. > The tunnel name is called off0. > The multicast traffic is sourced on the ethernet interface of xorp A. > On xorp B I have the following: > In the xorp_rtrmgr window I see: > [ 2005/05/01 18:55:39 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from > 192.168.10.1 to 224.0.0.13 on vif off0 > > But on xorp B: > tcpdump -i off0 > tcpdump: WARNING: arptype 778 not supported by libpcap - falling back > to cooked socket > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on off0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes > 18:55:38.495167 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 77 > 18:55:38.571164 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 67 > 18:55:38.653146 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 111 > 18:55:38.728131 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 50 > 18:55:38.810118 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 114 > 18:55:38.886102 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 78 > 18:55:38.967095 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 93 > 18:55:39.028094 IP 192.168.10.1 > PIM-ROUTERS.MCAST.NET: pim v2 Hello > (Hold-time 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms > override-interval=2500ms) (DR-Priority: 1) (Genid: 0x248bf4be) > 18:55:39.041087 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 96 > > So, the strange thing is that xorp is seeing the pim v2 hello, but > just not seeing the multicast stream 233.64.38.50:2000. Does anyone > have any idea's why. > > To help me track this down, could someone please point me to the > section of code that opens the socket for the multicast stream, and > the section of code that receives multicast stream packets. > > At the moment, I have concluded that the Linux module ip_gre has a > bug, whereby xorp does not think it is multicast capable. > > On xorp A (home0 is the GRE tunnel): > ip mroute show > (158.234.90.23, 233.64.38.50) Iif: eth1 Oifs: home0 > (158.234.90.20, 233.64.38.50) Iif: eth1 Oifs: home0 > > On xorp B (off0 is the GRE tunnel) > ip mroute show > > i.e. empty. > > I am hoping for some sort of route between off0 and eth0, as the PC > requesting this multicast group is on eth0 at site B. > > Can anyone help? > From pavlin@icir.org Sun May 1 21:11:41 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 01 May 2005 13:11:41 -0700 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: Message from James Courtier-Dutton of "Sun, 01 May 2005 21:00:15 BST." Message-ID: <200505012011.j41KBfS0082882@possum.icir.org> > I found the fix for this. :-) Great! I was in the process of tracing the problem, but I just found that my DSL modem/NAT/firewall at home doesn't like GRE tunnels... > On Linux one has to do: > echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter > > The reverse path filter was dropping all the multicast packets coming > over the tunnel. > > Maybe this could be added to a FAQ or something like that. Actually, it is already in ERRATA and the user manual (the PIM-SM section) :) Thanks, Pavlin > > James > > On 5/1/05, James Courtier-Dutton wrote: > > I have tried to get xorp to route multicast traffic using PIM-SM, but > > it has failed. > > I have 2 hosts A and B with a GRE tunnel over the internet between them. > > The tunnel name is called off0. > > The multicast traffic is sourced on the ethernet interface of xorp A. > > On xorp B I have the following: > > In the xorp_rtrmgr window I see: > > [ 2005/05/01 18:55:39 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from > > 192.168.10.1 to 224.0.0.13 on vif off0 > > > > But on xorp B: > > tcpdump -i off0 > > tcpdump: WARNING: arptype 778 not supported by libpcap - falling back > > to cooked socket > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on off0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes > > 18:55:38.495167 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 77 > > 18:55:38.571164 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 67 > > 18:55:38.653146 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 111 > > 18:55:38.728131 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 50 > > 18:55:38.810118 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 114 > > 18:55:38.886102 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 78 > > 18:55:38.967095 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 93 > > 18:55:39.028094 IP 192.168.10.1 > PIM-ROUTERS.MCAST.NET: pim v2 Hello > > (Hold-time 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms > > override-interval=2500ms) (DR-Priority: 1) (Genid: 0x248bf4be) > > 18:55:39.041087 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 96 > > > > So, the strange thing is that xorp is seeing the pim v2 hello, but > > just not seeing the multicast stream 233.64.38.50:2000. Does anyone > > have any idea's why. > > > > To help me track this down, could someone please point me to the > > section of code that opens the socket for the multicast stream, and > > the section of code that receives multicast stream packets. > > > > At the moment, I have concluded that the Linux module ip_gre has a > > bug, whereby xorp does not think it is multicast capable. > > > > On xorp A (home0 is the GRE tunnel): > > ip mroute show > > (158.234.90.23, 233.64.38.50) Iif: eth1 Oifs: home0 > > (158.234.90.20, 233.64.38.50) Iif: eth1 Oifs: home0 > > > > On xorp B (off0 is the GRE tunnel) > > ip mroute show > > > > i.e. empty. > > > > I am hoping for some sort of route between off0 and eth0, as the PC > > requesting this multicast group is on eth0 at site B. > > > > Can anyone help? > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From agibson@confabulator.net Sun May 1 21:36:31 2005 From: agibson@confabulator.net (Aaron) Date: Sun, 01 May 2005 15:36:31 -0500 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: <200505012011.j41KBfS0082882@possum.icir.org> References: <200505012011.j41KBfS0082882@possum.icir.org> Message-ID: <42753DCF.9060300@confabulator.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting, I had a similar issue with my DSL Modem (Speedstream 5100b) in pppoe-on-device mode with both gif and tun devices. pppoe-on-device mode is when the 5100b terminates the pppoe connection and hands the public IP address to the computer (in this case, my FreeBSD router) via DHCP. This seems to break gif/tun functionality. if I terminate pppoe on the FreeBSD router (pass through the 5100b) all worked perfectly, but put a greater cpu load on the pc than I cared for at the time. I wonder if there is some way around this. - --Aaron Pavlin Radoslavov wrote: >>I found the fix for this. :-) > > > Great! > I was in the process of tracing the problem, but I just found that > my DSL modem/NAT/firewall at home doesn't like GRE tunnels... > > >>On Linux one has to do: >>echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >> >>The reverse path filter was dropping all the multicast packets coming >>over the tunnel. >> >>Maybe this could be added to a FAQ or something like that. > > > Actually, it is already in ERRATA and the user manual (the PIM-SM > section) :) > > Thanks, > Pavlin > > >>James >> >>On 5/1/05, James Courtier-Dutton wrote: >> >>>I have tried to get xorp to route multicast traffic using PIM-SM, but >>>it has failed. >>>I have 2 hosts A and B with a GRE tunnel over the internet between them. >>>The tunnel name is called off0. >>>The multicast traffic is sourced on the ethernet interface of xorp A. >>>On xorp B I have the following: >>>In the xorp_rtrmgr window I see: >>>[ 2005/05/01 18:55:39 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from >>>192.168.10.1 to 224.0.0.13 on vif off0 >>> >>>But on xorp B: >>>tcpdump -i off0 >>>tcpdump: WARNING: arptype 778 not supported by libpcap - falling back >>>to cooked socket >>>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >>>listening on off0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes >>>18:55:38.495167 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 77 >>>18:55:38.571164 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 67 >>>18:55:38.653146 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 111 >>>18:55:38.728131 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 50 >>>18:55:38.810118 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 114 >>>18:55:38.886102 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 78 >>>18:55:38.967095 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 93 >>>18:55:39.028094 IP 192.168.10.1 > PIM-ROUTERS.MCAST.NET: pim v2 Hello >>>(Hold-time 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms >>>override-interval=2500ms) (DR-Priority: 1) (Genid: 0x248bf4be) >>>18:55:39.041087 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 96 >>> >>>So, the strange thing is that xorp is seeing the pim v2 hello, but >>>just not seeing the multicast stream 233.64.38.50:2000. Does anyone >>>have any idea's why. >>> >>>To help me track this down, could someone please point me to the >>>section of code that opens the socket for the multicast stream, and >>>the section of code that receives multicast stream packets. >>> >>>At the moment, I have concluded that the Linux module ip_gre has a >>>bug, whereby xorp does not think it is multicast capable. >>> >>>On xorp A (home0 is the GRE tunnel): >>>ip mroute show >>>(158.234.90.23, 233.64.38.50) Iif: eth1 Oifs: home0 >>>(158.234.90.20, 233.64.38.50) Iif: eth1 Oifs: home0 >>> >>>On xorp B (off0 is the GRE tunnel) >>>ip mroute show >>> >>>i.e. empty. >>> >>>I am hoping for some sort of route between off0 and eth0, as the PC >>>requesting this multicast group is on eth0 at site B. >>> >>>Can anyone help? >>> >> >>_______________________________________________ >>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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCdT3Pm1yLNDpKjl4RAnw1AKC5PbFy3qWXi3DBfs/CI4Yyt4srFACg1c8N +eypOt7k7U8jydFKAJ5YOR8= =Ljka -----END PGP SIGNATURE----- From James Courtier-Dutton Sun May 1 22:01:11 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sun, 1 May 2005 22:01:11 +0100 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: <42753DCF.9060300@confabulator.net> References: <200505012011.j41KBfS0082882@possum.icir.org> <42753DCF.9060300@confabulator.net> Message-ID: Aaron, GRE works based on the endpoint address being a fixed IP address. So, if you get given a different IP address each time the pppoe dial, it will not work. Not only will you have to change your local end, but the remote GRE machine will also have to change. You could potentially automate this, by reconfiguring your local end depending on the DHCP IP address, and then ssh to the remote end and reconfigure that to the new endpoint IP address. I have also found that if any changes happen to the tun interface, xorp has to be restarted. James On 5/1/05, Aaron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Interesting, I had a similar issue with my DSL Modem (Speedstream 5100b) > in pppoe-on-device mode with both gif and tun devices. > > pppoe-on-device mode is when the 5100b terminates the pppoe connection > and hands the public IP address to the computer (in this case, my > FreeBSD router) via DHCP. This seems to break gif/tun functionality. > > if I terminate pppoe on the FreeBSD router (pass through the 5100b) all > worked perfectly, but put a greater cpu load on the pc than I cared for > at the time. > > I wonder if there is some way around this. > > - --Aaron > > > Pavlin Radoslavov wrote: > >>I found the fix for this. :-) > > > > > > Great! > > I was in the process of tracing the problem, but I just found that > > my DSL modem/NAT/firewall at home doesn't like GRE tunnels... > > > > > >>On Linux one has to do: > >>echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter > >> > >>The reverse path filter was dropping all the multicast packets coming > >>over the tunnel. > >> > >>Maybe this could be added to a FAQ or something like that. > > > > > > Actually, it is already in ERRATA and the user manual (the PIM-SM > > section) :) > > > > Thanks, > > Pavlin > > > > > >>James > >> > >>On 5/1/05, James Courtier-Dutton wrote: > >> > >>>I have tried to get xorp to route multicast traffic using PIM-SM, but > >>>it has failed. > >>>I have 2 hosts A and B with a GRE tunnel over the internet between them. > >>>The tunnel name is called off0. > >>>The multicast traffic is sourced on the ethernet interface of xorp A. > >>>On xorp B I have the following: > >>>In the xorp_rtrmgr window I see: > >>>[ 2005/05/01 18:55:39 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from > >>>192.168.10.1 to 224.0.0.13 on vif off0 > >>> > >>>But on xorp B: > >>>tcpdump -i off0 > >>>tcpdump: WARNING: arptype 778 not supported by libpcap - falling back > >>>to cooked socket > >>>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > >>>listening on off0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes > >>>18:55:38.495167 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 77 > >>>18:55:38.571164 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 67 > >>>18:55:38.653146 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 111 > >>>18:55:38.728131 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 50 > >>>18:55:38.810118 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 114 > >>>18:55:38.886102 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 78 > >>>18:55:38.967095 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 93 > >>>18:55:39.028094 IP 192.168.10.1 > PIM-ROUTERS.MCAST.NET: pim v2 Hello > >>>(Hold-time 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms > >>>override-interval=2500ms) (DR-Priority: 1) (Genid: 0x248bf4be) > >>>18:55:39.041087 IP 158.234.90.20.1119 > 233.64.38.50.2000: UDP, length: 96 > >>> > >>>So, the strange thing is that xorp is seeing the pim v2 hello, but > >>>just not seeing the multicast stream 233.64.38.50:2000. Does anyone > >>>have any idea's why. > >>> > >>>To help me track this down, could someone please point me to the > >>>section of code that opens the socket for the multicast stream, and > >>>the section of code that receives multicast stream packets. > >>> > >>>At the moment, I have concluded that the Linux module ip_gre has a > >>>bug, whereby xorp does not think it is multicast capable. > >>> > >>>On xorp A (home0 is the GRE tunnel): > >>>ip mroute show > >>>(158.234.90.23, 233.64.38.50) Iif: eth1 Oifs: home0 > >>>(158.234.90.20, 233.64.38.50) Iif: eth1 Oifs: home0 > >>> > >>>On xorp B (off0 is the GRE tunnel) > >>>ip mroute show > >>> > >>>i.e. empty. > >>> > >>>I am hoping for some sort of route between off0 and eth0, as the PC > >>>requesting this multicast group is on eth0 at site B. > >>> > >>>Can anyone help? > >>> > >> > >>_______________________________________________ > >>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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (FreeBSD) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCdT3Pm1yLNDpKjl4RAnw1AKC5PbFy3qWXi3DBfs/CI4Yyt4srFACg1c8N > +eypOt7k7U8jydFKAJ5YOR8= > =Ljka > -----END PGP SIGNATURE----- > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin@icir.org Sun May 1 23:32:42 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 01 May 2005 15:32:42 -0700 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: Message from Aaron of "Sun, 01 May 2005 15:36:31 CDT." <42753DCF.9060300@confabulator.net> Message-ID: <200505012232.j41MWgBV083827@possum.icir.org> > Interesting, I had a similar issue with my DSL Modem (Speedstream 5100b) > in pppoe-on-device mode with both gif and tun devices. Your problem is probably different. In my case it appears that the DSL modem/NAT/firewall (2Wire HomePortal 1000) supports only TCP, UDP and ICMP, so I can't configure it to enable any other protocols (including GRE). FYI, I am able to use openvpn tunnels but those use UDP or TCP-based encapsulation. I don't know about the CPU load because I've used openvpn only for testing purpose with low bandwidth traffic. Regards, Pavlin > > pppoe-on-device mode is when the 5100b terminates the pppoe connection > and hands the public IP address to the computer (in this case, my > FreeBSD router) via DHCP. This seems to break gif/tun functionality. > > if I terminate pppoe on the FreeBSD router (pass through the 5100b) all > worked perfectly, but put a greater cpu load on the pc than I cared for > at the time. > > I wonder if there is some way around this. From bms@spc.org Sun May 1 23:42:06 2005 From: bms@spc.org (Bruce M Simpson) Date: Sun, 1 May 2005 23:42:06 +0100 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: <200505012232.j41MWgBV083827@possum.icir.org> References: <42753DCF.9060300@confabulator.net> <200505012232.j41MWgBV083827@possum.icir.org> Message-ID: <20050501224206.GA9824@empiric.icir.org> On Sun, May 01, 2005 at 03:32:42PM -0700, Pavlin Radoslavov wrote: > Your problem is probably different. In my case it appears that the > DSL modem/NAT/firewall (2Wire HomePortal 1000) supports only TCP, > UDP and ICMP, so I can't configure it to enable any other protocols > (including GRE). Welcome to my own private hell. This is why I began hacking on native ADSL support for FreeBSD. BMS From pavlin@icir.org Mon May 2 00:58:48 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 01 May 2005 16:58:48 -0700 Subject: [Xorp-users] Re: xorp fails to detect multicast traffic arriving over a GRE tunnel in Linux. In-Reply-To: Message from James Courtier-Dutton of "Sun, 01 May 2005 22:01:11 BST." Message-ID: <200505012358.j41NwmDw084345@possum.icir.org> > I have also found that if any changes happen to the tun interface, > xorp has to be restarted. Could you elaborate on this. Sounds like a XORP bug that needs to be fixed. Thanks, Pavlin From caldwell_jason@bah.com Wed May 4 21:00:24 2005 From: caldwell_jason@bah.com (Caldwell Jason) Date: Wed, 4 May 2005 16:00:24 -0400 Subject: [Xorp-users] RIP XORP 1.1RC between Juniper M10 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C550E3.E8FBE696 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pavlin, Im trying to configure RIP between my XORP 1.1-RC OpenBSD3.6 router and = my Juniper M10 router v6.1R1.4, below are my configuration for both = routers... Basically it seems that both routers are configured = correctly and seem to have RIP enabled... On my console window of the = XORP router Im receiving the error below... Thanks, Jason... ------ XORP Error [ 2005/05/04 15:14:17 WARNING xorp_fea XrlSocketServerTarget ] Handling = method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 = Command failed Host is down [ 2005/05/04 15:14:17 ERROR xorp_rip:16796 RIP +526 port.cc = port_io_send_completion ] Send failed ------ ------ XORP Config's protocols { rip { targetname: "rip" export connected { metric: 1 tag: 0 } interface em0 { vif em0 { address 1.10.2.10 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: false route-expiry-secs: 180 route-deletion-secs: 120 triggered-update-min-secs: 1 triggered-update-max-secs: 5 table-announce-min-secs: 25 table-announce-max-secs: 35 table-request-secs: 1 interpacket-delay-msecs: 50 } } } } } ------ XORP> run show rip status all * RIP on em0 em0 1.10.2.10 Status: enabled ------ XORP> run show rip statistics all * RIP on em0 em0 1.10.2.10 Status: enabled Counter Value -------------------------------- ---------------- Requests Sent 186027 Updates Sent 6308 Triggered Updates Sent 0 Non-RIP Updates Sent 0 Total Packets Received 0 Request Packets Received 0 Update Packets Received 0 Bad Packets Received 0 Authentication Failures 0 Bad Routes Received 0 Non-RIP Requests Received 0 ------ XORP> run show route table ipv4 unicast rip Network 1.10.2.0/24 Nexthop :=3D 1.10.2.10 Metric :=3D 1 Protocol :=3D rip Interface :=3D em0 Vif = :=3D em0 Network 12.0.0.0/24 Nexthop :=3D 12.0.0.1 Metric :=3D 1 Protocol :=3D rip Interface :=3D xl1 Vif = :=3D xl1 Network 14.0.0.0/24 Nexthop :=3D 14.0.0.1 Metric :=3D 1 Protocol :=3D rip Interface :=3D xl0 Vif = :=3D xl0 ------ ------ Juniper Config's; M10# run show configuration protocols rip group xorp { neighbor fe-1/1/0.0 { receive both; } neighbor fe-1/1/1.0 { receive both; } } ------ M10# run show rip neighbor logical-router all logical-router: default Source Destination Send Receive = In Neighbor State Address Address Mode Mode = Met -------- ----- ------- ----------- ---- ------- = --- fe-1/1/1.0 Up 1.11.2.2 224.0.0.9 mcast both = 1 fe-1/1/0.0 Up 1.10.2.3 224.0.0.9 mcast both = 1 ------ M10# run show rip statistics RIPv2 info: port 520; update interval 30s; holddown 180s; timeout 120s. rts learned rts held down rqsts dropped resps dropped 0 0 0 0 fe-1/1/1.0: 0 routes learned; 0 routes advertised Counter Total Last 5 min Last minute ------- ----------- ----------- ----------- Updates Sent 0 0 0 Triggered Updates Sent 0 0 0 Responses Sent 0 0 0 Bad Messages 0 0 0 RIPv1 Updates Received 0 0 0 RIPv1 Bad Route Entries 0 0 0 RIPv1 Updates Ignored 0 0 0 RIPv2 Updates Received 0 0 0 RIPv2 Bad Route Entries 0 0 0 RIPv2 Updates Ignored 0 0 0 Authentication Failures 0 0 0 RIP Requests Received 0 0 0 RIP Requests Ignored 0 0 0 fe-1/1/0.0: 0 routes learned; 0 routes advertised Counter Total Last 5 min Last minute ------- ----------- ----------- ----------- Updates Sent 0 0 0 Triggered Updates Sent 0 0 0 Responses Sent 0 0 0 Bad Messages 0 0 0 RIPv1 Updates Received 0 0 0 RIPv1 Bad Route Entries 0 0 0 RIPv1 Updates Ignored 0 0 0 RIPv2 Updates Received 0 0 0 RIPv2 Bad Route Entries 0 0 0 RIPv2 Updates Ignored 0 0 0 Authentication Failures 0 0 0 RIP Requests Received 0 0 0 RIP Requests Ignored 0 0 0 =20 ~~~~~~~ Jason Caldwell=20 Booz | Allen | Hamilton=20 900 Elkridge Landing Road (Office 322)=20 Linthicum, MD 21090=20 410.684.6567 Office=20 Caldwell_Jason@bah.com=20 ------_=_NextPart_001_01C550E3.E8FBE696 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RIP XORP 1.1RC between Juniper M10

Pavlin,

Im trying to configure RIP between my XORP 1.1-RC OpenBSD3.6 router and = my Juniper M10 router v6.1R1.4, below are my configuration for both = routers...  Basically it seems that both routers are configured = correctly and seem to have RIP enabled... On my console window of the = XORP router Im receiving the error below... Thanks, Jason...

------
XORP Error
[ 2005/05/04 15:14:17 WARNING xorp_fea XrlSocketServerTarget ] Handling = method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 = Command failed Host is down
[ 2005/05/04 15:14:17  ERROR xorp_rip:16796 RIP +526 port.cc = port_io_send_completion ] Send failed
------

------
XORP Config's
protocols {
        rip {
            = targetname: "rip"
            = export connected {
            &= nbsp;   metric: 1
            &= nbsp;   tag: 0
            }
            = interface em0 {
            &= nbsp;   vif em0 {
            &= nbsp;       address 1.10.2.10 {
            &= nbsp;           = metric: 1
            &= nbsp;           = horizon: "split-horizon-poison-reverse"
            &= nbsp;           = disable: false
            &= nbsp;           = passive: false
            &= nbsp;           = accept-non-rip-requests: true
            &= nbsp;           = accept-default-route: true
            &= nbsp;           = advertise-default-route: false
            &= nbsp;           = route-expiry-secs: 180
            &= nbsp;           = route-deletion-secs: 120
            &= nbsp;           = triggered-update-min-secs: 1
            &= nbsp;           = triggered-update-max-secs: 5
            &= nbsp;           = table-announce-min-secs: 25
            &= nbsp;           = table-announce-max-secs: 35
            &= nbsp;           = table-request-secs: 1
            &= nbsp;           = interpacket-delay-msecs: 50
            &= nbsp;       }
            &= nbsp;   }
            }
        }
    }
------
XORP> run show rip status all

* RIP on em0 em0 1.10.2.10
  Status: enabled
------
XORP> run show rip statistics all

* RIP on em0 em0 1.10.2.10
  Status: enabled

  = Counter           =             &= nbsp;           &n= bsp; Value
  -------------------------------- ----------------
  Requests = Sent           &nb= sp;           &nbs= p;      186027
  Updates = Sent           &nb= sp;           &nbs= p;         6308
  Triggered Updates = Sent           &nb= sp;           &nbs= p;  0
  Non-RIP Updates = Sent           &nb= sp;           &nbs= p;    0
  Total Packets = Received           = ;            =    0
  Request Packets = Received           = ;            = 0
  Update Packets = Received           = ;            =   0
  Bad Packets = Received           = ;            =      0
  Authentication = Failures           = ;            =   0
  Bad Routes = Received           = ;            =       0
  Non-RIP Requests = Received           = ;            = 0
------
XORP> run show route table ipv4 unicast rip
Network 1.10.2.0/24
    Nexthop :=3D 1.10.2.10
    Metric :=3D     = 1    Protocol :=3D rip    Interface :=3D = em0    Vif :=3D em0
Network 12.0.0.0/24
    Nexthop :=3D 12.0.0.1
    Metric :=3D     = 1    Protocol :=3D rip    Interface :=3D = xl1    Vif :=3D xl1
Network 14.0.0.0/24
    Nexthop :=3D 14.0.0.1
    Metric :=3D     = 1    Protocol :=3D rip    Interface :=3D = xl0    Vif :=3D xl0
------

------
Juniper Config's;
M10# run show configuration protocols rip
group xorp {
    neighbor fe-1/1/0.0 {
        receive both;
    }
    neighbor fe-1/1/1.0 {
        receive both;
    }
}

------
M10# run show rip neighbor logical-router all

logical-router: default
            &= nbsp;            = Source          = Destination     Send   Receive   = In
Neighbor          = State  Address         = Address         Mode   = Mode     Met
--------          = -----  -------         = -----------     ----   -------  = ---
fe-1/1/1.0           = Up 1.11.2.2        = 224.0.0.9       mcast  = both       1
fe-1/1/0.0           = Up 1.10.2.3        = 224.0.0.9       mcast  = both       1
------
M10# run show rip statistics
RIPv2 info: port 520; update interval 30s; holddown 180s; timeout = 120s.
    rts learned  rts held down  rqsts = dropped  resps dropped
            &= nbsp; = 0            =   = 0            =   = 0            =   0

fe-1/1/1.0:  0 routes learned; 0 routes advertised
Counter           =             &= nbsp; Total   Last 5 min  Last minute
-------           =         -----------  = -----------  -----------
Updates = Sent           &nb= sp;            = 0            = 0            = 0
Triggered Updates = Sent           &nb= sp;  = 0            = 0            = 0
Responses = Sent           &nb= sp;          = 0            = 0            = 0
Bad = Messages           = ;            = 0            = 0            = 0
RIPv1 Updates = Received           = ;   = 0            = 0            = 0
RIPv1 Bad Route = Entries           =   = 0            = 0            = 0
RIPv1 Updates = Ignored           =     = 0            = 0            = 0
RIPv2 Updates = Received           = ;   = 0            = 0            = 0
RIPv2 Bad Route = Entries           =   = 0            = 0            = 0
RIPv2 Updates = Ignored           =     = 0            = 0            = 0
Authentication = Failures           = ;  = 0            = 0            = 0
RIP Requests = Received           = ;    = 0            = 0            = 0
RIP Requests = Ignored           =      = 0            = 0            = 0

fe-1/1/0.0:  0 routes learned; 0 routes advertised
Counter           =             &= nbsp; Total   Last 5 min  Last minute
-------           =         -----------  = -----------  -----------
Updates = Sent           &nb= sp;            = 0            = 0            = 0
Triggered Updates = Sent           &nb= sp;  = 0            = 0            = 0
Responses = Sent           &nb= sp;          = 0            = 0            = 0
Bad = Messages           = ;            = 0            = 0            = 0
RIPv1 Updates = Received           = ;   = 0            = 0            = 0
RIPv1 Bad Route = Entries           =   = 0            = 0            = 0
RIPv1 Updates = Ignored           =     = 0            = 0            = 0
RIPv2 Updates = Received           = ;   = 0            = 0            = 0
RIPv2 Bad Route = Entries           =   = 0            = 0            = 0
RIPv2 Updates = Ignored           =     = 0            = 0            = 0
Authentication = Failures           = ;  = 0            = 0            = 0
RIP Requests = Received           = ;    = 0            = 0            = 0
RIP Requests = Ignored           =      = 0            = 0            = 0



~~~~~~~
Jason Caldwell
Booz | Allen | Hamilton
900 Elkridge Landing Road (Office 322)
Linthicum, MD 21090
410.684.6567 Office
Caldwell_Jason@bah.com

------_=_NextPart_001_01C550E3.E8FBE696-- From pavlin@icir.org Wed May 4 21:39:38 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 04 May 2005 13:39:38 -0700 Subject: [Xorp-users] RIP XORP 1.1RC between Juniper M10 In-Reply-To: Message from "Caldwell Jason" of "Wed, 04 May 2005 16:00:24 EDT." Message-ID: <200505042039.j44Kdc5N016774@possum.icir.org> > Im trying to configure RIP between my XORP 1.1-RC OpenBSD3.6 router and = > my Juniper M10 router v6.1R1.4, below are my configuration for both = > routers... Basically it seems that both routers are configured = > correctly and seem to have RIP enabled... On my console window of the = > XORP router Im receiving the error below... Thanks, Jason... > > ------ > XORP Error > [ 2005/05/04 15:14:17 WARNING xorp_fea XrlSocketServerTarget ] Handling = > method for socket4/0.1/send_from_multicast_if failed: XrlCmdError 102 = > Command failed Host is down > [ 2005/05/04 15:14:17 ERROR xorp_rip:16796 RIP +526 port.cc = > port_io_send_completion ] Send failed > ------ Jason, It looks like the above error messages have nothing to do with the other RIP router, and are because the XORP router fails to send the RIP multicast packets on the interface toward the other router. My guess this happens because you haven't enable the multicast_host/multicast_router setup (e.g., see netstart(8) for details). To fix this you need to add to your /etc/rc.conf.local the following two lines and then reboot: multicast_host=NO multicast_router=YES OR multicast_host=YES multicast_router=NO If you still get the same error, try to use some test program to send multicast traffic to group 224.0.0.9 port 520 on the interface toward the Juniper router and see if you can succeed. The following email contains instructions how to use one such program: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-April/000532.html Regards, Pavlin > > ------ > XORP Config's > protocols { > rip { > targetname: "rip" > export connected { > metric: 1 > tag: 0 > } > interface em0 { > vif em0 { > address 1.10.2.10 { > metric: 1 > horizon: "split-horizon-poison-reverse" > disable: false > passive: false > accept-non-rip-requests: true > accept-default-route: true > advertise-default-route: false > route-expiry-secs: 180 > route-deletion-secs: 120 > triggered-update-min-secs: 1 > triggered-update-max-secs: 5 > table-announce-min-secs: 25 > table-announce-max-secs: 35 > table-request-secs: 1 > interpacket-delay-msecs: 50 > } > } > } > } > } > ------ > XORP> run show rip status all > > * RIP on em0 em0 1.10.2.10 > Status: enabled > ------ > XORP> run show rip statistics all > > * RIP on em0 em0 1.10.2.10 > Status: enabled > > Counter Value > -------------------------------- ---------------- > Requests Sent 186027 > Updates Sent 6308 > Triggered Updates Sent 0 > Non-RIP Updates Sent 0 > Total Packets Received 0 > Request Packets Received 0 > Update Packets Received 0 > Bad Packets Received 0 > Authentication Failures 0 > Bad Routes Received 0 > Non-RIP Requests Received 0 > ------ > XORP> run show route table ipv4 unicast rip > Network 1.10.2.0/24 > Nexthop :=3D 1.10.2.10 > Metric :=3D 1 Protocol :=3D rip Interface :=3D em0 Vif = > :=3D em0 > Network 12.0.0.0/24 > Nexthop :=3D 12.0.0.1 > Metric :=3D 1 Protocol :=3D rip Interface :=3D xl1 Vif = > :=3D xl1 > Network 14.0.0.0/24 > Nexthop :=3D 14.0.0.1 > Metric :=3D 1 Protocol :=3D rip Interface :=3D xl0 Vif = > :=3D xl0 > ------ > > ------ > Juniper Config's; > M10# run show configuration protocols rip > group xorp { > neighbor fe-1/1/0.0 { > receive both; > } > neighbor fe-1/1/1.0 { > receive both; > } > } > > ------ > M10# run show rip neighbor logical-router all > > logical-router: default > Source Destination Send Receive = > In > Neighbor State Address Address Mode Mode = > Met > -------- ----- ------- ----------- ---- ------- = > --- > fe-1/1/1.0 Up 1.11.2.2 224.0.0.9 mcast both = > 1 > fe-1/1/0.0 Up 1.10.2.3 224.0.0.9 mcast both = > 1 > ------ > M10# run show rip statistics > RIPv2 info: port 520; update interval 30s; holddown 180s; timeout 120s. > rts learned rts held down rqsts dropped resps dropped > 0 0 0 0 > > fe-1/1/1.0: 0 routes learned; 0 routes advertised > Counter Total Last 5 min Last minute > ------- ----------- ----------- ----------- > Updates Sent 0 0 0 > Triggered Updates Sent 0 0 0 > Responses Sent 0 0 0 > Bad Messages 0 0 0 > RIPv1 Updates Received 0 0 0 > RIPv1 Bad Route Entries 0 0 0 > RIPv1 Updates Ignored 0 0 0 > RIPv2 Updates Received 0 0 0 > RIPv2 Bad Route Entries 0 0 0 > RIPv2 Updates Ignored 0 0 0 > Authentication Failures 0 0 0 > RIP Requests Received 0 0 0 > RIP Requests Ignored 0 0 0 > > fe-1/1/0.0: 0 routes learned; 0 routes advertised > Counter Total Last 5 min Last minute > ------- ----------- ----------- ----------- > Updates Sent 0 0 0 > Triggered Updates Sent 0 0 0 > Responses Sent 0 0 0 > Bad Messages 0 0 0 > RIPv1 Updates Received 0 0 0 > RIPv1 Bad Route Entries 0 0 0 > RIPv1 Updates Ignored 0 0 0 > RIPv2 Updates Received 0 0 0 > RIPv2 Bad Route Entries 0 0 0 > RIPv2 Updates Ignored 0 0 0 > Authentication Failures 0 0 0 > RIP Requests Received 0 0 0 > RIP Requests Ignored 0 0 0 > > =20 > > ~~~~~~~ > Jason Caldwell=20 > Booz | Allen | Hamilton=20 > 900 Elkridge Landing Road (Office 322)=20 > Linthicum, MD 21090=20 > 410.684.6567 Office=20 > Caldwell_Jason@bah.com=20 From satko@quanto.nr.sanet.sk Thu May 5 11:12:05 2005 From: satko@quanto.nr.sanet.sk (Jan Satko) Date: Thu, 5 May 2005 12:12:05 +0200 (CEST) Subject: [Xorp-users] multicast problem Message-ID: Hi. I have following situation: UPLINK----C6500-----local_net----XORP------notebook | | comp1 streaming_test C6500- cisco router with static RP (himself) (194.160.88.3, 193.87.96.3) notebook- 193.87.98.250 xorp: version 1.1, RH9 2.4.20-42.9.legacy eth0: 194.160.88.14 eth1: 193.87.98.3 streaming_test: 194.160.94.149 + multicast stream source 233.10.49.177 comp1: vlc client 193.87.96.15 I want to watch some video streaming source from UPLINK on notebook with vlc-videolan client (behind xorp). But it doens't work and I don't know where is the problem :-( So i try to stream some video file with VLC on streaming_test. On comp1 it is working. But on notebook not. Thank you for your help. Here is my config.boot: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.23 2005/03/09 22:50:41 pavlin Exp $ */ interfaces { interface eth0 { disable: false default-system-config } interface eth1 { disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 194.160.88.3 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } A here are some starting infos: [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] Protocol enabled [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] CLI enabled [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] CLI started [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] pif_inde x: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: 194.160 .95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] pif_inde x: 0 vif_index: 1 addr: 193.87.98.3 subnet: 193.87.98.0/24 broadcast: 193.87.98. 255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 0 vif_index: 2 addr: 194.160.88.14 subnet: 194.160.88.14/32 broadcast : 194.160.88.14 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Protocol started [ 2005/05/05 12:04:59 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] pif_in dex: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: 194.1 60.95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 E NABLED [ 2005/05/05 12:04:59 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] pif_in dex: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: 194.1 60.95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENA BLED [ 2005/05/05 12:06:17 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: pimsm4 [ 2005/05/05 12:06:17 INFO xorp_rtrmgr:12684 RTRMGR +525 module_manager.cc norm al_exit ] Module normal exit: pimsm4 [ 2005/05/05 12:06:18 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 ../xrl/tar gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0 .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" does not exist or is not enabled. [ 2005/05/05 12:06:19 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: igmp [ 2005/05/05 12:06:19 INFO xorp_rtrmgr:12684 RTRMGR +525 module_manager.cc norm al_exit ] Module normal exit: igmp [ 2005/05/05 12:06:20 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 ../xrl/tar gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0 .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does not exi st or is not enabled. [ 2005/05/05 12:06:21 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: fib2mrib [ 2005/05/05 12:06:21 INFO xorp_rtrmgr:12684 RTRMGR +525 module_manager.cc norm al_exit ] Module normal exit: fib2mrib [ 2005/05/05 12:06:22 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 ../xrl/tar gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0 .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fib2mrib" does not exist or is not enabled. [ 2005/05/05 12:06:23 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: rib [ 2005/05/05 12:06:23 INFO xorp_rtrmgr:12684 RTRMGR +525 module_manager.cc norm al_exit ] Module normal exit: rib [ 2005/05/05 12:06:24 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 ../xrl/tar gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0 .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does not exis t or is not enabled. [ 2005/05/05 12:06:25 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: mfea4 [ 2005/05/05 12:06:27 INFO xorp_rtrmgr:12684 RTRMGR +216 module_manager.cc term inate ] Terminating module: mfea4 [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +216 module_manager.cc term inate ] Terminating module: fea [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown ] Shu tting down module: interfaces [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +525 module_manager.cc norm al_exit ] Module normal exit: interfaces [ 2005/05/05 12:06:31 INFO xorp_rtrmgr:12684 RTRMGR +1420 task.cc run_task ] No more tasks to run ket from 193.87.3.3 to 224.0.0.2: no vif found [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.81 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.2 dst = 233.10.47.14 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.80 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.70 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.71 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.59 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 v if_index = 0 src = 194.160.9.4 dst = 233.10.47.60 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 v if_index [ 2005/05/05 12:05:10 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_ REPORT from 194.160.88.14 to 224.0.0.13 on vif eth0 [ 2005/05/05 12:05:15 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 1 94.160.88.3 to 224.0.0.1 on vif eth0 [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.94.200 to 239.255.255.250 on vif eth0 [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.190 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.90.26 to 233.10.47.59 on vif eth0 [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.90.26 to 224.2.127.254 on vif eth0 [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.88.14 to 224.0.0.13 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.95.7 to 227.0.0.2 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.92.146 to 239.255.255.250 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.93.160 to 224.0.1.60 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.93.19 to 224.0.1.22 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.88.28 to 224.101.101.101 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.95.5 to 224.2.127.254 on vif eth0 [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V1_MEMBERSHIP_REPORT fr om 194.160.95.5 to 233.10.47.71 on vif eth0 [ 2005/05/05 12:05:18 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.90.222 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:05:19 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.246 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:05:19 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.108 to 234.21.81.1 on vif eth0 [ 2005/05/05 12:05:20 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.92.180 to 234.0.0.1 on vif eth0 [ 2005/05/05 12:05:20 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.92.135 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:05:21 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.92.12 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:05:21 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.89.36 to 233.10.49.177 on vif eth0 [ 2005/05/05 12:05:22 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.250 to 233.10.49.177 on vif eth1 [ 2005/05/05 12:05:25 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.93.40 to 233.10.47.60 on vif eth0 [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 1 93.87.98.3 to 224.0.0.1 [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 1 93.87.98.3 to 224.0.0.1 on vif eth1 [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.250 to 233.10.49.177 on vif eth1 [ 2005/05/05 12:05:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.3 to 224.0.0.2 on vif eth1 [ 2005/05/05 12:05:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.250 to 224.2.127.254 on vif eth1 [ 2005/05/05 12:05:37 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.3 to 224.0.0.13 on vif eth1 [ 2005/05/05 12:05:37 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.250 to 239.255.255.250 on vif eth1 [ 2005/05/05 12:06:06 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 193.87.98.250 to 233.10.49.177 on vif eth1 [ 2005/05/05 12:06:15 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 1 94.160.88.3 to 224.0.0.1 on vif eth0 [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.169 to 239.255.255.250 on vif eth0 [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.44 to 233.10.47.59 on vif eth0 [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.92.180 to 234.0.0.1 on vif eth0 [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.88.14 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 194 .160.88.14 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.91.246 to 224.0.0.2 on vif eth0 [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 193 .87.98.3 to 224.0.0.2 on vif eth1 [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 1 93.87.98.3 to 224.0.0.13 [ 2005/05/05 12:06:18 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT fr om 194.160.90.26 to 224.2.127.254 on vif eth0 [ 2005/05/05 12:06:18 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 1 93.87.98.3 to 224.0.0.13 -- Bc. Jan 'EIS' Satko Slovak University of Agriculture network & system manager Tr. A. Hlinku 2 Tel: +421 37 7412 616 949 76 Nitra Slovakia From pavlin@icir.org Fri May 6 03:55:48 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 05 May 2005 19:55:48 -0700 Subject: [Xorp-users] multicast problem In-Reply-To: Message from Jan Satko of "Thu, 05 May 2005 12:12:05 +0200." Message-ID: <200505060255.j462tmIc026254@possum.icir.org> > Hi. > I have following situation: > > UPLINK----C6500-----local_net----XORP------notebook > | | > comp1 streaming_test > > > C6500- cisco router with static RP (himself) (194.160.88.3, 193.87.96.3) > notebook- 193.87.98.250 > xorp: version 1.1, RH9 2.4.20-42.9.legacy eth0: 194.160.88.14 eth1: > 193.87.98.3 > streaming_test: 194.160.94.149 + multicast stream source 233.10.49.177 > comp1: vlc client 193.87.96.15 > > I want to watch some video streaming source from UPLINK on notebook with > vlc-videolan client (behind xorp). But it doens't work and I don't know > where is the problem :-( > So i try to stream some video file with VLC on streaming_test. On comp1 > it is working. But on notebook not. Jan, The config file appears OK. However, the log file is incomplete. For example, apart of the startup interface-related log messages, it doesn't contain any log messages that the PIM-SM is transmitting PIM control messages on its interfaces, etc. Hence, please restart XORP and send the complete log. Also, I'd recommend to use some of the xorpsh "show pim" commands to look around: e.g., does XORP PIM-SM see the Cisco as a neighbor, do you have a (*,G) Join state that points toward Cisco as the RP, etc. Furthermore, you could run tcpdump on the XORP's interface toward Cisco to see whether XORP sends properly PIM Hello and PIM Join/Prune messages. Similarly, if you can use Cisco's CLI to test whether the Cisco sees XORP as a neighbor and whether it is receiving PIM Join messages from it. Regards, Pavlin > > Thank you for your help. > > > Here is my config.boot: > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.23 2005/03/09 22:50:41 pavlin > Exp $ > */ > > > interfaces { > interface eth0 { > disable: false > default-system-config > } > interface eth1 { > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > static-rps { > rp 194.160.88.3 { > group-prefix 224.0.0.0/4 { > /* rp-priority: 192 */ > /* hash-mask-len: 30 */ > } > } > } > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval-sec: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > } > } > > /* > * Note: fib2mrib is needed for multicast only if the unicast protocols > * don't populate the MRIB with multicast-specific routes. > */ > protocols { > fib2mrib { > disable: false > } > } > > > A here are some starting infos: > [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] Protocol enabled > [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] CLI enabled > [ 2005/05/05 12:04:57 INFO xorp_pimsm4 PIM ] CLI started > [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] > pif_inde > x: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: > 194.160 > .95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] > pif_inde > x: 0 vif_index: 1 addr: 193.87.98.3 subnet: 193.87.98.0/24 broadcast: > 193.87.98. > 255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Interface added: > Vif[register_vif] > pif_index: 0 vif_index: 2 addr: 194.160.88.14 subnet: 194.160.88.14/32 > broadcast > : 194.160.88.14 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > [ 2005/05/05 12:04:58 INFO xorp_pimsm4 PIM ] Protocol started > [ 2005/05/05 12:04:59 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] > pif_in > dex: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: > 194.1 > 60.95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN > IPv4 E > NABLED > [ 2005/05/05 12:04:59 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] > pif_in > dex: 0 vif_index: 0 addr: 194.160.88.14 subnet: 194.160.88.0/21 broadcast: > 194.1 > 60.95.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP > IPv4 ENA > BLED > [ 2005/05/05 12:06:17 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: pimsm4 > [ 2005/05/05 12:06:17 INFO xorp_rtrmgr:12684 RTRMGR +525 > module_manager.cc norm > al_exit ] Module normal exit: pimsm4 > [ 2005/05/05 12:06:18 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 > ../xrl/tar > gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for > finder/0 > .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" > does not > exist or is not enabled. > [ 2005/05/05 12:06:19 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: igmp > [ 2005/05/05 12:06:19 INFO xorp_rtrmgr:12684 RTRMGR +525 > module_manager.cc norm > al_exit ] Module normal exit: igmp > [ 2005/05/05 12:06:20 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 > ../xrl/tar > gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for > finder/0 > .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does > not exi > st or is not enabled. > [ 2005/05/05 12:06:21 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: fib2mrib > [ 2005/05/05 12:06:21 INFO xorp_rtrmgr:12684 RTRMGR +525 > module_manager.cc norm > al_exit ] Module normal exit: fib2mrib > [ 2005/05/05 12:06:22 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 > ../xrl/tar > gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for > finder/0 > .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fib2mrib" > does not > exist or is not enabled. > [ 2005/05/05 12:06:23 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: rib > [ 2005/05/05 12:06:23 INFO xorp_rtrmgr:12684 RTRMGR +525 > module_manager.cc norm > al_exit ] Module normal exit: rib > [ 2005/05/05 12:06:24 WARNING xorp_rtrmgr:12684 XrlFinderTarget +406 > ../xrl/tar > gets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for > finder/0 > .2/resolve_xrl failed: XrlCmdError 102 Command failed Target "rib" does > not exis > t or is not enabled. > [ 2005/05/05 12:06:25 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: mfea4 > [ 2005/05/05 12:06:27 INFO xorp_rtrmgr:12684 RTRMGR +216 > module_manager.cc term > inate ] Terminating module: mfea4 > [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +216 > module_manager.cc term > inate ] Terminating module: fea > [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +600 task.cc shutdown > ] Shu > tting down module: interfaces > [ 2005/05/05 12:06:30 INFO xorp_rtrmgr:12684 RTRMGR +525 > module_manager.cc norm > al_exit ] Module normal exit: interfaces > [ 2005/05/05 12:06:31 INFO xorp_rtrmgr:12684 RTRMGR +1420 task.cc > run_task ] No > more tasks to run > ket from 193.87.3.3 to 224.0.0.2: no vif found > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.81 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.2 dst = 233.10.47.14 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.80 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.70 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.71 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.59 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 1 v > if_index = 0 src = 194.160.9.4 dst = 233.10.47.60 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index = 2 src = 194.160.94.149 dst = 233.10.49.177 > [ 2005/05/05 12:05:07 TRACE xorp_fea MFEA ] RX kernel signal: message_type > = 3 v > if_index [ 2005/05/05 12:05:10 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_ > REPORT from 194.160.88.14 to 224.0.0.13 on vif eth0 > [ 2005/05/05 12:05:15 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY > from 1 > 94.160.88.3 to 224.0.0.1 on vif eth0 > [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.94.200 to 239.255.255.250 on vif eth0 > [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.190 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.90.26 to 233.10.47.59 on vif eth0 > [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.90.26 to 224.2.127.254 on vif eth0 > [ 2005/05/05 12:05:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.88.14 to 224.0.0.13 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.95.7 to 227.0.0.2 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.92.146 to 239.255.255.250 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.93.160 to 224.0.1.60 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.93.19 to 224.0.1.22 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.88.28 to 224.101.101.101 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.95.5 to 224.2.127.254 on vif eth0 > [ 2005/05/05 12:05:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V1_MEMBERSHIP_REPORT fr > om 194.160.95.5 to 233.10.47.71 on vif eth0 > [ 2005/05/05 12:05:18 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.90.222 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:05:19 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.246 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:05:19 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.108 to 234.21.81.1 on vif eth0 > [ 2005/05/05 12:05:20 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.92.180 to 234.0.0.1 on vif eth0 > [ 2005/05/05 12:05:20 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.92.135 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:05:21 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.92.12 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:05:21 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.89.36 to 233.10.49.177 on vif eth0 > [ 2005/05/05 12:05:22 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.250 to 233.10.49.177 on vif eth1 > [ 2005/05/05 12:05:25 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.93.40 to 233.10.47.60 on vif eth0 > [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY > from 1 > 93.87.98.3 to 224.0.0.1 > [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY > from 1 > 93.87.98.3 to 224.0.0.1 on vif eth1 > [ 2005/05/05 12:05:28 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.250 to 233.10.49.177 on vif eth1 > [ 2005/05/05 12:05:31 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.3 to 224.0.0.2 on vif eth1 > [ 2005/05/05 12:05:36 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.250 to 224.2.127.254 on vif eth1 > [ 2005/05/05 12:05:37 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.3 to 224.0.0.13 on vif eth1 > [ 2005/05/05 12:05:37 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.250 to 239.255.255.250 on vif eth1 > [ 2005/05/05 12:06:06 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 193.87.98.250 to 233.10.49.177 on vif eth1 > [ 2005/05/05 12:06:15 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY > from 1 > 94.160.88.3 to 224.0.0.1 on vif eth0 > [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.169 to 239.255.255.250 on vif eth0 > [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.44 to 233.10.47.59 on vif eth0 > [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.92.180 to 234.0.0.1 on vif eth0 > [ 2005/05/05 12:06:16 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.88.14 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP > from 194 > .160.88.14 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.91.246 to 224.0.0.2 on vif eth0 > [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP > from 193 > .87.98.3 to 224.0.0.2 on vif eth1 > [ 2005/05/05 12:06:17 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY > from 1 > 93.87.98.3 to 224.0.0.13 > [ 2005/05/05 12:06:18 TRACE xorp_igmp MLD6IGMP ] RX > IGMP_V2_MEMBERSHIP_REPORT fr > om 194.160.90.26 to 224.2.127.254 on vif eth0 > [ 2005/05/05 12:06:18 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY > from 1 > 93.87.98.3 to 224.0.0.13 > > > -- > Bc. Jan 'EIS' Satko Slovak University of Agriculture > network & system manager Tr. A. Hlinku 2 > Tel: +421 37 7412 616 949 76 Nitra Slovakia > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From gernot.schmied@chello.at Sat May 7 22:40:09 2005 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sat, 07 May 2005 23:40:09 +0200 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 Message-ID: <427D35B9.1080402@chello.at> Hello, XORP-1.1 fails to compile on AMD64 Gentoo. Any idea? make[3]: Entering directory `/usr/local/src/Routing/xorp-1.1/fea' source='fticonfig_entry_get_netlink.cc' object='fticonfig_entry_get_netlink.lo' libtool=yes \ depfile='.deps/fticonfig_entry_get_netlink.Plo' tmpdepfile='.deps/fticonfig_entry_get_netlink.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wca st-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o fticonfig _entry_get_netlink.lo `test -f fticonfig_entry_get_netlink.cc || echo './'`fticonfig_entry_get_netlink.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcas t-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c fticonfig_entry_get_netlink.cc -MT fticonfig_entr y_get_netlink.lo -MD -MP -MF .deps/fticonfig_entry_get_netlink.TPlo -o fticonfig_entry_get_netlink.o fticonfig_entry_get_netlink.cc: In member function `virtual bool FtiConfigEntryGetNetlink::lookup_route_by_ dest(const IPvX&, FteX&)': fticonfig_entry_get_netlink.cc:317: warning: int format, different type arg (arg 4) make[3]: *** [fticonfig_entry_get_netlink.lo] Error 1 make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' make: *** [all] Error 2 Regards, Gernot From TTA Group Sun May 8 09:28:49 2005 From: TTA Group (TTA Group) Date: Sun, 8 May 2005 01:28:49 -0700 Subject: [Xorp-users] RTT "Round Trip Time" Message-ID: <9fa8f1af0505080128130f72db@mail.gmail.com> Hi, I'm a graduate student and my graduate project about "Round Trip Time" as router matrix. So I think to use XORP as my research environment. But I notice that the default xorp RIP matrix is "Hob Count". So does any one has any idea how I can make it RTT "Round trip time"? any help or suggestions in this subject or previous experience? I appreciate your time. Tariq ttagroup@gmail.com From pavlin@icir.org Sun May 8 20:30:52 2005 From: pavlin@icir.org (pavlin@icir.org) Date: Sun, 08 May 2005 12:30:52 -0700 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 In-Reply-To: <427D35B9.1080402@chello.at> References: <427D35B9.1080402@chello.at> Message-ID: <20050508123052D.pavlin@icir.org> ----Next_Part(Sun_May__8_12:30:33_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > XORP-1.1 fails to compile on AMD64 Gentoo. Any idea? > > make[3]: Entering directory `/usr/local/src/Routing/xorp-1.1/fea' > source='fticonfig_entry_get_netlink.cc' > object='fticonfig_entry_get_netlink.lo' libtool=yes \ > depfile='.deps/fticonfig_entry_get_netlink.Plo' > tmpdepfile='.deps/fticonfig_entry_get_netlink.TPlo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > -g -W -Wall -Wwrite-strings -Wca st-qual -Werror -Wpointer-arith > -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o > fticonfig _entry_get_netlink.lo `test -f fticonfig_entry_get_netlink.cc > || echo './'`fticonfig_entry_get_netlink.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcas t-align -Woverloaded-virtual > -ftemplate-depth-22 -pipe -c fticonfig_entry_get_netlink.cc -MT > fticonfig_entr y_get_netlink.lo -MD -MP -MF > .deps/fticonfig_entry_get_netlink.TPlo -o fticonfig_entry_get_netlink.o > fticonfig_entry_get_netlink.cc: In member function `virtual bool > FtiConfigEntryGetNetlink::lookup_route_by_ dest(const IPvX&, FteX&)': > fticonfig_entry_get_netlink.cc:317: warning: int format, different type > arg (arg 4) > make[3]: *** [fticonfig_entry_get_netlink.lo] Error 1 > make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' > make: *** [all] Error 2 Sigh, this is a casting error. Below is a patch (committed to CVS) that should fix the problem. Note that it fixes similar problems in other places as well, but without access to an AMD64 Linux box I cannot guarantee there aren't other similar compilation problems. Please let us know if there are other compilation errors. Thanks, Pavlin ----Next_Part(Sun_May__8_12:30:33_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux_amd64.patch" Index: fticonfig_entry_get_netlink.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/fticonfig_entry_get_netlink.cc,v retrieving revision 1.28 diff -u -p -r1.28 fticonfig_entry_get_netlink.cc --- fticonfig_entry_get_netlink.cc 25 Mar 2005 02:53:01 -0000 1.28 +++ fticonfig_entry_get_netlink.cc 8 May 2005 19:21:32 -0000 @@ -314,8 +314,9 @@ FtiConfigEntryGetNetlink::lookup_route_b // Add the 'ipaddr' address as an attribute rta_len = RTA_LENGTH(IPvX::addr_size(family)); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = RTM_RTA(rtmsg); rtattr->rta_type = RTA_DST; Index: fticonfig_entry_set_netlink.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/fticonfig_entry_set_netlink.cc,v retrieving revision 1.22 diff -u -p -r1.22 fticonfig_entry_set_netlink.cc --- fticonfig_entry_set_netlink.cc 25 Mar 2005 02:53:03 -0000 1.22 +++ fticonfig_entry_set_netlink.cc 8 May 2005 19:21:32 -0000 @@ -257,8 +257,9 @@ FtiConfigEntrySetNetlink::add_entry(cons // Add the destination address as an attribute rta_len = RTA_LENGTH(fte.net().masked_addr().addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = RTM_RTA(rtmsg); rtattr->rta_type = RTA_DST; @@ -271,8 +272,9 @@ FtiConfigEntrySetNetlink::add_entry(cons if (fte.nexthop() != IPvX::ZERO(family)) { rta_len = RTA_LENGTH(fte.nexthop().addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = (struct rtattr*)(((char*)(rtattr)) + RTA_ALIGN((rtattr)->rta_len)); rtattr->rta_type = RTA_GATEWAY; @@ -318,8 +320,9 @@ FtiConfigEntrySetNetlink::add_entry(cons int int_if_index = if_index; rta_len = RTA_LENGTH(sizeof(int_if_index)); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = (struct rtattr*)(((char*)(rtattr)) + RTA_ALIGN((rtattr)->rta_len)); @@ -334,8 +337,9 @@ FtiConfigEntrySetNetlink::add_entry(cons int int_priority = fte.metric(); rta_len = RTA_LENGTH(sizeof(int_priority)); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = (struct rtattr*)(((char*)(rtattr)) + RTA_ALIGN((rtattr)->rta_len)); rtattr->rta_type = RTA_PRIORITY; @@ -454,8 +458,9 @@ FtiConfigEntrySetNetlink::delete_entry(c // Add the destination address as an attribute rta_len = RTA_LENGTH(fte.net().masked_addr().addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = RTM_RTA(rtmsg); rtattr->rta_type = RTA_DST; Index: ifconfig_set_netlink.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/ifconfig_set_netlink.cc,v retrieving revision 1.21 diff -u -p -r1.21 ifconfig_set_netlink.cc --- ifconfig_set_netlink.cc 25 Mar 2005 02:53:08 -0000 1.21 +++ ifconfig_set_netlink.cc 8 May 2005 19:21:32 -0000 @@ -472,8 +472,9 @@ IfConfigSetNetlink::config_interface(con ifinfomsg->ifi_change = 0xffffffff; if (NLMSG_ALIGN(nlh->nlmsg_len) > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len)); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len))); } nlh->nlmsg_len = NLMSG_ALIGN(nlh->nlmsg_len); @@ -612,8 +613,9 @@ IfConfigSetNetlink::set_interface_mac_ad // Add the MAC address as an attribute rta_len = RTA_LENGTH(ETH_ALEN); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = IFLA_RTA(ifinfomsg); rtattr->rta_type = IFLA_ADDRESS; @@ -721,8 +723,9 @@ IfConfigSetNetlink::set_interface_mtu(co unsigned int uint_mtu = mtu; rta_len = RTA_LENGTH(sizeof(unsigned int)); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = IFLA_RTA(ifinfomsg); rtattr->rta_type = IFLA_MTU; @@ -876,8 +879,9 @@ IfConfigSetNetlink::add_vif_address(cons // Add the address as an attribute rta_len = RTA_LENGTH(addr.addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = IFA_RTA(ifaddrmsg); rtattr->rta_type = IFA_LOCAL; @@ -890,8 +894,9 @@ IfConfigSetNetlink::add_vif_address(cons // Set the p2p or broadcast address rta_len = RTA_LENGTH(dst_or_bcast.addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = (struct rtattr*)(((char*)(rtattr)) + RTA_ALIGN((rtattr)->rta_len)); rtattr->rta_type = IFA_UNSPEC; @@ -1019,8 +1024,9 @@ IfConfigSetNetlink::delete_vif_address(c // Add the address as an attribute rta_len = RTA_LENGTH(addr.addr_size()); if (NLMSG_ALIGN(nlh->nlmsg_len) + rta_len > sizeof(buffer)) { - XLOG_FATAL("AF_NETLINK buffer size error: %d instead of %d", - sizeof(buffer), NLMSG_ALIGN(nlh->nlmsg_len) + rta_len); + XLOG_FATAL("AF_NETLINK buffer size error: %u instead of %u", + XORP_UINT_CAST(sizeof(buffer)), + XORP_UINT_CAST(NLMSG_ALIGN(nlh->nlmsg_len) + rta_len)); } rtattr = IFA_RTA(ifaddrmsg); rtattr->rta_type = IFA_LOCAL; Index: netlink_socket.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/netlink_socket.cc,v retrieving revision 1.30 diff -u -p -r1.30 netlink_socket.cc --- netlink_socket.cc 25 Mar 2005 02:53:11 -0000 1.30 +++ netlink_socket.cc 8 May 2005 19:21:32 -0000 @@ -185,8 +185,9 @@ NetlinkSocket::start(int af, string& err } if (snl_len != sizeof(snl)) { error_msg = c_format("Wrong address length of AF_NETLINK socket: " - "%d instead of %d", - snl_len, sizeof(snl)); + "%u instead of %u", + XORP_UINT_CAST(snl_len), + XORP_UINT_CAST(sizeof(snl))); close(_fd); _fd = -1; return (XORP_ERROR); @@ -203,8 +204,9 @@ NetlinkSocket::start(int af, string& err // XXX: 'nl_pid' is supposed to be defined as 'pid_t' if ( (pid_t)snl.nl_pid != pid()) { error_msg = c_format("Wrong nl_pid of AF_NETLINK socket: " - "%d instead of %d", - snl.nl_pid, pid()); + "%u instead of %u", + XORP_UINT_CAST(snl.nl_pid), + XORP_UINT_CAST(pid())); close(_fd); _fd = -1; return (XORP_ERROR); @@ -293,7 +295,8 @@ NetlinkSocket::force_read(string& error_ "message truncated: " "received %d bytes instead of (at least) %u " "bytes", - got, XORP_UINT_CAST(sizeof(struct nlmsghdr))); + XORP_INT_CAST(got), + XORP_UINT_CAST(sizeof(struct nlmsghdr))); return (XORP_ERROR); } @@ -369,7 +372,8 @@ NetlinkSocket::force_recvfrom(int flags, "message truncated: " "received %d bytes instead of (at least) %u " "bytes", - got, XORP_UINT_CAST(sizeof(struct nlmsghdr))); + XORP_INT_CAST(got), + XORP_UINT_CAST(sizeof(struct nlmsghdr))); return (XORP_ERROR); } @@ -459,8 +463,9 @@ NetlinkSocket::force_recvmsg(int flags, } if (msg.msg_namelen != sizeof(snl)) { error_msg = c_format("Netlink socket recvmsg error: " - "sender address length %d instead of %u ", - msg.msg_namelen, sizeof(snl)); + "sender address length %d instead of %u", + XORP_INT_CAST(msg.msg_namelen), + XORP_UINT_CAST(sizeof(snl))); return (XORP_ERROR); } message.resize(message.size() + got); @@ -472,7 +477,8 @@ NetlinkSocket::force_recvmsg(int flags, "message truncated: " "received %d bytes instead of (at least) %u " "bytes", - got, XORP_UINT_CAST(sizeof(struct nlmsghdr))); + XORP_INT_CAST(got), + XORP_UINT_CAST(sizeof(struct nlmsghdr))); return (XORP_ERROR); } Index: netlink_socket_utils.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/netlink_socket_utils.cc,v retrieving revision 1.23 diff -u -p -r1.23 netlink_socket_utils.cc --- netlink_socket_utils.cc 25 Mar 2005 02:53:11 -0000 1.23 +++ netlink_socket_utils.cc 8 May 2005 19:21:32 -0000 @@ -382,9 +382,9 @@ NlmUtils::check_netlink_request(NetlinkS break; default: - debug_msg("Unhandled type %s(%d) (%d bytes)\n", + debug_msg("Unhandled type %s(%d) (%u bytes)\n", NlmUtils::nlm_msg_type(nlh->nlmsg_type).c_str(), - nlh->nlmsg_type, nlh->nlmsg_len); + nlh->nlmsg_type, XORP_UINT_CAST(nlh->nlmsg_len)); break; } } ----Next_Part(Sun_May__8_12:30:33_2005_809)---- From gernot.schmied@chello.at Sun May 8 21:55:37 2005 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sun, 08 May 2005 22:55:37 +0200 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 In-Reply-To: <20050508123052D.pavlin@icir.org> References: <427D35B9.1080402@chello.at> <20050508123052D.pavlin@icir.org> Message-ID: <427E7CC9.2070408@chello.at> pavlin@icir.org wrote: >>XORP-1.1 fails to compile on AMD64 Gentoo. Any idea? >> >>make[3]: Entering directory `/usr/local/src/Routing/xorp-1.1/fea' >>source='fticonfig_entry_get_netlink.cc' >>object='fticonfig_entry_get_netlink.lo' libtool=yes \ >>depfile='.deps/fticonfig_entry_get_netlink.Plo' >>tmpdepfile='.deps/fticonfig_entry_get_netlink.TPlo' \ >>depmode=gcc3 /bin/sh ../config/depcomp \ >>/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. >> -g -W -Wall -Wwrite-strings -Wca st-qual -Werror -Wpointer-arith >>-Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o >>fticonfig _entry_get_netlink.lo `test -f fticonfig_entry_get_netlink.cc >>|| echo './'`fticonfig_entry_get_netlink.cc >>g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings >>-Wcast-qual -Werror -Wpointer-arith -Wcas t-align -Woverloaded-virtual >>-ftemplate-depth-22 -pipe -c fticonfig_entry_get_netlink.cc -MT >>fticonfig_entr y_get_netlink.lo -MD -MP -MF >>.deps/fticonfig_entry_get_netlink.TPlo -o fticonfig_entry_get_netlink.o >>fticonfig_entry_get_netlink.cc: In member function `virtual bool >>FtiConfigEntryGetNetlink::lookup_route_by_ dest(const IPvX&, FteX&)': >>fticonfig_entry_get_netlink.cc:317: warning: int format, different type >>arg (arg 4) >>make[3]: *** [fticonfig_entry_get_netlink.lo] Error 1 >>make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' >>make[2]: *** [all-recursive] Error 1 >>make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' >>make: *** [all] Error 2 > > > Sigh, this is a casting error. Below is a patch (committed to CVS) > that should fix the problem. Note that it fixes similar problems in > other places as well, but without access to an AMD64 Linux box I > cannot guarantee there aren't other similar compilation problems. > > Please let us know if there are other compilation errors. > > Thanks, > Pavlin > Thanks Pavlin, I got a bit further, nevertheless: /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o ifconfig_parse_nlm.lo `test -f ifconfig_parse_nlm.cc || echo './'`ifconfig_parse_nlm.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c ifconfig_parse_nlm.cc -MT ifconfig_parse_nlm.lo -MD -MP -MF .deps/ifconfig_parse_nlm.TPlo -o ifconfig_parse_nlm.o ifconfig_parse_nlm.cc: In function `void nlm_newdeladdr_to_fea_cfg(IfConfig&, IfTree&, const ifaddrmsg*, int, bool)': ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 4) ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 5) ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 4) ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 5) ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 4) ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 5) make[3]: *** [ifconfig_parse_nlm.lo] Error 1 make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' make: *** [all] Error 2 Unfortunately I can only assist with debugging and testing, I am not a programmer. Regards, Gernot From pavlin@icir.org Sun May 8 22:09:37 2005 From: pavlin@icir.org (pavlin@icir.org) Date: Sun, 08 May 2005 14:09:37 -0700 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 In-Reply-To: <427E7CC9.2070408@chello.at> References: <427D35B9.1080402@chello.at> <20050508123052D.pavlin@icir.org> <427E7CC9.2070408@chello.at> Message-ID: <20050508140937G.pavlin@icir.org> ----Next_Part(Sun_May__8_14:09:05_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I got a bit further, nevertheless: > > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o > ifconfig_parse_nlm.lo `test -f ifconfig_parse_nlm.cc || echo > './'`ifconfig_parse_nlm.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-22 -pipe -c ifconfig_parse_nlm.cc -MT > ifconfig_parse_nlm.lo -MD -MP -MF .deps/ifconfig_parse_nlm.TPlo -o > ifconfig_parse_nlm.o > ifconfig_parse_nlm.cc: In function `void > nlm_newdeladdr_to_fea_cfg(IfConfig&, IfTree&, const ifaddrmsg*, int, bool)': > ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 4) > ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 5) > ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 4) > ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 5) > ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 4) > ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 5) > make[3]: *** [ifconfig_parse_nlm.lo] Error 1 > make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' > make: *** [all] Error 2 Patch included below. Thanks, Pavlin ----Next_Part(Sun_May__8_14:09:05_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux_amd64.patch2" Index: ifconfig_parse_nlm.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/ifconfig_parse_nlm.cc,v retrieving revision 1.17 diff -u -p -r1.17 ifconfig_parse_nlm.cc --- ifconfig_parse_nlm.cc 25 Mar 2005 02:53:07 -0000 1.17 +++ ifconfig_parse_nlm.cc 8 May 2005 21:08:28 -0000 @@ -247,7 +247,7 @@ nlm_newlink_to_fea_cfg(IfConfig& ifc, If if (is_newlink || (mtu != fi.mtu())) fi.set_mtu(mtu); } - debug_msg("MTU: %d\n", fi.mtu()); + debug_msg("MTU: %u\n", fi.mtu()); // // Get the flags @@ -459,9 +459,9 @@ nlm_newdeladdr_to_fea_cfg(IfConfig& ifc, const uint8_t* data = reinterpret_cast(RTA_DATA(const_cast(rta_array[IFA_LOCAL]))); if (RTA_PAYLOAD(rta_array[IFA_LOCAL]) != IPvX::addr_size(family)) { XLOG_FATAL("Invalid IFA_LOCAL address size payload: " - "received %d expected %d", - RTA_PAYLOAD(rta_array[IFA_LOCAL]), - IPvX::addr_size(family)); + "received %d expected %u", + XORP_INT_CAST(RTA_PAYLOAD(rta_array[IFA_LOCAL])), + XORP_UINT_CAST(IPvX::addr_size(family))); } lcl_addr.copy_in(family, data); } @@ -481,9 +481,9 @@ nlm_newdeladdr_to_fea_cfg(IfConfig& ifc, if (RTA_PAYLOAD(rta_array[IFA_BROADCAST]) != IPvX::addr_size(family)) { XLOG_FATAL("Invalid IFA_BROADCAST address size payload: " - "received %d expected %d", - RTA_PAYLOAD(rta_array[IFA_BROADCAST]), - IPvX::addr_size(family)); + "received %d expected %u", + XORP_INT_CAST(RTA_PAYLOAD(rta_array[IFA_BROADCAST])), + XORP_UINT_CAST(IPvX::addr_size(family))); } broadcast_addr.copy_in(family, data); has_broadcast_addr = true; @@ -508,9 +508,9 @@ nlm_newdeladdr_to_fea_cfg(IfConfig& ifc, if (RTA_PAYLOAD(rta_array[IFA_ADDRESS]) != IPvX::addr_size(family)) { XLOG_FATAL("Invalid IFA_ADDRESS address size payload: " - "received %d expected %d", - RTA_PAYLOAD(rta_array[IFA_ADDRESS]), - IPvX::addr_size(family)); + "received %d expected %u", + XORP_INT_CAST(RTA_PAYLOAD(rta_array[IFA_ADDRESS])), + XORP_UINT_CAST(IPvX::addr_size(family))); } peer_addr.copy_in(family, data); has_peer_addr = true; ----Next_Part(Sun_May__8_14:09:05_2005_809)---- From gernot.schmied@chello.at Sun May 8 23:04:59 2005 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Mon, 09 May 2005 00:04:59 +0200 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 In-Reply-To: <20050508140937G.pavlin@icir.org> References: <427D35B9.1080402@chello.at> <20050508123052D.pavlin@icir.org> <427E7CC9.2070408@chello.at> <20050508140937G.pavlin@icir.org> Message-ID: <427E8D0B.2080006@chello.at> pavlin@icir.org wrote: >>I got a bit further, nevertheless: >> >>/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. >> -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith >>-Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o >>ifconfig_parse_nlm.lo `test -f ifconfig_parse_nlm.cc || echo >>'./'`ifconfig_parse_nlm.cc >>g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings >>-Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual >>-ftemplate-depth-22 -pipe -c ifconfig_parse_nlm.cc -MT >>ifconfig_parse_nlm.lo -MD -MP -MF .deps/ifconfig_parse_nlm.TPlo -o >>ifconfig_parse_nlm.o >>ifconfig_parse_nlm.cc: In function `void >>nlm_newdeladdr_to_fea_cfg(IfConfig&, IfTree&, const ifaddrmsg*, int, bool)': >>ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 4) >>ifconfig_parse_nlm.cc:461: warning: int format, different type arg (arg 5) >>ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 4) >>ifconfig_parse_nlm.cc:483: warning: int format, different type arg (arg 5) >>ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 4) >>ifconfig_parse_nlm.cc:510: warning: int format, different type arg (arg 5) >>make[3]: *** [ifconfig_parse_nlm.lo] Error 1 >>make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' >>make[2]: *** [all-recursive] Error 1 >>make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' >>make[1]: *** [all-recursive] Error 1 >>make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' >>make: *** [all] Error 2 > > > Patch included below. > > Thanks, > Pavlin Thanks, getting closer ;-). make[3]: Entering directory `/usr/local/src/Routing/xorp-1.1/fea' source='mfea_proto_comm.cc' object='mfea_proto_comm.lo' libtool=yes \ depfile='.deps/mfea_proto_comm.Plo' tmpdepfile='.deps/mfea_proto_comm.TPlo' \ depmode=gcc3 /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o mfea_proto_comm.lo `test -f mfea_proto_comm.cc || echo './'`mfea_proto_comm.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c mfea_proto_comm.cc -MT mfea_proto_comm.lo -MD -MP -MF .deps/mfea_proto_comm.TPlo -o mfea_proto_comm.o mfea_proto_comm.cc: In member function `void ProtoComm::proto_socket_read(int, SelectorMask)': mfea_proto_comm.cc:1048: warning: int format, different type arg (arg 4) make[3]: *** [mfea_proto_comm.lo] Error 1 make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' make: *** [all] Error 2 Regards, Gernot From pavlin@icir.org Mon May 9 00:58:24 2005 From: pavlin@icir.org (pavlin@icir.org) Date: Sun, 08 May 2005 16:58:24 -0700 Subject: [Xorp-users] xorp-1.1 build failure on Gentoo AMD64 In-Reply-To: <427E8D0B.2080006@chello.at> References: <427E7CC9.2070408@chello.at> <20050508140937G.pavlin@icir.org> <427E8D0B.2080006@chello.at> Message-ID: <20050508165824W.pavlin@icir.org> ----Next_Part(Sun_May__8_16:58:14_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > make[3]: Entering directory `/usr/local/src/Routing/xorp-1.1/fea' > source='mfea_proto_comm.cc' object='mfea_proto_comm.lo' libtool=yes \ > depfile='.deps/mfea_proto_comm.Plo' > tmpdepfile='.deps/mfea_proto_comm.TPlo' \ > depmode=gcc3 /bin/sh ../config/depcomp \ > /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. > -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith > -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -c -o > mfea_proto_comm.lo `test -f mfea_proto_comm.cc || echo > './'`mfea_proto_comm.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings > -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual > -ftemplate-depth-22 -pipe -c mfea_proto_comm.cc -MT mfea_proto_comm.lo > -MD -MP -MF .deps/mfea_proto_comm.TPlo -o mfea_proto_comm.o > mfea_proto_comm.cc: In member function `void > ProtoComm::proto_socket_read(int, SelectorMask)': > mfea_proto_comm.cc:1048: warning: int format, different type arg (arg 4) > make[3]: *** [mfea_proto_comm.lo] Error 1 > make[3]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/src/Routing/xorp-1.1/fea' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/Routing/xorp-1.1' > make: *** [all] Error 2 Below is the next patch. I guess there may be a number of problems like this, so I'd recommend that we take it off the list. If anyone else is interested in those patches, please let me know and I will send them later when all instances are fixed. Thanks, Pavlin ----Next_Part(Sun_May__8_16:58:14_2005_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux_amd64.patch3" Index: mfea_proto_comm.cc =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/fea/mfea_proto_comm.cc,v retrieving revision 1.30 diff -u -p -r1.30 mfea_proto_comm.cc --- mfea_proto_comm.cc 30 Apr 2005 21:59:57 -0000 1.30 +++ mfea_proto_comm.cc 8 May 2005 23:57:32 -0000 @@ -1047,7 +1047,7 @@ ProtoComm::proto_socket_read(int fd, Sel if (nbytes < (ssize_t)sizeof(struct icmp6_hdr)) { XLOG_WARNING("proto_socket_read() failed: " "packet size %d is smaller than minimum size %u", - nbytes, + XORP_INT_CAST(nbytes), XORP_UINT_CAST(sizeof(struct icmp6_hdr))); return; // Error } ----Next_Part(Sun_May__8_16:58:14_2005_809)---- From mehdi.bensaid@rd.francetelecom.com Mon May 9 13:07:09 2005 From: mehdi.bensaid@rd.francetelecom.com (zze-BEN SAID Mehdi RD-CORE-ISS) Date: Mon, 9 May 2005 14:07:09 +0200 Subject: [Xorp-users] Erreur Message-ID: <3418F3471F1CA4409901547349FFAE2E03C3F4BF@FTRDMEL2.rd.francetelecom.fr> I had this displayed on my xorp_rtrmgr debug window, when trying to chage the configuration via an indirect script: [ 2005/05/09 14:03:18 ERROR xorp_rtrmgr:3578 RTRMGR +569 xrl_rtrmgr_interface.cc client_updated ] Failed to notify client that config changed: Transport failed What's the 3578 error? Does anybody have a possible interpretation of this? From atanu@ICSI.Berkeley.EDU Mon May 9 18:07:39 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 09 May 2005 10:07:39 -0700 Subject: [Xorp-users] Erreur In-Reply-To: Message from "zze-BEN SAID Mehdi RD-CORE-ISS" of "Mon, 09 May 2005 14:07:09 +0200." <3418F3471F1CA4409901547349FFAE2E03C3F4BF@FTRDMEL2.rd.francetelecom.fr> Message-ID: <6517.1115658459@tigger.icir.org> The number after the process name is its process id, not an error number. Atanu. >>>>> "zze-BEN" == zze-BEN SAID Mehdi > writes: zze-BEN> I had this displayed on my xorp_rtrmgr debug window, when zze-BEN> trying to chage the configuration via an indirect script: [ zze-BEN> 2005/05/09 14:03:18 ERROR xorp_rtrmgr:3578 RTRMGR +569 zze-BEN> xrl_rtrmgr_interface.cc client_updated ] Failed to notify zze-BEN> client that config changed: Transport failed What's the zze-BEN> 3578 error? Does anybody have a possible interpretation of zze-BEN> this? zze-BEN> _______________________________________________ Xorp-users zze-BEN> mailing list Xorp-users@xorp.org zze-BEN> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jer_log@hotmail.com Tue May 10 17:27:22 2005 From: jer_log@hotmail.com (jer log) Date: Tue, 10 May 2005 16:27:22 +0000 Subject: [Xorp-users] using XORP (bgp) to test third party router Message-ID: Hi, I am (a newbie) trying to use the bgp harness test suite of XORP to test a third party router. Has this been done? What are the processes i need to run to achieve this? I have been able to compile xorp in a redhat linux. If i just modify bgp/harness/test1.sh it just stops at coord reset. I guess i must start the coordinator process... Thanks for your help -Jer _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From pavlin@icir.org Tue May 10 22:30:58 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 10 May 2005 14:30:58 -0700 Subject: [Xorp-users] RTT "Round Trip Time" In-Reply-To: Message from TTA Group of "Sun, 08 May 2005 01:28:49 PDT." <9fa8f1af0505080128130f72db@mail.gmail.com> Message-ID: <200505102131.j4ALV3i5012391@possum.icir.org> > I'm a graduate student and my graduate project about "Round Trip Time" > as router matrix. So I think to use XORP as my research environment. > But I notice that the default xorp RIP matrix is "Hob Count". So does > any one has any idea how I can make it RTT "Round trip time"? any help > or suggestions in this subject or previous experience? Tariq, The RIP protocol itself is designed to use hop-count, so it is not clear whether it can easily be modified to use RTT instead of hop-count. It may be simpler to design your own routing protocol that uses RTT instead of modifing RIP, but you should be the one to research that option :) Once you have designed your routing protocol, then you can decide whether you can reuse some of the RIP code. If you want to implement your protocol from scratch, then you can use the static_routes implementation as a starting point. Good luck! Atanu & Pavlin From jer_log@hotmail.com Wed May 11 01:02:27 2005 From: jer_log@hotmail.com (jer log) Date: Wed, 11 May 2005 00:02:27 +0000 Subject: [Xorp-users] using XORP (bgp) to test third party router In-Reply-To: Message-ID: Folks, I have since got some peering (bgp test harness) with a third party router going... But i have problems in specifying multiple peers. Specifically the router requires these peers to come from multiple ip addresses. How do i specify a test peer's ip address? I am assuming configure_bgp() {} routine configures the peers in XORP. Thanks, -Jer So how do i specify the peer programs to >From: "jer log" >To: xorp-users@xorp.org >Subject: [Xorp-users] using XORP (bgp) to test third party router >Date: Tue, 10 May 2005 16:27:22 +0000 > >Hi, > I am (a newbie) trying to use the bgp harness test suite of XORP to test > a third party router. > Has this been done? > What are the processes i need to run to achieve this? > I have been able to compile xorp in a redhat linux. > > If i just modify bgp/harness/test1.sh it just stops at coord reset. > I guess i must start the coordinator process... > > Thanks for your help >-Jer > >_________________________________________________________________ >Express yourself instantly with MSN Messenger! Download today - it's FREE! >http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From atanu@ICSI.Berkeley.EDU Wed May 11 03:09:46 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 10 May 2005 19:09:46 -0700 Subject: [Xorp-users] using XORP (bgp) to test third party router In-Reply-To: Message from "jer log" of "Wed, 11 May 2005 00:02:27 -0000." Message-ID: <37116.1115777386@tigger.icir.org> The bgp test harness was written with the intent of being able to test third party BGP implementations: . We have never tried using the tests against a third party BGP. So some dependencies on our BGP may have crept in. I would experiment with the set of scripts that we use daily in our regression runs, they are in Makefile.am: test_peering1.sh test_peering2.sh test_routing1.sh test_routing2.sh test_rib1.sh test_rib_fea1.sh test_path_attribute1.sh test_terminate.sh A typical BGP will create a single session with a peer. More than one session to a peer is clearly a protocol violation. We wanted to be able to run our BGP regression tests from a Makefile so we modified our BGP to accept connections on any port not just 179. For testing third party implementations we need to run each test_peer on a separate host (or address). The test harness has two components a coordinating process and a number of test_peers. The test_peers are designed to run on separate hosts although we run them on the same host. Taking test_routing1.sh as an example the top of the file describes which process need to be started, clearly when testing a third party BGP there is no need to start the XORP processes. We need to start a finder process a coordinating process and and three test_peers. All the port numbers in script need to be changed to port 179 (PORT? and PEER?_PORT). Choose three separate hosts on which to run the test peers. Configure you BGP to accept connections from this these hosts. Set the HOST variable to the IP address of your BGP router. The finder process for security reasons will only accept connections on localhost. It will need to be started with the "-n" with the network that the test_peers are on and "-i" with the interface address that it should listen on. Then start a test peer on each host with the "-h" flag, with the IP address of the finder host. Each test peer will also require a unique name provided with the "-s" flag, (peer1, peer2 and peer3). For simplicity run the test_routing1.sh script on the same host that you run the coordinator and finder process. Now run a test: $ ./test_routing1.sh -s -t test1 The configure_bgp does indeed configure the XORP bgp. There is no way to set the test peer's IP address interesting omission on my part. The test_peer is provided with the targets IP address and port. In our tests the target is always localhost so the source address selected by the system is always localhost. When running the test_peers on separate hosts again the source IP address will be selected by the operating system. I have noticed a number of problems in the test scripts while trying to compose this email. The most irritating is that I have overloaded the configuration on some peerings. For example in test_routing1.sh I use the same peerings for IPv4 and IPv6 tests. Your won't be able to run the IPv4 and IPv6 tests with the same router configuration. This also means that you can't allow the script to run all the tests, each one will need to be run individually. I hope this helps. In retrospect using the the shell as the scripting language was a mistake. We will be rewriting the tests in python during the summer and hopefully make the scripts more amenable to testing third party BGP implementations. Checkout harness.py and lookup.py. Sorry for the slow response we had a power failure in our machine room today and lost both power supplies on our mail server. Atanu. >>>>> "jer" == jer log writes: jer> Folks, I have since got some peering (bgp test harness) with a jer> third party router going... But i have problems in specifying jer> multiple peers. Specifically the router requires these peers jer> to come from multiple ip addresses. jer> How do i specify a test peer's ip address? I am assuming jer> configure_bgp() {} routine configures the peers in XORP. jer> Thanks, -Jer jer> So how do i specify the peer programs to From: "jer log" jer> >> To: xorp-users@xorp.org Subject: [Xorp-users] using XORP (bgp) to >> test third party router Date: Tue, 10 May 2005 16:27:22 +0000 >> >> Hi, I am (a newbie) trying to use the bgp harness test suite of >> XORP to test a third party router. Has this been done? What are >> the processes i need to run to achieve this? I have been able to >> compile xorp in a redhat linux. >> >> If i just modify bgp/harness/test1.sh it just stops at coord >> reset. I guess i must start the coordinator process... >> >> Thanks for your help -Jer >> >> _________________________________________________________________ >> Express yourself instantly with MSN Messenger! Download today - >> it's FREE! >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> _______________________________________________ Xorp-users >> mailing list Xorp-users@xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users jer> _________________________________________________________________ jer> Express yourself instantly with MSN Messenger! Download today - jer> it's FREE! jer> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ jer> _______________________________________________ Xorp-users jer> mailing list Xorp-users@xorp.org jer> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jer_log@hotmail.com Wed May 11 04:12:31 2005 From: jer_log@hotmail.com (jer log) Date: Wed, 11 May 2005 03:12:31 +0000 Subject: [Xorp-users] using XORP (bgp) to test third party router In-Reply-To: <37116.1115777386@tigger.icir.org> Message-ID: Thank you so much for that response. Multiple hosts is not really a option for me. I have since tried adding a '-b' and '-p' option to specify a local bind address/port (to enforce the source address/port during connect) options to test_peer.cc under bgp/harness The idea is to run each peer with testpeer -b -p The 'Third Party' router has an option to specify the destination TCP port to connect to (does not have to be 179, thankfully) But when i make this change, i get " "Operation in coordinator still pending try number: 1... and fail" BTW, i really think the test script can become a great third party BGP test tool. with all the extensible functionality to send arbitrary update and expect statements. (reminds me of Qarobot from Qosnetics) Thanks for your help. -jer >From: Atanu Ghosh >Reply-To: atanu@ICSI.Berkeley.EDU >To: "jer log" >CC: xorp-users@xorp.org >Subject: Re: [Xorp-users] using XORP (bgp) to test third party router Date: >Tue, 10 May 2005 19:09:46 -0700 > >The bgp test harness was written with the intent of being able to test >third party BGP implementations: >. > >We have never tried using the tests against a third party BGP. So >some dependencies on our BGP may have crept in. > >I would experiment with the set of scripts that we use daily in our >regression runs, they are in Makefile.am: > >test_peering1.sh >test_peering2.sh >test_routing1.sh >test_routing2.sh >test_rib1.sh >test_rib_fea1.sh >test_path_attribute1.sh >test_terminate.sh > >A typical BGP will create a single session with a peer. More than one >session to a peer is clearly a protocol violation. We wanted to be able >to run our BGP regression tests from a Makefile so we modified our BGP >to accept connections on any port not just 179. For testing third party >implementations we need to run each test_peer on a separate host (or >address). > >The test harness has two components a coordinating process and a number >of test_peers. The test_peers are designed to run on separate hosts >although we run them on the same host. > >Taking test_routing1.sh as an example the top of the file describes >which process need to be started, clearly when testing a third party BGP >there is no need to start the XORP processes. We need to start a finder >process a coordinating process and and three test_peers. All the port >numbers in script need to be changed to port 179 (PORT? and >PEER?_PORT). Choose three separate hosts on which to run the test >peers. Configure you BGP to accept connections from this these >hosts. Set the HOST variable to the IP address of your BGP router. > >The finder process for security reasons will only accept connections on >localhost. It will need to be started with the "-n" with the network >that the test_peers are on and "-i" with the interface address that it >should listen on. Then start a test peer on each host with the "-h" >flag, with the IP address of the finder host. Each test peer will also >require a unique name provided with the "-s" flag, (peer1, peer2 and >peer3). > >For simplicity run the test_routing1.sh script on the same host that you >run the coordinator and finder process. > >Now run a test: >$ ./test_routing1.sh -s -t test1 > >The configure_bgp does indeed configure the XORP bgp. > >There is no way to set the test peer's IP address interesting omission >on my part. The test_peer is provided with the targets IP address and >port. In our tests the target is always localhost so the source address >selected by the system is always localhost. When running the test_peers >on separate hosts again the source IP address will be selected by the >operating system. > >I have noticed a number of problems in the test scripts while trying to >compose this email. The most irritating is that I have overloaded the >configuration on some peerings. For example in test_routing1.sh I use >the same peerings for IPv4 and IPv6 tests. Your won't be able to run the >IPv4 and IPv6 tests with the same router configuration. This also means >that you can't allow the script to run all the tests, each one will need >to be run individually. > >I hope this helps. > >In retrospect using the the shell as the scripting language was a >mistake. We will be rewriting the tests in python during the summer and >hopefully make the scripts more amenable to testing third party BGP >implementations. Checkout harness.py and lookup.py. > >Sorry for the slow response we had a power failure in our machine room >today and lost both power supplies on our mail server. > > Atanu. > > > >>>>> "jer" == jer log writes: > > jer> Folks, I have since got some peering (bgp test harness) with a > jer> third party router going... But i have problems in specifying > jer> multiple peers. Specifically the router requires these peers > jer> to come from multiple ip addresses. > > jer> How do i specify a test peer's ip address? I am assuming > jer> configure_bgp() {} routine configures the peers in XORP. > > jer> Thanks, -Jer > > jer> So how do i specify the peer programs to From: "jer log" > jer> > >> To: xorp-users@xorp.org Subject: [Xorp-users] using XORP (bgp) to > >> test third party router Date: Tue, 10 May 2005 16:27:22 +0000 > >> > >> Hi, I am (a newbie) trying to use the bgp harness test suite of > >> XORP to test a third party router. Has this been done? What are > >> the processes i need to run to achieve this? I have been able to > >> compile xorp in a redhat linux. > >> > >> If i just modify bgp/harness/test1.sh it just stops at coord > >> reset. I guess i must start the coordinator process... > >> > >> Thanks for your help -Jer > >> > >> _________________________________________________________________ > >> Express yourself instantly with MSN Messenger! Download today - > >> it's FREE! > >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > >> _______________________________________________ Xorp-users > >> mailing list Xorp-users@xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > jer> _________________________________________________________________ > jer> Express yourself instantly with MSN Messenger! Download today - > jer> it's FREE! > jer> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > jer> _______________________________________________ Xorp-users > jer> mailing list Xorp-users@xorp.org > jer> 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 _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From atanu@ICSI.Berkeley.EDU Wed May 11 04:38:42 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 10 May 2005 20:38:42 -0700 Subject: [Xorp-users] using XORP (bgp) to test third party router In-Reply-To: Message from "jer log" of "Wed, 11 May 2005 03:12:31 -0000." Message-ID: <59341.1115782722@tigger.icir.org> I think the failure that you are reporting happens when the test_peer fails to connect with the BGP process. Try running the test_peer with the "-t" and "-v" flags. You should see something like this: reset() register(coord,0) packetisation(bgp) connect(localhost,10001) The connect line should contain the address and port that your BGP router is listening on. Atanu. >>>>> "jer" == jer log writes: jer> Thank you so much for that response. Multiple hosts is not jer> really a option for me. jer> I have since tried adding a '-b' and '-p' option to specify a jer> local bind address/port (to enforce the source address/port jer> during connect) options to test_peer.cc under bgp/harness jer> The idea is to run each peer with testpeer -b -p jer> The 'Third Party' router has an option to specify the jer> destination TCP port to connect to (does not have to be 179, jer> thankfully) jer> But when i make this change, i get " "Operation in coordinator jer> still pending try number: 1... and fail" jer> BTW, i really think the test script can become a great third jer> party BGP test tool. with all the extensible functionality to jer> send arbitrary update and expect statements. (reminds me of jer> Qarobot from Qosnetics) jer> Thanks for your help. -jer jer> From: Atanu Ghosh >> Reply-To: atanu@ICSI.Berkeley.EDU To: "jer log" >> CC: xorp-users@xorp.org Subject: Re: >> [Xorp-users] using XORP (bgp) to test third party router Date: >> Tue, 10 May 2005 19:09:46 -0700 >> >> The bgp test harness was written with the intent of being able to >> test third party BGP implementations: >> . >> >> We have never tried using the tests against a third party BGP. So >> some dependencies on our BGP may have crept in. >> >> I would experiment with the set of scripts that we use daily in >> our regression runs, they are in Makefile.am: >> >> test_peering1.sh test_peering2.sh test_routing1.sh >> test_routing2.sh test_rib1.sh test_rib_fea1.sh >> test_path_attribute1.sh test_terminate.sh >> >> A typical BGP will create a single session with a peer. More than >> one session to a peer is clearly a protocol violation. We wanted >> to be able to run our BGP regression tests from a Makefile so we >> modified our BGP to accept connections on any port not just >> 179. For testing third party implementations we need to run each >> test_peer on a separate host (or address). >> >> The test harness has two components a coordinating process and a >> number of test_peers. The test_peers are designed to run on >> separate hosts although we run them on the same host. >> >> Taking test_routing1.sh as an example the top of the file >> describes which process need to be started, clearly when testing >> a third party BGP there is no need to start the XORP >> processes. We need to start a finder process a coordinating >> process and and three test_peers. All the port numbers in script >> need to be changed to port 179 (PORT? and PEER?_PORT). Choose >> three separate hosts on which to run the test peers. Configure >> you BGP to accept connections from this these hosts. Set the HOST >> variable to the IP address of your BGP router. >> >> The finder process for security reasons will only accept >> connections on localhost. It will need to be started with the >> "-n" with the network that the test_peers are on and "-i" with >> the interface address that it should listen on. Then start a test >> peer on each host with the "-h" flag, with the IP address of the >> finder host. Each test peer will also require a unique name >> provided with the "-s" flag, (peer1, peer2 and peer3). >> >> For simplicity run the test_routing1.sh script on the same host >> that you run the coordinator and finder process. >> >> Now run a test: $ ./test_routing1.sh -s -t test1 >> >> The configure_bgp does indeed configure the XORP bgp. >> >> There is no way to set the test peer's IP address interesting >> omission on my part. The test_peer is provided with the targets >> IP address and port. In our tests the target is always localhost >> so the source address selected by the system is always >> localhost. When running the test_peers on separate hosts again >> the source IP address will be selected by the operating system. >> >> I have noticed a number of problems in the test scripts while >> trying to compose this email. The most irritating is that I have >> overloaded the configuration on some peerings. For example in >> test_routing1.sh I use the same peerings for IPv4 and IPv6 >> tests. Your won't be able to run the IPv4 and IPv6 tests with the >> same router configuration. This also means that you can't allow >> the script to run all the tests, each one will need to be run >> individually. >> >> I hope this helps. >> >> In retrospect using the the shell as the scripting language was a >> mistake. We will be rewriting the tests in python during the >> summer and hopefully make the scripts more amenable to testing >> third party BGP implementations. Checkout harness.py and >> lookup.py. >> >> Sorry for the slow response we had a power failure in our machine >> room today and lost both power supplies on our mail server. >> >> Atanu. >> >> >> >>>>> "jer" == jer log writes: >> jer> Folks, I have since got some peering (bgp test harness) with a jer> third party router going... But i have problems in specifying jer> multiple peers. Specifically the router requires these peers jer> to come from multiple ip addresses. >> jer> How do i specify a test peer's ip address? I am assuming jer> configure_bgp() {} routine configures the peers in XORP. >> jer> Thanks, -Jer >> jer> So how do i specify the peer programs to From: "jer log" jer> >> >> To: xorp-users@xorp.org Subject: [Xorp-users] using XORP (bgp) >> to >> test third party router Date: Tue, 10 May 2005 16:27:22 >> +0000 >> >> >> >> Hi, I am (a newbie) trying to use the bgp harness test suite >> of >> XORP to test a third party router. Has this been done? >> What are >> the processes i need to run to achieve this? I have >> been able to >> compile xorp in a redhat linux. >> >> >> >> If i just modify bgp/harness/test1.sh it just stops at coord >> >> reset. I guess i must start the coordinator process... >> >> >> >> Thanks for your help -Jer >> >> >> >> >> _________________________________________________________________ >> >> Express yourself instantly with MSN Messenger! Download today >> - >> it's FREE! >> >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >> _______________________________________________ Xorp-users >> >> mailing list Xorp-users@xorp.org >> >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> jer> _________________________________________________________________ jer> Express yourself instantly with MSN Messenger! Download today - jer> it's FREE! jer> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> jer> _______________________________________________ Xorp-users jer> mailing list Xorp-users@xorp.org jer> 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 jer> _________________________________________________________________ jer> Don’t just search. Find. Check out the new MSN Search! jer> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dikshie@lapi.itb.ac.id Wed May 11 11:30:30 2005 From: dikshie@lapi.itb.ac.id (Dikshie) Date: Wed, 11 May 2005 17:30:30 +0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect Message-ID: <20050511103030.GA43691@lapi.itb.ac.id> I've just cvs-ed today, using same config.boot, run xorp_rtmgr and then I got: ------ ipv6# /usr/local/xorp/bin/xorp_rtrmgr [ 2005/05/11 17:17:32 ERROR xorp_rtrmgr:89197 FINDER +374 finder_tcp_messenger.cc do_auto_connect ] Failed to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:33 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:34 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:35 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:36 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:37 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:38 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:39 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:40 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/11 17:17:41 ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress ------ the OS is FreeBSD-5.4-STABLE any clue or solution ? with best regards, -dikshie- From gernot.schmied@chello.at Wed May 11 14:21:55 2005 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Wed, 11 May 2005 15:21:55 +0200 Subject: [Xorp-users] RTT "Round Trip Time" In-Reply-To: <200505102131.j4ALV3i5012391@possum.icir.org> References: <200505102131.j4ALV3i5012391@possum.icir.org> Message-ID: <428206F3.8060506@chello.at> Pavlin Radoslavov wrote: >>I'm a graduate student and my graduate project about "Round Trip Time" >>as router matrix. So I think to use XORP as my research environment. >>But I notice that the default xorp RIP matrix is "Hob Count". So does >>any one has any idea how I can make it RTT "Round trip time"? any help >>or suggestions in this subject or previous experience? > > > Tariq, > > The RIP protocol itself is designed to use hop-count, so it is not > clear whether it can easily be modified to use RTT instead of > hop-count. It may be simpler to design your own routing protocol > that uses RTT instead of modifing RIP, but you should be the one to > research that option :) > > Once you have designed your routing protocol, then you can decide > whether you can reuse some of the RIP code. > If you want to implement your protocol from scratch, then you can > use the static_routes implementation as a starting point. > > Good luck! > Atanu & Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > Designing a routing protocol around a volatile, largely varying and intrinsically unpredictable metric such as RTT is a difficult task and generally not a good idea in a best-effort IP network. I'd rather suggest you take an existing routing protocol such as OSPF or EIGRp and consider implementing the generic "cost" hook based on consolidated RTT data instead of bandwidth, hop-count or something else. Anyway, you have to consider the return-path as well so that would defeat the purpose. For a start you could also look at the EIGRP hybrid metric approach. Regards, Gernot From bms@spc.org Wed May 11 15:07:36 2005 From: bms@spc.org (Bruce M Simpson) Date: Wed, 11 May 2005 15:07:36 +0100 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: <20050511103030.GA43691@lapi.itb.ac.id> References: <20050511103030.GA43691@lapi.itb.ac.id> Message-ID: <20050511140736.GB798@empiric.icir.org> On Wed, May 11, 2005 at 05:30:30PM +0700, Dikshie wrote: > I've just cvs-ed today, using same config.boot, run xorp_rtmgr and then I got: Known issue. I think this has now been fixed in CVS. BMS From atanu@ICSI.Berkeley.EDU Wed May 11 15:47:09 2005 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 11 May 2005 07:47:09 -0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: Message from Bruce M Simpson of "Wed, 11 May 2005 15:07:36 BST." <20050511140736.GB798@empiric.icir.org> Message-ID: <4554.1115822829@tigger.icir.org> Bruce> On Wed, May 11, 2005 at 05:30:30PM +0700, Dikshie wrote: >> I've just cvs-ed today, using same config.boot, run xorp_rtmgr >> and then I got: Bruce> Known issue. I think this has now been fixed in CVS. You need xorp/libcomm/comm_sock.c later than revision 1.17 Atanu. From jer_log@hotmail.com Wed May 11 19:25:14 2005 From: jer_log@hotmail.com (jer log) Date: Wed, 11 May 2005 18:25:14 +0000 Subject: [Xorp-users] using XORP (bgp) to test third party router In-Reply-To: <59341.1115782722@tigger.icir.org> Message-ID: Pl. ignore the earlier message about the test case. Mea culpa. -jer >From: Atanu Ghosh >Reply-To: atanu@ICSI.Berkeley.EDU >To: "jer log" >CC: xorp-users@xorp.org >Subject: Re: [Xorp-users] using XORP (bgp) to test third party router Date: >Tue, 10 May 2005 20:38:42 -0700 > >I think the failure that you are reporting happens when the test_peer >fails to connect with the BGP process. Try running the test_peer with >the "-t" and "-v" flags. > >You should see something like this: >reset() >register(coord,0) >packetisation(bgp) >connect(localhost,10001) > >The connect line should contain the address and port that your BGP >router is listening on. > > Atanu. > > >>>>> "jer" == jer log writes: > > jer> Thank you so much for that response. Multiple hosts is not > jer> really a option for me. > > jer> I have since tried adding a '-b' and '-p' option to specify a > jer> local bind address/port (to enforce the source address/port > jer> during connect) options to test_peer.cc under bgp/harness > > jer> The idea is to run each peer with testpeer -b -p > > jer> The 'Third Party' router has an option to specify the > jer> destination TCP port to connect to (does not have to be 179, > jer> thankfully) > > jer> But when i make this change, i get " "Operation in coordinator > jer> still pending try number: 1... and fail" > > jer> BTW, i really think the test script can become a great third > jer> party BGP test tool. with all the extensible functionality to > jer> send arbitrary update and expect statements. (reminds me of > jer> Qarobot from Qosnetics) > > jer> Thanks for your help. -jer > > jer> From: Atanu Ghosh > >> Reply-To: atanu@ICSI.Berkeley.EDU To: "jer log" > >> CC: xorp-users@xorp.org Subject: Re: > >> [Xorp-users] using XORP (bgp) to test third party router Date: > >> Tue, 10 May 2005 19:09:46 -0700 > >> > >> The bgp test harness was written with the intent of being able to > >> test third party BGP implementations: > >> >. > >> > >> We have never tried using the tests against a third party BGP. So > >> some dependencies on our BGP may have crept in. > >> > >> I would experiment with the set of scripts that we use daily in > >> our regression runs, they are in Makefile.am: > >> > >> test_peering1.sh test_peering2.sh test_routing1.sh > >> test_routing2.sh test_rib1.sh test_rib_fea1.sh > >> test_path_attribute1.sh test_terminate.sh > >> > >> A typical BGP will create a single session with a peer. More than > >> one session to a peer is clearly a protocol violation. We wanted > >> to be able to run our BGP regression tests from a Makefile so we > >> modified our BGP to accept connections on any port not just > >> 179. For testing third party implementations we need to run each > >> test_peer on a separate host (or address). > >> > >> The test harness has two components a coordinating process and a > >> number of test_peers. The test_peers are designed to run on > >> separate hosts although we run them on the same host. > >> > >> Taking test_routing1.sh as an example the top of the file > >> describes which process need to be started, clearly when testing > >> a third party BGP there is no need to start the XORP > >> processes. We need to start a finder process a coordinating > >> process and and three test_peers. All the port numbers in script > >> need to be changed to port 179 (PORT? and PEER?_PORT). Choose > >> three separate hosts on which to run the test peers. Configure > >> you BGP to accept connections from this these hosts. Set the HOST > >> variable to the IP address of your BGP router. > >> > >> The finder process for security reasons will only accept > >> connections on localhost. It will need to be started with the > >> "-n" with the network that the test_peers are on and "-i" with > >> the interface address that it should listen on. Then start a test > >> peer on each host with the "-h" flag, with the IP address of the > >> finder host. Each test peer will also require a unique name > >> provided with the "-s" flag, (peer1, peer2 and peer3). > >> > >> For simplicity run the test_routing1.sh script on the same host > >> that you run the coordinator and finder process. > >> > >> Now run a test: $ ./test_routing1.sh -s -t test1 > >> > >> The configure_bgp does indeed configure the XORP bgp. > >> > >> There is no way to set the test peer's IP address interesting > >> omission on my part. The test_peer is provided with the targets > >> IP address and port. In our tests the target is always localhost > >> so the source address selected by the system is always > >> localhost. When running the test_peers on separate hosts again > >> the source IP address will be selected by the operating system. > >> > >> I have noticed a number of problems in the test scripts while > >> trying to compose this email. The most irritating is that I have > >> overloaded the configuration on some peerings. For example in > >> test_routing1.sh I use the same peerings for IPv4 and IPv6 > >> tests. Your won't be able to run the IPv4 and IPv6 tests with the > >> same router configuration. This also means that you can't allow > >> the script to run all the tests, each one will need to be run > >> individually. > >> > >> I hope this helps. > >> > >> In retrospect using the the shell as the scripting language was a > >> mistake. We will be rewriting the tests in python during the > >> summer and hopefully make the scripts more amenable to testing > >> third party BGP implementations. Checkout harness.py and > >> lookup.py. > >> > >> Sorry for the slow response we had a power failure in our machine > >> room today and lost both power supplies on our mail server. > >> > >> Atanu. > >> > >> > >> >>>>> "jer" == jer log writes: > >> > jer> Folks, I have since got some peering (bgp test harness) with a > jer> third party router going... But i have problems in specifying > jer> multiple peers. Specifically the router requires these peers > jer> to come from multiple ip addresses. > >> > jer> How do i specify a test peer's ip address? I am assuming > jer> configure_bgp() {} routine configures the peers in XORP. > >> > jer> Thanks, -Jer > >> > jer> So how do i specify the peer programs to From: "jer log" > jer> > >> >> To: xorp-users@xorp.org Subject: [Xorp-users] using XORP (bgp) > >> to >> test third party router Date: Tue, 10 May 2005 16:27:22 > >> +0000 > >> >> > >> >> Hi, I am (a newbie) trying to use the bgp harness test suite > >> of >> XORP to test a third party router. Has this been done? > >> What are >> the processes i need to run to achieve this? I have > >> been able to >> compile xorp in a redhat linux. > >> >> > >> >> If i just modify bgp/harness/test1.sh it just stops at coord > >> >> reset. I guess i must start the coordinator process... > >> >> > >> >> Thanks for your help -Jer > >> >> > >> >> > >> _________________________________________________________________ > >> >> Express yourself instantly with MSN Messenger! Download today > >> - >> it's FREE! >> > >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> >> > >> >> _______________________________________________ Xorp-users >> > >> mailing list Xorp-users@xorp.org >> > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> > jer> _________________________________________________________________ > jer> Express yourself instantly with MSN Messenger! Download today - > jer> it's FREE! > jer> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > >> > jer> _______________________________________________ Xorp-users > jer> mailing list Xorp-users@xorp.org > jer> 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 > > jer> _________________________________________________________________ > jer> Don’t just search. Find. Check out the new MSN Search! > jer> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From TTA Group Thu May 12 00:34:55 2005 From: TTA Group (TTA Group) Date: Wed, 11 May 2005 16:34:55 -0700 Subject: [Xorp-users] RTT "Round Trip Time" In-Reply-To: <428206F3.8060506@chello.at> References: <200505102131.j4ALV3i5012391@possum.icir.org> <428206F3.8060506@chello.at> Message-ID: <9fa8f1af0505111634e4d48f1@mail.gmail.com> Thank you guys for your reply I will take your advice about not playing with RIP to make it RTT(Round Trip Time). But it seems XORP does not support any of the "Cost" link protocols like OSPF or EIGRp isn't it ? So in this case, either I have to install their routing platform (like Zebra) or even change the OS and use Windows2000 for OSPF. so which choice you recommend guys? I notice that to activate OSPF in windows2000 I have to configure Routing and Remote Access service in it. and that is only available in windows 2000 server. isn't it ? do you think I can easily configure OSPF in windows to use the delay metric (close to RTT) ? Thanks for your help On 5/11/05, Gernot W. Schmied wrote: > Pavlin Radoslavov wrote: > >>I'm a graduate student and my graduate project about "Round Trip Time" > >>as router matrix. So I think to use XORP as my research environment. > >>But I notice that the default xorp RIP matrix is "Hob Count". So does > >>any one has any idea how I can make it RTT "Round trip time"? any help > >>or suggestions in this subject or previous experience? > > > > > > Tariq, > > > > The RIP protocol itself is designed to use hop-count, so it is not > > clear whether it can easily be modified to use RTT instead of > > hop-count. It may be simpler to design your own routing protocol > > that uses RTT instead of modifing RIP, but you should be the one to > > research that option :) > > > > Once you have designed your routing protocol, then you can decide > > whether you can reuse some of the RIP code. > > If you want to implement your protocol from scratch, then you can > > use the static_routes implementation as a starting point. > > > > Good luck! > > Atanu & Pavlin > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > Designing a routing protocol around a volatile, largely varying and > intrinsically unpredictable metric such as RTT is a difficult task and > generally not a good idea in a best-effort IP network. I'd rather > suggest you take an existing routing protocol such as OSPF or EIGRp and > consider implementing the generic "cost" hook based on consolidated RTT > data instead of bandwidth, hop-count or something else. Anyway, you have > to consider the return-path as well so that would defeat the purpose. > For a start you could also look at the EIGRP hybrid metric approach. > > Regards, > Gernot > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From gernot.schmied@chello.at Thu May 12 01:23:09 2005 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Thu, 12 May 2005 02:23:09 +0200 Subject: [Xorp-users] RTT "Round Trip Time" In-Reply-To: <9fa8f1af0505111634e4d48f1@mail.gmail.com> References: <200505102131.j4ALV3i5012391@possum.icir.org> <428206F3.8060506@chello.at> <9fa8f1af0505111634e4d48f1@mail.gmail.com> Message-ID: <4282A1ED.50506@chello.at> TTA Group wrote: > Thank you guys for your reply > I will take your advice about not playing with RIP to make it > RTT(Round Trip Time). But it seems XORP does not support any of the > "Cost" link protocols like OSPF or EIGRp isn't it ? > EIGRP is Cisco-proprietary anyway, an example given to discuss hybrid metrics, read Ivan Pepelniaks book about EIGRP. > So in this case, either I have to install their routing platform (like > Zebra) or even change the OS and use Windows2000 for OSPF. so which > choice you recommend guys? > > I notice that to activate OSPF in windows2000 I have to configure > Routing and Remote Access service in it. and that is only available in > windows 2000 server. isn't it ? do you think I can easily configure > OSPF in windows to use the delay metric (close to RTT) ? > You can't just "configure" or mimic TTL-like behavior, you have to reengineer the code. Have a look at the Quagga OSPF implementation, Zebra's evolution has nearly haltet. Link state protocols have a generic cost-based metric and what you mean by delay is administrator-configured. Gernot From dikshie@lapi.itb.ac.id Thu May 12 08:57:28 2005 From: dikshie@lapi.itb.ac.id (Dikshie) Date: Thu, 12 May 2005 14:57:28 +0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: <4554.1115822829@tigger.icir.org> References: <20050511140736.GB798@empiric.icir.org> <4554.1115822829@tigger.icir.org> Message-ID: <20050512075728.GA22399@lapi.itb.ac.id> Atanu Ghosh (atanu@icsi.berkeley.edu) wrote: > You need xorp/libcomm/comm_sock.c later than revision 1.17 > I've just cvs-ed, compile, install, run xorp_rtrmgr and then I'm still get: --- ipv6# /usr/local/xorp/bin/xorp_rtrmgr [ 2005/05/12 14:50:30 ERROR xorp_rtrmgr:75644 FINDER +374 finder_tcp_messenger.cc do_auto_connect ] Failed to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:31 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:32 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:33 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:34 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:35 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:36 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:37 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:38 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:39 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:40 ERROR xorp_rtrmgr:75644 FINDER +381 finder_tcp_messenger.cc do_auto_connect ] Failed 10 times to connect to 127.0.0.1/19999: Operation now in progress [ 2005/05/12 14:50:59 ERROR xorp_rtrmgr:75644 XRL +590 xrl_router.cc wait_until_xrl_router_is_ready ] XrlRouter failed. No Finder? ---- I have: ipv6# ident comm_sock.c comm_sock.c: $XORP: xorp/libcomm/comm_sock.c,v 1.20 2005/05/11 00:32:35 pavlin Exp $ thanks ! -dikshie- From M.Handley@cs.ucl.ac.uk Thu May 12 10:31:59 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 12 May 2005 10:31:59 +0100 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: Your message of "Thu, 12 May 2005 14:57:28 +0700." <20050512075728.GA22399@lapi.itb.ac.id> Message-ID: <31684.1115890319@aardvark.cs.ucl.ac.uk> >I've just cvs-ed, compile, install, run xorp_rtrmgr >and then I'm still get: >--- >ipv6# /usr/local/xorp/bin/xorp_rtrmgr >[ 2005/05/12 14:50:30 ERROR xorp_rtrmgr:75644 FINDER +374 finder_tcp_messenge >r.cc do_auto_connect ] Failed to connect to 127.0.0.1/19999: Operation now in >progress Normally the tinderbox would give us early warning if there's been any commit problem to our CVS archive. Unfortunately the tinderbox has been offline for the last day or so - I'm not clear why, but it's probably related to a major power failure in Berkeley a couple of days ago. Hopefully the ICSI folks can resolve this today. I just did a fresh build from CVS (FreeBSD 4.10, g++ 2.95.4) and ran the router manager. I had no problems, so it doesn't look like there's been a bad commit as far as I can see. I'll do a manual build and check on a FreeBSD 5.3 system to check that too. Unfortunately I don't have a FreeBSD 5.4 system to test on right now. It is of course possible that this problem is specific to FreeBSD 5.4, but this doesn't seem all that likely to me. As for the nature of the error - the finder is built in to the rtrmgr, so there's no way for the rtrmgr to be running and the finder not to be running. I notice that your machine is called "ipv6". Does this machine have an IPv4 address (i.e. 127.0.0.1) on the loopback interface? If not, this could be the cause of the problem. Cheers, Mark From dikshie@lapi.itb.ac.id Thu May 12 13:42:45 2005 From: dikshie@lapi.itb.ac.id (Dikshie) Date: Thu, 12 May 2005 19:42:45 +0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: <31684.1115890319@aardvark.cs.ucl.ac.uk> References: <20050512075728.GA22399@lapi.itb.ac.id> <31684.1115890319@aardvark.cs.ucl.ac.uk> Message-ID: <20050512124245.GA26166@lapi.itb.ac.id> Mark Handley (M.Handley@cs.ucl.ac.uk) wrote: > I just did a fresh build from CVS (FreeBSD 4.10, g++ 2.95.4) and ran > the router manager. I had no problems, so it doesn't look like > there's been a bad commit as far as I can see. > I'll do a manual build and check on a FreeBSD 5.3 system to check that > too. Unfortunately I don't have a FreeBSD 5.4 system to test on right > now. It is of course possible that this problem is specific to > FreeBSD 5.4, but this doesn't seem all that likely to me. my machine FreeBSD-5.4-STABLE > g++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 > As for the nature of the error - the finder is built in to the rtrmgr, > so there's no way for the rtrmgr to be running and the finder not to > be running. I notice that your machine is called "ipv6". Does this > machine have an IPv4 address (i.e. 127.0.0.1) on the loopback > interface? If not, this could be the cause of the problem. Its dual stack machine. It has IPv4 addresses. > ifconfig -a em0: flags=18943 mtu 1500 options=4b inet 167.205.30.228 netmask 0xfffffff0 broadcast 167.205.30.239 inet6 fe80::20c:f1ff:fe98:41ac%em0 prefixlen 64 scopeid 0x1 ether 00:0c:f1:98:41:ac media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=18843 mtu 1500 options=48 inet 167.205.37.129 netmask 0xffffff80 broadcast 167.205.37.255 inet6 fe80::20c:f1ff:fee4:4e67%fxp0 prefixlen 64 scopeid 0x2 inet6 2001:d30:3:320:20c:f1ff:fee4:4e67 prefixlen 64 ether 00:0c:f1:e4:4e:67 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108851 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 with best regards, -dikshie- From M.Handley@cs.ucl.ac.uk Thu May 12 13:58:49 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 12 May 2005 13:58:49 +0100 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: Your message of "Thu, 12 May 2005 19:42:45 +0700." <20050512124245.GA26166@lapi.itb.ac.id> Message-ID: <40237.1115902729@aardvark.cs.ucl.ac.uk> >Mark Handley (M.Handley@cs.ucl.ac.uk) wrote: >> I just did a fresh build from CVS (FreeBSD 4.10, g++ 2.95.4) and ran >> the router manager. I had no problems, so it doesn't look like >> there's been a bad commit as far as I can see. >> I'll do a manual build and check on a FreeBSD 5.3 system to check that >> too. The manual tests I ran failed on FreeBSD 5.3 with the same errors you've seen, so there has been a bad commit to CVS. Unlucky this should happen right when the tinderbox was broken, but I guess that's Murphy's law for you. We will get this fixed as soon as possible. Sorry for the problems, and thanks for reporting this. - Mark From M.Handley@cs.ucl.ac.uk Thu May 12 14:50:20 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 12 May 2005 14:50:20 +0100 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: Your message of "Thu, 12 May 2005 13:58:49 BST." <40237.1115902729@aardvark.cs.ucl.ac.uk> Message-ID: <42399.1115905820@aardvark.cs.ucl.ac.uk> >The manual tests I ran failed on FreeBSD 5.3 with the same errors >you've seen, so there has been a bad commit to CVS. Unlucky this >should happen right when the tinderbox was broken, but I guess that's >Murphy's law for you. > >We will get this fixed as soon as possible. Sorry for the problems, >and thanks for reporting this. If you're in a hurry, here's a diff that appears to fix this problem. I'm not really familiar with this code, so it's possible this isn't the best solution, but it does appear to work for me on FreeBSD 5.3. I'll leave it to someone with a better understanding of this part of the code than me to commit an official fix into CVS. Cheers, Mark vulture.xorp.org: cd xorp/xorp/libcomm/ vulture.xorp.org: cvs diff cvs diff: Diffing . Index: comm_user.c =================================================================== RCS file: /usr/local/share/doc/apache/cvs/xorp/libcomm/comm_user.c,v retrieving revision 1.17 diff -r1.17 comm_user.c 612c612 < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) --- > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) 658c658 < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) --- > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) 711c711 < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) --- > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) 757c757 < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) --- > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) From pavlin@icir.org Thu May 12 18:45:05 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 12 May 2005 10:45:05 -0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: Message from Mark Handley of "Thu, 12 May 2005 14:50:20 BST." <42399.1115905820@aardvark.cs.ucl.ac.uk> Message-ID: <200505121745.j4CHj58f020650@possum.icir.org> > > >The manual tests I ran failed on FreeBSD 5.3 with the same errors > >you've seen, so there has been a bad commit to CVS. Unlucky this > >should happen right when the tinderbox was broken, but I guess that's > >Murphy's law for you. > > > >We will get this fixed as soon as possible. Sorry for the problems, > >and thanks for reporting this. > > If you're in a hurry, here's a diff that appears to fix this problem. > I'm not really familiar with this code, so it's possible this isn't > the best solution, but it does appear to work for me on FreeBSD 5.3. > I'll leave it to someone with a better understanding of this part of > the code than me to commit an official fix into CVS. Yes, the fix is correct and is committed to CVS. Thanks for the catch! Guilty as charged, Pavlin > > Cheers, > Mark > > > vulture.xorp.org: cd xorp/xorp/libcomm/ > vulture.xorp.org: cvs diff > cvs diff: Diffing . > Index: comm_user.c > =================================================================== > RCS file: /usr/local/share/doc/apache/cvs/xorp/libcomm/comm_user.c,v > retrieving revision 1.17 > diff -r1.17 comm_user.c > 612c612 > < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) > --- > > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) > 658c658 > < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) > --- > > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) > 711c711 > < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) > --- > > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) > 757c757 > < if (is_blocking && (in_progress != NULL) && (*in_progress == 1)) > --- > > if ((!is_blocking) && (in_progress != NULL) && (*in_progress == 1)) > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dikshie@lapi.itb.ac.id Fri May 13 01:58:56 2005 From: dikshie@lapi.itb.ac.id (Dikshie) Date: Fri, 13 May 2005 07:58:56 +0700 Subject: [Xorp-users] ERROR xorp_rtrmgr:89197 FINDER +381 finder_tcp_messenger.cc do_auto_connect In-Reply-To: <200505121745.j4CHj58f020650@possum.icir.org> References: <42399.1115905820@aardvark.cs.ucl.ac.uk> <200505121745.j4CHj58f020650@possum.icir.org> Message-ID: <20050513005856.GA31694@lapi.itb.ac.id> Pavlin Radoslavov (pavlin@icir.org) wrote: > Yes, the fix is correct and is committed to CVS. Thanks for the > catch! Hi Pavlin and Mark, Many thanks for good working ! with best regards, -dikshie- From James Courtier-Dutton Sat May 14 15:39:40 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sat, 14 May 2005 15:39:40 +0100 Subject: [Xorp-users] Access control and QoS for Xorp Message-ID: Hi, I am looking at how one might add Access control and Qos to multicast. I am thinking about modifying the PIM-SM routers on the network to send RADIUS requests whenever an IGMPv3 messages are received. The RADIUS server will then return accept or reject. If accepted, the RADIUS server will return QoS parameters which Xorp could then apply to the Linux kernel QoS functions at the same time it adds a new multicast route. If the required QoS resources are not available, it will not add a multicast route. Is this functionallity possible in the current Xorp architecture? If so, where abouts in the source code should I look to add it? James From pavlin@icir.org Sun May 15 07:04:25 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sat, 14 May 2005 23:04:25 -0700 Subject: [Xorp-users] Access control and QoS for Xorp In-Reply-To: Message from James Courtier-Dutton of "Sat, 14 May 2005 15:39:40 BST." Message-ID: <200505150604.j4F64PLf036772@possum.icir.org> > I am looking at how one might add Access control and Qos to multicast. > I am thinking about modifying the PIM-SM routers on the network to > send RADIUS requests whenever an IGMPv3 messages are received. The > RADIUS server will then return accept or reject. If accepted, the > RADIUS server will return QoS parameters which Xorp could then apply > to the Linux kernel QoS functions at the same time it adds a new > multicast route. If the required QoS resources are not available, it > will not add a multicast route. > > Is this functionallity possible in the current Xorp architecture? > If so, where abouts in the source code should I look to add it? James, It should be possible with the following caveat. Currently, our IGMP implementation is only IGMPv1 and v2. We have IGMPv3 on our roadmap (see http://www.xorp.org/roadmap.html), but it is scheduled for January 2006. If, however, you don't need a full IGMPv3 implementation, but you need only to receive the IGMPv3 messages, I belive it should be relatively simple to add that to the IGMP module: you need to modify Mld6igmpVif::igmp_process() inside mld6igmp/igmp_proto.cc Then you just need to call Mld6igmpVif::join_prune_notify_routing() to send the (S,G) Join/Prune signal to, say, the PIM-SM module or the QoS module (see below). Though, before going that path, can you confirm that you really have to use IGMPv3, or IGMPv2 is also acceptable. In term of adding the multicast forwarding entries to the kernel, PIM-SM sends the appropriate XRL to the MFEA, and the MFEA installs them into the kernel. Hence, if you want to add QoS parameters, you have to modify the mfea/0.1/add_mfc4 XRL (see xrl/interfaces/mfea.xif) to include those parameters. Of course, you also have to modify the MFEA so it knows what to do with those parameters. The MFC entries are written to the kernel by MfeaMrouter::add_mfc() (inside fea/mfea_mrouter.cc). The interesting part is who sends and receives the RADIUS requests to/from the RADIUS server. The easiest approach probably would be for the PIM-SM module to do this, though it may not be the cleanest solution (architecture-wise). A cleaner solution would be to have a separate module (a QoS manager) that interacts with the RADIUS server, and then it sends XRLs to PIM-SM with instructions what to do. I believe the forthcoming policy manager can be extended to include the QoS functionality as well, though currently it needs some polishing before it is fully integrated with XORP. In either case, the PIM-SM's behavior is controlled by RADIUS accept/reject events, hence the PIM-SM module needs to be modified to take those events into account. You mentioned that the RADIUS server controls whether to enable the installation of a multicast route. This, translated into PIM-SM actions, means not only the installation of the forwarding entries into the kernel, but probably also whether any PIM Join messages are sent upstream (toward the source or the RP). There are several PIM-SM specific details that need to be considered here, but those can be discussed once you reach this stage. In any case, I don't see a show-stopper here, but it can be an interesting exercise. Regards, Pavlin From James Courtier-Dutton Sun May 15 11:48:12 2005 From: James Courtier-Dutton (James Courtier-Dutton) Date: Sun, 15 May 2005 11:48:12 +0100 Subject: [Xorp-users] RTT "Round Trip Time" In-Reply-To: <9fa8f1af0505080128130f72db@mail.gmail.com> References: <9fa8f1af0505080128130f72db@mail.gmail.com> Message-ID: On 5/8/05, TTA Group wrote: > Hi, > I'm a graduate student and my graduate project about "Round Trip Time" > as router matrix. So I think to use XORP as my research environment. > But I notice that the default xorp RIP matrix is "Hob Count". So does > any one has any idea how I can make it RTT "Round trip time"? any help > or suggestions in this subject or previous experience? > > I appreciate your time. > Tariq > > ttagroup@gmail.com > RTT has never been used as a routing protocol measurement for a very good reason. RTT is dependent on how much traffic has to pass over a link. That is, if you measure RTT with something like "ping". Another measure of RTT could be the physical latency of a link without any traffic on it. I.e. A Satellite link will have a higher latency that an land based link. As this RTT is therefore constant, one can just manually adjust the "cost" of a link. One has to then use a routing protocol that uses "cost" as a metric, like for example OSPF. So, what I am trying to say is that your current graduate project is hardly worth attempting as the final outcome will not be of any use to anyone. But, something that would be extremely useful, would be to implement something on the Xorp roadmap so that it arrives earlier. e.g. OSPFv2 or IGMPv3. James From drcaesar@ecs.fullerton.edu Sun May 15 04:18:09 2005 From: drcaesar@ecs.fullerton.edu (Jake Jangyeop Kim) Date: Sat, 14 May 2005 20:18:09 -0700 Subject: [Xorp-users] Static route configuration Message-ID: <200505150318.j4F3IG3j072069@wyvern.icir.org> This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C558C2.0C3E0CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I'm having a hard time in configuring static routes. Following is the topology. [RT2] / \ / \ [PC1]------------[RT1]-----[RT3]-----------[PC2] I configured only static protocol in the config.boot file on RT1 machine. protocols { static { route4 192.168.1.0/24 { next-hop: 192.168.1.20 /* interface to PC 1 */ metric: 1 } route4 192.168.2.0/24 { next-hop: 192.168.2.21 /* interface to RT2 */ metric: 1 } route4 192.168.4.0/24 { next-hop: 192.168.4.22 /* interface to RT3 */ metric: 1 } } } Ping never reaches to RT2 and RT3 from PC1. I was going to set up BGP in the first place, but it didn't work. So I tried static route to see if it works but it doesn't work either. What configuration should I check more? All machines are running on FreeBSD and Xorp is running on RT1, 2, and 3 machines. Thanks, Jake ------=_NextPart_000_0000_01C558C2.0C3E0CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = everyone,

 

I’m having a hard time in configuring static = routes.

Following is the = topology.

 

    &nbs= p;        [RT2]

    &nbs= p;            = ;            =            = /   \

    &nbs= p;            = ;          =        /       = \

[PC1]------------[RT1]-----[= RT3]-----------[PC2]

 

 

I configured only static = protocol in the config.boot file on RT1 machine.

protocols = {

    &nbs= p;        static {

    &nbs= p;            = ;          route4 192.168.1.0/24 {

    &nbs= p;            = ;            =            next-hop: 192.168.1.20 /* interface to PC 1 */

    &nbs= p;            = ;            =            metric: 1

    &nbs= p;            = ;          = }

    &nbs= p;            = ;          route4 192.168.2.0/24 {

    &nbs= p;            = ;            =            next-hop: 192.168.2.21 /* interface to RT2 */

    &nbs= p;            = ;            =            metric: 1

    &nbs= p;            = ;          = }

    &nbs= p;            = ;          route4 192.168.4.0/24 {

    &nbs= p;            = ;            =            next-hop: 192.168.4.22 /* interface to RT3 */

    &nbs= p;            = ;            =            metric: 1

    &nbs= p;            = ;          = }

    &nbs= p;        = }

}

 

Ping never reaches to RT2 and RT3 from PC1. I was going = to set up BGP in the first place, but it didn’t work. So I tried static route to see if it works = but it doesn’t work either. What configuration should I check = more? All machines are running on FreeBSD and Xorp is running on RT1, 2, and 3 = machines.

 

Thanks,

Jake

------=_NextPart_000_0000_01C558C2.0C3E0CE0-- From pavlin@icir.org Mon May 16 04:45:33 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 15 May 2005 20:45:33 -0700 Subject: [Xorp-users] Static route configuration In-Reply-To: Message from "Jake Jangyeop Kim" of "Sat, 14 May 2005 20:18:09 PDT." <200505150318.j4F3IG3j072069@wyvern.icir.org> Message-ID: <200505160345.j4G3jXfE003920@possum.icir.org> Jake, You need to configure the network interfaces that are going to be used by XORP (the "interfaces {}" configuration section). Also, in your case you should enable the unicast forwarding as well: fea { unicast-forwarding4 { disable: false } } Regards, Pavlin > Hi everyone, > > > > I'm having a hard time in configuring static routes. > > Following is the topology. > > > > [RT2] > > / \ > > / \ > > [PC1]------------[RT1]-----[RT3]-----------[PC2] > > > > > > I configured only static protocol in the config.boot file on RT1 machine. > > protocols { > > static { > > route4 192.168.1.0/24 { > > next-hop: 192.168.1.20 /* interface > to PC 1 */ > > metric: 1 > > } > > route4 192.168.2.0/24 { > > next-hop: 192.168.2.21 /* interface > to RT2 */ > > metric: 1 > > } > > route4 192.168.4.0/24 { > > next-hop: 192.168.4.22 /* interface > to RT3 */ > > metric: 1 > > } > > } > > } > > > > Ping never reaches to RT2 and RT3 from PC1. I was going to set up BGP in the > first place, but it didn't work. So I tried static route to see if it works > but it doesn't work either. What configuration should I check more? All > machines are running on FreeBSD and Xorp is running on RT1, 2, and 3 > machines. From drcaesar@yahoo.com Mon May 16 06:11:35 2005 From: drcaesar@yahoo.com (Jake Kim) Date: Sun, 15 May 2005 22:11:35 -0700 (PDT) Subject: [Xorp-users] Static route configuration Message-ID: <20050516051135.42168.qmail@web80604.mail.yahoo.com> Pavlin, Thanks for your reply. Yes, I configured those two, interfaces and fea too. I just didn't explain it. ;) Three interfaces are configured in R1 machine. interfaces { interface fxp0 { description: "Ethernet" vif fxp0 { disable: false address 192.168.1.20 { disable: false prefix-length: 24 broadcast: 192.168.1.255 } } } interface fxp1 { description: "Ethernet" vif fxp1 { disable: false address 192.168.2.21 { disable: false prefix-length: 24 broadcast: 192.168.2.255 } } } interface fxp2 { description: "Ethernet" vif fxp2 { disable: false address 192.168.2.22 { disable: false prefix-length: 24 broadcast: 192.168.1.255 } } } disable: false } fea { unicast-forwarding4 { disable: false } } and the static protocol. What do I have to configure more? Thanks, Jake -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin@icir.org] Sent: Sunday, May 15, 2005 8:46 PM To: drcaesar@ecs.fullerton.edu Cc: xorp-users@xorp.org Subject: Re: [Xorp-users] Static route configuration Jake, You need to configure the network interfaces that are going to be used by XORP (the "interfaces {}" configuration section). Also, in your case you should enable the unicast forwarding as well: fea { unicast-forwarding4 { disable: false } } Regards, Pavlin > Hi everyone, > > > > I'm having a hard time in configuring static routes. > > Following is the topology. > > > > [RT2] > > / \ > > / \ > > [PC1]------------[RT1]-----[RT3]-----------[PC2] > > > > > > I configured only static protocol in the config.boot file on RT1 machine. > > protocols { > > static { > > route4 192.168.1.0/24 { > > next-hop: 192.168.1.20 /* interface > to PC 1 */ > > metric: 1 > > } > > route4 192.168.2.0/24 { > > next-hop: 192.168.2.21 /* interface > to RT2 */ > > metric: 1 > > } > > route4 192.168.4.0/24 { > > next-hop: 192.168.4.22 /* interface > to RT3 */ > > metric: 1 > > } > > } > > } > > > > Ping never reaches to RT2 and RT3 from PC1. I was going to set up BGP in the > first place, but it didn't work. So I tried static route to see if it works > but it doesn't work either. What configuration should I check more? All > machines are running on FreeBSD and Xorp is running on RT1, 2, and 3 > machines. From pavlin@icir.org Mon May 16 07:02:10 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 15 May 2005 23:02:10 -0700 Subject: [Xorp-users] Static route configuration In-Reply-To: Message from Jake Kim of "Sun, 15 May 2005 22:11:35 PDT." <20050516051135.42168.qmail@web80604.mail.yahoo.com> Message-ID: <200505160602.j4G62A8T004745@possum.icir.org> > Thanks for your reply. Yes, I configured those two, > interfaces and fea too. I just didn't explain it. ;) > Three interfaces are configured in R1 machine. > and the static protocol. > What do I have to configure more? Were there any log messages that indicate any error? And, of course, did you see the static routes installed in the kernel? The output of "netstat -rn" should tell you what routes are in the kernel. Regards, Pavlin > > Thanks, > Jake > > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin@icir.org] > Sent: Sunday, May 15, 2005 8:46 PM > To: drcaesar@ecs.fullerton.edu > Cc: xorp-users@xorp.org > Subject: Re: [Xorp-users] Static route configuration > > Jake, > > You need to configure the network interfaces that are > going to be > used by XORP (the "interfaces {}" configuration > section). > > Also, in your case you should enable the unicast > forwarding as well: > fea { > unicast-forwarding4 { > disable: false > } > } > > > Regards, > Pavlin > > > Hi everyone, > > > > > > > > I'm having a hard time in configuring static routes. > > > > Following is the topology. > > > > > > > > [RT2] > > > > / \ > > > > / \ > > > > [PC1]------------[RT1]-----[RT3]-----------[PC2] > > > > > > > > > > > > I configured only static protocol in the config.boot > file on RT1 machine. > > > > protocols { > > > > static { > > > > route4 192.168.1.0/24 { > > > > next-hop: > 192.168.1.20 /* interface > > to PC 1 */ > > > > metric: 1 > > > > } > > > > route4 192.168.2.0/24 { > > > > next-hop: > 192.168.2.21 /* interface > > to RT2 */ > > > > metric: 1 > > > > } > > > > route4 192.168.4.0/24 { > > > > next-hop: > 192.168.4.22 /* interface > > to RT3 */ > > > > metric: 1 > > > > } > > > > } > > > > } > > > > > > > > Ping never reaches to RT2 and RT3 from PC1. I was > going to set up BGP in the > > first place, but it didn't work. So I tried static > route to see if it works > > but it doesn't work either. What configuration > should I check more? All > > machines are running on FreeBSD and Xorp is running > on RT1, 2, and 3 > > machines. > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From drcaesar@yahoo.com Mon May 16 07:21:31 2005 From: drcaesar@yahoo.com (Jake Kim) Date: Sun, 15 May 2005 23:21:31 -0700 (PDT) Subject: [Xorp-users] Static route configuration In-Reply-To: 6667 Message-ID: <20050516062131.92939.qmail@web80601.mail.yahoo.com> Pavlin, Everything seemed correct from "netstat -rn" and "xorpsh". Let me check that again tomorrow. Additional thing I'd like to ask you is that why metric is 0 when I did "show route ... connected" in the xorp shell whereas "show route ... static" shows metric is 1? Does this mean something wrong? One more question... when I run xorp, it stops at [no more tasks to run] not allowing me to tpye any BSD command unless I log out with ALT + F4, does this indicate normal status of xorp? I'm new to xorp... Thanks, Jake --- Pavlin Radoslavov wrote: > > Thanks for your reply. Yes, I configured those > two, > > interfaces and fea too. I just didn't explain it. > ;) > > Three interfaces are configured in R1 machine. > > > > > and the static protocol. > > What do I have to configure more? > > Were there any log messages that indicate any error? > And, of course, did you see the static routes > installed in the > kernel? The output of "netstat -rn" should tell you > what routes are > in the kernel. > > Regards, > Pavlin > > > > > Thanks, > > Jake > > > > > > -----Original Message----- > > From: Pavlin Radoslavov [mailto:pavlin@icir.org] > > Sent: Sunday, May 15, 2005 8:46 PM > > To: drcaesar@ecs.fullerton.edu > > Cc: xorp-users@xorp.org > > Subject: Re: [Xorp-users] Static route > configuration > > > > Jake, > > > > You need to configure the network interfaces that > are > > going to be > > used by XORP (the "interfaces {}" configuration > > section). > > > > Also, in your case you should enable the unicast > > forwarding as well: > > fea { > > unicast-forwarding4 { > > disable: false > > } > > } > > > > > > Regards, > > Pavlin > > > > > Hi everyone, > > > > > > > > > > > > I'm having a hard time in configuring static > routes. > > > > > > Following is the topology. > > > > > > > > > > > > [RT2] > > > > > > / \ > > > > > > / \ > > > > > > [PC1]------------[RT1]-----[RT3]-----------[PC2] > > > > > > > > > > > > > > > > > > I configured only static protocol in the > config.boot > > file on RT1 machine. > > > > > > protocols { > > > > > > static { > > > > > > route4 192.168.1.0/24 > { > > > > > > > next-hop: > > 192.168.1.20 /* interface > > > to PC 1 */ > > > > > > metric: > 1 > > > > > > } > > > > > > route4 192.168.2.0/24 > { > > > > > > > next-hop: > > 192.168.2.21 /* interface > > > to RT2 */ > > > > > > metric: > 1 > > > > > > } > > > > > > route4 192.168.4.0/24 > { > > > > > > > next-hop: > > 192.168.4.22 /* interface > > > to RT3 */ > > > > > > metric: > 1 > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > Ping never reaches to RT2 and RT3 from PC1. I > was > > going to set up BGP in the > > > first place, but it didn't work. So I tried > static > > route to see if it works > > > but it doesn't work either. What configuration > > should I check more? All > > > machines are running on FreeBSD and Xorp is > running > > on RT1, 2, and 3 > > > machines. > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From pavlin@icir.org Mon May 16 07:45:27 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Sun, 15 May 2005 23:45:27 -0700 Subject: [Xorp-users] Static route configuration In-Reply-To: Message from Jake Kim of "Sun, 15 May 2005 23:21:31 PDT." <20050516062131.92939.qmail@web80601.mail.yahoo.com> Message-ID: <200505160645.j4G6jRjg005054@possum.icir.org> > Everything seemed correct from "netstat -rn" and > "xorpsh". Let me check that again tomorrow. Additional > thing I'd like to ask you is that why metric is 0 when > I did "show route ... connected" in the xorp shell > whereas "show route ... static" shows metric is 1? > Does this mean something wrong? That's normal. All "connected" routes (automatically added internally by RIB) have administrative metric of 0, while all static routes have metric of 1. > One more question... when I run xorp, it stops at [no > more tasks to run] not allowing me to tpye any BSD > command unless I log out with ALT + F4, does this > indicate normal status of xorp? That's normal too. By default, the rtrmgr runs in foreground. If you want to run any UNIX commands, then you have to open another terminal. Alternatively, run the rtrmgr in background and redirect its output to a file. Regars, Pavlin > I'm new to xorp... > > Thanks, > Jake From Diogo Della" This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C55BF5.CB8CBAC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgZXZyZXlvbmUsDQoNCkknbSBoYXZpbmcgcHJvYmxlbXMgY29tcGlsaW5nIFhvcnAgMS4xLg0K DQpUaGUgY29tbWFuZHMgd2VyZToNCiMuL2NvbmZpZ3VyZQ0KI2dtYWtlDQojZ21ha2UgY2hlY2sN Cg0KQWZ0ZXIgdGhlIGNoZWNrLCBJIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgZXJyb3JzOg0KIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCkZBSUw6IHRl c3RfeHJsX3NvY2tldHM0X3VkcC5zaA0KPT09PT09PT09PT09PT09PT09PQ0KMSBvZiAzIHRlc3Rz IGZhaWxlZA0KPT09PT09PT09PT09PT09PT09PQ0KZ21ha2VbM106ICoqKiBbY2hlY2stVEVTVFNd IEVycm9yIDENCmdtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci94b3JwLTEuMS9mZWEn DQpnbWFrZVsyXTogKioqIFtjaGVjay1hbV0gRXJyb3IgMg0KZ21ha2VbMl06IExlYXZpbmcgZGly ZWN0b3J5IGAvdXNyL3hvcnAtMS4xL2ZlYScNCmdtYWtlWzFdOiAqKiogW2NoZWNrLXJlY3Vyc2l2 ZV0gRXJyb3IgMQ0KZ21ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3hvcnAtMS4xL2Zl YScNCmdtYWtlOiAqKiogW2NoZWNrLXJlY3Vyc2l2ZV0gRXJyb3IgMQ0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCg0KSSB0aGluayB0aGUgcHJvYmxl bSBpcyByZWxhdGVkIHRvIG9wZW5pbmcgc29ja2V0cyBhdCBGcmVlQlNELCBidXQgSSBjYW60dCBm aWd1cmUgb3V0IGhvdyB0byBzb2x2ZS4NCg0KUnVubmluZyB4b3JwX3J0cm1nciwgSSBnb3Q6DQoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0Kcm91dGVy MSMgLi94b3JwX3J0cm1ncg0KWyAyMDA1LzA1LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX3J0cm1n cjo3MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2Vz IG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS4NClsgMjAwNS8wNS8xOCAyMjowNDozMiAgRVJST1Ig eG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAi eG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTggMjI6MDQ6 MzIgIEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2Vy IF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAyMDA1LzA1 LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5j YyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS4N ClsgMjAwNS8wNS8xOCAyMjowNDozMiAgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEy NiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhp cyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzIgIEVSUk9SIHhvcnBfcnRybWdyOjczNTAg UlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4 aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAyMDA1LzA1LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX3J0 cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBk b2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS4NClsgMjAwNS8wNS8xOCAyMjowNDozMiAgRVJS T1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91 cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTggMjI6 MDQ6MzIgIEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91 c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAyMDA1 LzA1LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJk Yi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3Rl bS4NClsgMjAwNS8wNS8xOCAyMjowNDozMiAgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1Ig KzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24g dGhpcyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzIgIEVSUk9SIHhvcnBfcnRybWdyOjcz NTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90 IGV4aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAyMDA1LzA1LzE4IDIyOjA0OjMyICBFUlJPUiB4b3Jw X3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3Jw IiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS4NClsgMjAwNS8wNS8xOCAyMjowNDozMiAg RVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBH cm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTgg MjI6MDQ6MzIgIEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFk ZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAy MDA1LzA1LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVz ZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5 c3RlbS4NClsgMjAwNS8wNS8xOCAyMjowNDozMiAgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJN R1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qg b24gdGhpcyBzeXN0ZW0uDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzIgIEVSUk9SIHhvcnBfcnRybWdy OjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMg bm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLg0KWyAyMDA1LzA1LzE4IDIyOjA0OjMyICBJTkZPIHhv cnBfcnRybWdyOjczNTAgUlRSTUdSICsxNzAgbWFzdGVyX2NvbmZfdHJlZS5jYyBleGVjdXRlIF0g Q2hhbmdlZCBtb2R1bGVzOiBpbnRlcmZhY2VzLCBmZWEsIG1mZWE0LCByaWIsIHN0YXRpY19yb3V0 ZXMsIGJncCwgZmliMm1yaWIsIGlnbXAsIHBpbXNtNCwgcmlwDQpbIDIwMDUvMDUvMTggMjI6MDQ6 MzIgIElORk8geG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzQwNCBtb2R1bGVfbWFuYWdlci5jYyBy dW4gXSBSdW5uaW5nIG1vZHVsZTogaW50ZXJmYWNlcyAoL3Vzci94b3JwLTEuMS9mZWEveG9ycF9m ZWEpDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzIgIEVSUk9SIHhvcnBfZmVhOjczNTEgRkVBICs0MDUg cm91dGluZ19zb2NrZXRfdXRpbHMuY2MgcnRtX2dldF90b19mdGVfY2ZnIF0gQ2Fubm90IG1hcCBh IGRpc2NhcmQgcm91dGUgYmFjayB0byBhbiBGRUEgc29mdCBkaXNjYXJkIGludGVyZmFjZS4NClsg MjAwNS8wNS8xOCAyMjowNDozMiAgRVJST1IgeG9ycF9mZWE6NzM1MSBGRUEgKzQwNSByb3V0aW5n X3NvY2tldF91dGlscy5jYyBydG1fZ2V0X3RvX2Z0ZV9jZmcgXSBDYW5ub3QgbWFwIGEgZGlzY2Fy ZCByb3V0ZSBiYWNrIHRvIGFuIEZFQSBzb2Z0IGRpc2NhcmQgaW50ZXJmYWNlLg0KWyAyMDA1LzA1 LzE4IDIyOjA0OjMyICBFUlJPUiB4b3JwX2ZlYTo3MzUxIEZFQSArNDA1IHJvdXRpbmdfc29ja2V0 X3V0aWxzLmNjIHJ0bV9nZXRfdG9fZnRlX2NmZyBdIENhbm5vdCBtYXAgYSBkaXNjYXJkIHJvdXRl IGJhY2sgdG8gYW4gRkVBIHNvZnQgZGlzY2FyZCBpbnRlcmZhY2UuDQpbIDIwMDUvMDUvMTggMjI6 MDQ6MzMgSU5GTyB4b3JwX2ZlYSBDTEkgXSBDTEkgZW5hYmxlZA0KWyAyMDA1LzA1LzE4IDIyOjA0 OjMzIElORk8geG9ycF9mZWEgQ0xJIF0gQ0xJIHN0YXJ0ZWQNClsgMjAwNS8wNS8xOCAyMjowNDoz MyBJTkZPIHhvcnBfZmVhIE1GRUEgXSBNRkVBIGVuYWJsZWQNClsgMjAwNS8wNS8xOCAyMjowNDoz MyBJTkZPIHhvcnBfZmVhIE1GRUEgXSBDTEkgZW5hYmxlZA0KWyAyMDA1LzA1LzE4IDIyOjA0OjMz IElORk8geG9ycF9mZWEgTUZFQSBdIENMSSBzdGFydGVkDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzMg SU5GTyB4b3JwX2ZlYSBNRkVBIF0gTUZFQSBlbmFibGVkDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzMg SU5GTyB4b3JwX2ZlYSBNRkVBIF0gQ0xJIGVuYWJsZWQNClsgMjAwNS8wNS8xOCAyMjowNDozMyBJ TkZPIHhvcnBfZmVhIE1GRUEgXSBDTEkgc3RhcnRlZA0KWyAyMDA1LzA1LzE4IDIyOjA0OjM0ICBJ TkZPIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICs0MDQgbW9kdWxlX21hbmFnZXIuY2MgcnVuIF0g UnVubmluZyBtb2R1bGU6IGZlYSAoL3Vzci94b3JwLTEuMS9mZWEveG9ycF9mZWEpDQpbIDIwMDUv MDUvMTggMjI6MDQ6MzkgIEVSUk9SIHhvcnBfZmVhOjczNTEgTElCQ09NTSArNDk5IGNvbW1fc29j ay5jIGNvbW1fc29ja19jb25uZWN0NCBdIEVycm9yIGNvbm5lY3Rpbmcgc29ja2V0IChmYW1pbHkg PSAyLCByZW1vdGVfYWRkciA9IDEyNy4wLjAuMSwgcmVtb3RlX3BvcnQgPSAxMzAwMCk6IENvbm5l Y3Rpb24gcmVmdXNlZA0KWyAyMDA1LzA1LzE4IDIyOjA0OjM5IFdBUk5JTkcgeG9ycF9mZWEgRkVB IF0gQ291bGQgbm90IG9wZW4gdXNlci1sZXZlbCBDbGljayBzb2NrZXQ6IENvbm5lY3Rpb24gcmVm dXNlZC4gVHJ5aW5nIGFnYWluLi4uDQpbIDIwMDUvMDUvMTggMjI6MDQ6MzkgIEVSUk9SIHhvcnBf ZmVhOjczNTEgTElCQ09NTSArNDk5IGNvbW1fc29jay5jIGNvbW1fc29ja19jb25uZWN0NCBdIEVy cm9yIGNvbm5lY3Rpbmcgc29ja2V0IChmYW1pbHkgPSAyLCByZW1vdGVfYWRkciA9IDEyNy4wLjAu MSwgcmVtb3RlX3BvcnQgPSAxMzAwMCk6IENvbm5lY3Rpb24gcmVmdXNlZA0KWyAyMDA1LzA1LzE4 IDIyOjA0OjM5IFdBUk5JTkcgeG9ycF9mZWEgRkVBIF0gQ291bGQgbm90IG9wZW4gdXNlci1sZXZl bCBDbGljayBzb2NrZXQ6IENvbm5lY3Rpb24gcmVmdXNlZC4gVHJ5aW5nIGFnYWluLi4uDQpbIDIw MDUvMDUvMTggMjI6MDQ6MzkgIEVSUk9SIHhvcnBfZmVhOjczNTEgTElCQ09NTSArNDk5IGNvbW1f c29jay5jIGNvbW1fc29ja19jb25uZWN0NCBdIEVycm9yIGNvbm5lY3Rpbmcgc29ja2V0IChmYW1p bHkgPSAyLCByZW1vdGVfYWRkciA9IDEyNy4wLjAuMSwgcmVtb3RlX3BvcnQgPSAxMzAwMCk6IENv bm5lY3Rpb24gcmVmdXNlZA0KWyAyMDA1LzA1LzE4IDIyOjA0OjM5IFdBUk5JTkcgeG9ycF9mZWEg RkVBIF0gQ291bGQgbm90IG9wZW4gdXNlci1sZXZlbCBDbGljayBzb2NrZXQ6IENvbm5lY3Rpb24g cmVmdXNlZC4gVHJ5aW5nIGFnYWluLi4uDQpbIDIwMDUvMDUvMTggMjI6MDQ6NDAgIEVSUk9SIHhv cnBfZmVhOjczNTEgTElCQ09NTSArNDk5IGNvbW1fc29jay5jIGNvbW1fc29ja19jb25uZWN0NCBd IEVycm9yIGNvbm5lY3Rpbmcgc29ja2V0IChmYW1pbHkgPSAyLCByZW1vdGVfYWRkciA9IDEyNy4w LjAuMSwgcmVtb3RlX3BvcnQgPSAxMzAwMCk6IENvbm5lY3Rpb24gcmVmdXNlZA0KWyAyMDA1LzA1 LzE4IDIyOjA0OjQwIFdBUk5JTkcgeG9ycF9mZWEgWHJsRmVhVGFyZ2V0IF0gSGFuZGxpbmcgbWV0 aG9kIGZvciBmZWFfY2xpY2svMC4xL3N0YXJ0X2NsaWNrIGZhaWxlZDogWHJsQ21kRXJyb3IgMTAy IENvbW1hbmQgZmFpbGVkIENvdWxkIG5vdCBvcGVuIHVzZXItbGV2ZWwgQ2xpY2sgc29ja2V0OiBD b25uZWN0aW9uIHJlZnVzZWQNClsgMjAwNS8wNS8xOCAyMjowNDo0MCAgRVJST1IgeG9ycF9ydHJt Z3I6NzM1MCBSVFJNR1IgKzU5NyBtYXN0ZXJfY29uZl90cmVlLmNjIGNvbW1pdF9wYXNzMl9kb25l IF0gQ29tbWl0IGZhaWxlZDogMTAyIENvbW1hbmQgZmFpbGVkIENvdWxkIG5vdCBvcGVuIHVzZXIt bGV2ZWwgQ2xpY2sgc29ja2V0OiBDb25uZWN0aW9uIHJlZnVzZWQNClsgMjAwNS8wNS8xOCAyMjow NDo0MCAgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzE4MiBtYXN0ZXJfY29uZl90cmVl LmNjIGNvbmZpZ19kb25lIF0gQ29uZmlndXJhdGlvbiBmYWlsZWQ6IDEwMiBDb21tYW5kIGZhaWxl ZCBDb3VsZCBub3Qgb3BlbiB1c2VyLWxldmVsIENsaWNrIHNvY2tldDogQ29ubmVjdGlvbiByZWZ1 c2VkDQpbIDIwMDUvMDUvMTggMjI6MDQ6NDAgIElORk8geG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1Ig KzE0MjAgdGFzay5jYyBydW5fdGFzayBdIE5vIG1vcmUgdGFza3MgdG8gcnVuDQpbIDIwMDUvMDUv MTggMjI6MDQ6NDAgIElORk8geG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzIxNiBtb2R1bGVfbWFu YWdlci5jYyB0ZXJtaW5hdGUgXSBUZXJtaW5hdGluZyBtb2R1bGU6IGZlYQ0KWyAyMDA1LzA1LzE4 IDIyOjA0OjQwICBJTkZPIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsyMTYgbW9kdWxlX21hbmFn ZXIuY2MgdGVybWluYXRlIF0gVGVybWluYXRpbmcgbW9kdWxlOiBpbnRlcmZhY2VzDQpbIDIwMDUv MDUvMTggMjI6MDQ6NDAgIElORk8geG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzI2MiBtb2R1bGVf bWFuYWdlci5jYyB0ZXJtaW5hdGUgXSBLaWxsaW5nIG1vZHVsZTogaW50ZXJmYWNlcyAocGlkID0g NzM1MSkNClsgMjAwNS8wNS8xOCAyMjowNDo0MCAgSU5GTyB4b3JwX3J0cm1ncjo3MzUwIFJUUk1H UiArNTQ3IG1vZHVsZV9tYW5hZ2VyLmNjIGtpbGxlZCBdIE1vZHVsZSBraWxsZWQgZHVyaW5nIHNo dXRkb3duOiBpbnRlcmZhY2VzDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjDQoNCg0KSSBjb21waWxlZCBYb3JwIGF0IHRoaXMgZW52aXJvbWVudDoN CkZyZWVCU0QgNC4xMA0KR05VIE1ha2UgMy44MA0KZ2NjIHZlcnNpb24gMi45NS40IDIwMDIwMzIw IFtGcmVlQlNEXQ0KDQpUaGUgS2VybmVsIGhhcyB0aGlzIG9wdGlvbnMgY29tcGlsZWQ6DQojTVVM VElDQVNUDQpvcHRpb25zICAgICAgICAgTVJPVVRJTkcNCg0KI0RVTU1ZTkVUDQpvcHRpb25zICAg ICAgICAgRFVNTVlORVQNCm9wdGlvbnMgICAgICAgICBJUEZJUkVXQUxMDQpvcHRpb25zICAgICAg ICAgSVBGSVJFV0FMTF9WRVJCT1NFDQpvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9WRVJCT1NF X0xJTUlUPTUNCm9wdGlvbnMgICAgICAgICBJUEZJUkVXQUxMX0ZPUldBUkQNCm9wdGlvbnMgICAg ICAgICBJUEZXMg0Kb3B0aW9ucyAgICAgICAgIElQRElWRVJUDQpvcHRpb25zICAgICAgICAgSFo9 MTAwMA0Kb3B0aW9ucyAgICBJUEZJUkVXQUxMX0RFRkFVTFRfVE9fQUNDRVBUDQpvcHRpb25zICAg IElQVjZGSVJFV0FMTA0Kb3B0aW9ucyAgICBJUFY2RklSRVdBTExfVkVSQk9TRQ0Kb3B0aW9ucyAg ICBJUFY2RklSRVdBTExfVkVSQk9TRV9MSU1JVA0Kb3B0aW9ucyAgICBJUFY2RklSRVdBTExfREVG QVVMVF9UT19BQ0NFUFQNCg0KQXRlbmNpb3NhbWVudGUsDQoNCkRpb2dvIERlbGxhIFRvcnJlcyBP bGl2ZWlyYQ0KaHR0cDovL3d3dy5kZWxsYS5lbmcuYnIgICAgDQpkaW9nb2R0b0B0ZXJyYS5jb20u YnIgICAgICAgICAgICAgIA0KTVNOOiBkaW9nb2R0b0Bob3RtYWlsLmNvbSAgICAgICAgICAgICAg ICAgICAgICANCis1NSAoNjEpIDg0MDEtNzA3MA0KDQo= ------=_NextPart_000_006E_01C55BF5.CB8CBAC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNDk4IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0y PkhpIGV2cmV5b25lLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+SSdt IGhhdmluZyBwcm9ibGVtcyBjb21waWxpbmcgWG9ycCANCjEuMS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUNvdXJpZXIgc2l6ZT0yPlRoZSBjb21tYW5kcyB3ZXJlOjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj4jLi9jb25maWd1cmU8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+I2dtYWtlPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPiNnbWFrZSBjaGVjazwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Q291cmllciBzaXplPTI+QWZ0ZXIgdGhlIGNoZWNrLCBJIHJlY2VpdmVkIHRoZSBmb2xs b3dpbmcgDQplcnJvcnM6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgDQpz aXplPTI+IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyM8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+RkFJTDogDQp0ZXN0 X3hybF9zb2NrZXRzNF91ZHAuc2g8QlI+PT09PT09PT09PT09PT09PT09PTxCUj4xIG9mIDMgdGVz dHMgDQpmYWlsZWQ8QlI+PT09PT09PT09PT09PT09PT09PTxCUj5nbWFrZVszXTogKioqIFtjaGVj ay1URVNUU10gRXJyb3IgDQoxPEJSPmdtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci94 b3JwLTEuMS9mZWEnPEJSPmdtYWtlWzJdOiAqKiogW2NoZWNrLWFtXSANCkVycm9yIDI8QlI+Z21h a2VbMl06IExlYXZpbmcgZGlyZWN0b3J5IGAvdXNyL3hvcnAtMS4xL2ZlYSc8QlI+Z21ha2VbMV06 ICoqKiANCltjaGVjay1yZWN1cnNpdmVdIEVycm9yIDE8QlI+Z21ha2VbMV06IExlYXZpbmcgZGly ZWN0b3J5IA0KYC91c3IveG9ycC0xLjEvZmVhJzxCUj5nbWFrZTogKioqIFtjaGVjay1yZWN1cnNp dmVdIEVycm9yIDE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciANCnNpemU9 Mj4jIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIzwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+SSB0aGluayB0aGUgcHJvYmxlbSBp cyByZWxhdGVkIHRvIG9wZW5pbmcgc29ja2V0cyANCmF0IEZyZWVCU0QsIGJ1dCBJIGNhbrR0IGZp Z3VyZSBvdXQgaG93IHRvIHNvbHZlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3Vy aWVyIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBz aXplPTI+UnVubmluZyB4b3JwX3J0cm1nciwgSSBnb3Q6PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUNvdXJpZXIgDQpzaXplPTI+IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBz aXplPTI+cm91dGVyMSMgLi94b3JwX3J0cm1ncjxCUj5bIDIwMDUvMDUvMTggDQoyMjowNDozMiZu YnNwOyBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5jYyBhZGRfdXNl ciBdIEdyb3VwIA0KInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLjxCUj5bIDIw MDUvMDUvMTggMjI6MDQ6MzImbmJzcDsgRVJST1IgDQp4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiAr MTI2IHVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiAN CnRoaXMgc3lzdGVtLjxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzImbmJzcDsgRVJST1IgeG9ycF9y dHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiANCnVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3Jw IiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS48QlI+WyAyMDA1LzA1LzE4IA0KMjI6MDQ6 MzImbmJzcDsgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiB1c2VyZGIuY2MgYWRk X3VzZXIgXSBHcm91cCANCiJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS48QlI+ WyAyMDA1LzA1LzE4IDIyOjA0OjMyJm5ic3A7IEVSUk9SIA0KeG9ycF9ydHJtZ3I6NzM1MCBSVFJN R1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qg b24gDQp0aGlzIHN5c3RlbS48QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMyJm5ic3A7IEVSUk9SIHhv cnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgDQp1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAi eG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0uPEJSPlsgMjAwNS8wNS8xOCANCjIy OjA0OjMyJm5ic3A7IEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNj IGFkZF91c2VyIF0gR3JvdXAgDQoieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0u PEJSPlsgMjAwNS8wNS8xOCAyMjowNDozMiZuYnNwOyBFUlJPUiANCnhvcnBfcnRybWdyOjczNTAg UlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4 aXN0IG9uIA0KdGhpcyBzeXN0ZW0uPEJSPlsgMjAwNS8wNS8xOCAyMjowNDozMiZuYnNwOyBFUlJP UiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IA0KdXNlcmRiLmNjIGFkZF91c2VyIF0gR3Jv dXAgInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLjxCUj5bIDIwMDUvMDUvMTgg DQoyMjowNDozMiZuYnNwOyBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IHVzZXJk Yi5jYyBhZGRfdXNlciBdIEdyb3VwIA0KInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lz dGVtLjxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzImbmJzcDsgRVJST1IgDQp4b3JwX3J0cm1ncjo3 MzUwIFJUUk1HUiArMTI2IHVzZXJkYi5jYyBhZGRfdXNlciBdIEdyb3VwICJ4b3JwIiBkb2VzIG5v dCBleGlzdCBvbiANCnRoaXMgc3lzdGVtLjxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzImbmJzcDsg RVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiANCnVzZXJkYi5jYyBhZGRfdXNlciBd IEdyb3VwICJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlzIHN5c3RlbS48QlI+WyAyMDA1LzA1 LzE4IA0KMjI6MDQ6MzImbmJzcDsgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzEyNiB1 c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCANCiJ4b3JwIiBkb2VzIG5vdCBleGlzdCBvbiB0aGlz IHN5c3RlbS48QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMyJm5ic3A7IEVSUk9SIA0KeG9ycF9ydHJt Z3I6NzM1MCBSVFJNR1IgKzEyNiB1c2VyZGIuY2MgYWRkX3VzZXIgXSBHcm91cCAieG9ycCIgZG9l cyBub3QgZXhpc3Qgb24gDQp0aGlzIHN5c3RlbS48QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMyJm5i c3A7IEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxMjYgDQp1c2VyZGIuY2MgYWRkX3Vz ZXIgXSBHcm91cCAieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24gdGhpcyBzeXN0ZW0uPEJSPlsgMjAw NS8wNS8xOCANCjIyOjA0OjMyJm5ic3A7IEVSUk9SIHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsx MjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgDQoieG9ycCIgZG9lcyBub3QgZXhpc3Qgb24g dGhpcyBzeXN0ZW0uPEJSPlsgMjAwNS8wNS8xOCAyMjowNDozMiZuYnNwOyBFUlJPUiANCnhvcnBf cnRybWdyOjczNTAgUlRSTUdSICsxMjYgdXNlcmRiLmNjIGFkZF91c2VyIF0gR3JvdXAgInhvcnAi IGRvZXMgbm90IGV4aXN0IG9uIA0KdGhpcyBzeXN0ZW0uPEJSPlsgMjAwNS8wNS8xOCAyMjowNDoz MiZuYnNwOyBFUlJPUiB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMTI2IA0KdXNlcmRiLmNjIGFk ZF91c2VyIF0gR3JvdXAgInhvcnAiIGRvZXMgbm90IGV4aXN0IG9uIHRoaXMgc3lzdGVtLjxCUj5b IDIwMDUvMDUvMTggDQoyMjowNDozMiZuYnNwOyBJTkZPIHhvcnBfcnRybWdyOjczNTAgUlRSTUdS ICsxNzAgbWFzdGVyX2NvbmZfdHJlZS5jYyBleGVjdXRlIF0gDQpDaGFuZ2VkIG1vZHVsZXM6IGlu dGVyZmFjZXMsIGZlYSwgbWZlYTQsIHJpYiwgc3RhdGljX3JvdXRlcywgYmdwLCBmaWIybXJpYiwg DQppZ21wLCBwaW1zbTQsIHJpcDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzImbmJzcDsgSU5GTyB4 b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiANCis0MDQgbW9kdWxlX21hbmFnZXIuY2MgcnVuIF0gUnVu bmluZyBtb2R1bGU6IGludGVyZmFjZXMgDQooL3Vzci94b3JwLTEuMS9mZWEveG9ycF9mZWEpPEJS PlsgMjAwNS8wNS8xOCAyMjowNDozMiZuYnNwOyBFUlJPUiB4b3JwX2ZlYTo3MzUxIA0KRkVBICs0 MDUgcm91dGluZ19zb2NrZXRfdXRpbHMuY2MgcnRtX2dldF90b19mdGVfY2ZnIF0gQ2Fubm90IG1h cCBhIGRpc2NhcmQgcm91dGUgDQpiYWNrIHRvIGFuIEZFQSBzb2Z0IGRpc2NhcmQgaW50ZXJmYWNl LjxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzImbmJzcDsgRVJST1IgDQp4b3JwX2ZlYTo3MzUxIEZF QSArNDA1IHJvdXRpbmdfc29ja2V0X3V0aWxzLmNjIHJ0bV9nZXRfdG9fZnRlX2NmZyBdIENhbm5v dCBtYXAgYSANCmRpc2NhcmQgcm91dGUgYmFjayB0byBhbiBGRUEgc29mdCBkaXNjYXJkIGludGVy ZmFjZS48QlI+WyAyMDA1LzA1LzE4IA0KMjI6MDQ6MzImbmJzcDsgRVJST1IgeG9ycF9mZWE6NzM1 MSBGRUEgKzQwNSByb3V0aW5nX3NvY2tldF91dGlscy5jYyANCnJ0bV9nZXRfdG9fZnRlX2NmZyBd IENhbm5vdCBtYXAgYSBkaXNjYXJkIHJvdXRlIGJhY2sgdG8gYW4gRkVBIHNvZnQgZGlzY2FyZCAN CmludGVyZmFjZS48QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMzIElORk8geG9ycF9mZWEgQ0xJIF0g Q0xJIGVuYWJsZWQ8QlI+WyANCjIwMDUvMDUvMTggMjI6MDQ6MzMgSU5GTyB4b3JwX2ZlYSBDTEkg XSBDTEkgc3RhcnRlZDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzMgDQpJTkZPIHhvcnBfZmVhIE1G RUEgXSBNRkVBIGVuYWJsZWQ8QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMzIElORk8geG9ycF9mZWEg TUZFQSBdIA0KQ0xJIGVuYWJsZWQ8QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjMzIElORk8geG9ycF9m ZWEgTUZFQSBdIENMSSBzdGFydGVkPEJSPlsgDQoyMDA1LzA1LzE4IDIyOjA0OjMzIElORk8geG9y cF9mZWEgTUZFQSBdIE1GRUEgZW5hYmxlZDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzMgDQpJTkZP IHhvcnBfZmVhIE1GRUEgXSBDTEkgZW5hYmxlZDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzMgSU5G TyB4b3JwX2ZlYSBNRkVBIF0gDQpDTEkgc3RhcnRlZDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6MzQm bmJzcDsgSU5GTyB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArNDA0IA0KbW9kdWxlX21hbmFnZXIu Y2MgcnVuIF0gUnVubmluZyBtb2R1bGU6IGZlYSAoL3Vzci94b3JwLTEuMS9mZWEveG9ycF9mZWEp PEJSPlsgDQoyMDA1LzA1LzE4IDIyOjA0OjM5Jm5ic3A7IEVSUk9SIHhvcnBfZmVhOjczNTEgTElC Q09NTSArNDk5IGNvbW1fc29jay5jIA0KY29tbV9zb2NrX2Nvbm5lY3Q0IF0gRXJyb3IgY29ubmVj dGluZyBzb2NrZXQgKGZhbWlseSA9IDIsIHJlbW90ZV9hZGRyID0gDQoxMjcuMC4wLjEsIHJlbW90 ZV9wb3J0ID0gMTMwMDApOiBDb25uZWN0aW9uIHJlZnVzZWQ8QlI+WyAyMDA1LzA1LzE4IDIyOjA0 OjM5IA0KV0FSTklORyB4b3JwX2ZlYSBGRUEgXSBDb3VsZCBub3Qgb3BlbiB1c2VyLWxldmVsIENs aWNrIHNvY2tldDogQ29ubmVjdGlvbiANCnJlZnVzZWQuIFRyeWluZyBhZ2Fpbi4uLjxCUj5bIDIw MDUvMDUvMTggMjI6MDQ6MzkmbmJzcDsgRVJST1IgeG9ycF9mZWE6NzM1MSANCkxJQkNPTU0gKzQ5 OSBjb21tX3NvY2suYyBjb21tX3NvY2tfY29ubmVjdDQgXSBFcnJvciBjb25uZWN0aW5nIHNvY2tl dCAoZmFtaWx5ID0gDQoyLCByZW1vdGVfYWRkciA9IDEyNy4wLjAuMSwgcmVtb3RlX3BvcnQgPSAx MzAwMCk6IENvbm5lY3Rpb24gcmVmdXNlZDxCUj5bIA0KMjAwNS8wNS8xOCAyMjowNDozOSBXQVJO SU5HIHhvcnBfZmVhIEZFQSBdIENvdWxkIG5vdCBvcGVuIHVzZXItbGV2ZWwgQ2xpY2sgDQpzb2Nr ZXQ6IENvbm5lY3Rpb24gcmVmdXNlZC4gVHJ5aW5nIGFnYWluLi4uPEJSPlsgMjAwNS8wNS8xOCAy MjowNDozOSZuYnNwOyBFUlJPUiANCnhvcnBfZmVhOjczNTEgTElCQ09NTSArNDk5IGNvbW1fc29j ay5jIGNvbW1fc29ja19jb25uZWN0NCBdIEVycm9yIGNvbm5lY3RpbmcgDQpzb2NrZXQgKGZhbWls eSA9IDIsIHJlbW90ZV9hZGRyID0gMTI3LjAuMC4xLCByZW1vdGVfcG9ydCA9IDEzMDAwKTogQ29u bmVjdGlvbiANCnJlZnVzZWQ8QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjM5IFdBUk5JTkcgeG9ycF9m ZWEgRkVBIF0gQ291bGQgbm90IG9wZW4gDQp1c2VyLWxldmVsIENsaWNrIHNvY2tldDogQ29ubmVj dGlvbiByZWZ1c2VkLiBUcnlpbmcgYWdhaW4uLi48QlI+WyAyMDA1LzA1LzE4IA0KMjI6MDQ6NDAm bmJzcDsgRVJST1IgeG9ycF9mZWE6NzM1MSBMSUJDT01NICs0OTkgY29tbV9zb2NrLmMgY29tbV9z b2NrX2Nvbm5lY3Q0IF0gDQpFcnJvciBjb25uZWN0aW5nIHNvY2tldCAoZmFtaWx5ID0gMiwgcmVt b3RlX2FkZHIgPSAxMjcuMC4wLjEsIHJlbW90ZV9wb3J0ID0gDQoxMzAwMCk6IENvbm5lY3Rpb24g cmVmdXNlZDxCUj5bIDIwMDUvMDUvMTggMjI6MDQ6NDAgV0FSTklORyB4b3JwX2ZlYSANClhybEZl YVRhcmdldCBdIEhhbmRsaW5nIG1ldGhvZCBmb3IgZmVhX2NsaWNrLzAuMS9zdGFydF9jbGljayBm YWlsZWQ6IFhybENtZEVycm9yIA0KMTAyIENvbW1hbmQgZmFpbGVkIENvdWxkIG5vdCBvcGVuIHVz ZXItbGV2ZWwgQ2xpY2sgc29ja2V0OiBDb25uZWN0aW9uIA0KcmVmdXNlZDxCUj5bIDIwMDUvMDUv MTggMjI6MDQ6NDAmbmJzcDsgRVJST1IgeG9ycF9ydHJtZ3I6NzM1MCBSVFJNR1IgKzU5NyANCm1h c3Rlcl9jb25mX3RyZWUuY2MgY29tbWl0X3Bhc3MyX2RvbmUgXSBDb21taXQgZmFpbGVkOiAxMDIg Q29tbWFuZCBmYWlsZWQgQ291bGQgDQpub3Qgb3BlbiB1c2VyLWxldmVsIENsaWNrIHNvY2tldDog Q29ubmVjdGlvbiByZWZ1c2VkPEJSPlsgMjAwNS8wNS8xOCANCjIyOjA0OjQwJm5ic3A7IEVSUk9S IHhvcnBfcnRybWdyOjczNTAgUlRSTUdSICsxODIgbWFzdGVyX2NvbmZfdHJlZS5jYyANCmNvbmZp Z19kb25lIF0gQ29uZmlndXJhdGlvbiBmYWlsZWQ6IDEwMiBDb21tYW5kIGZhaWxlZCBDb3VsZCBu b3Qgb3BlbiB1c2VyLWxldmVsIA0KQ2xpY2sgc29ja2V0OiBDb25uZWN0aW9uIHJlZnVzZWQ8QlI+ WyAyMDA1LzA1LzE4IDIyOjA0OjQwJm5ic3A7IElORk8gDQp4b3JwX3J0cm1ncjo3MzUwIFJUUk1H UiArMTQyMCB0YXNrLmNjIHJ1bl90YXNrIF0gTm8gbW9yZSB0YXNrcyB0byBydW48QlI+WyANCjIw MDUvMDUvMTggMjI6MDQ6NDAmbmJzcDsgSU5GTyB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArMjE2 IG1vZHVsZV9tYW5hZ2VyLmNjIA0KdGVybWluYXRlIF0gVGVybWluYXRpbmcgbW9kdWxlOiBmZWE8 QlI+WyAyMDA1LzA1LzE4IDIyOjA0OjQwJm5ic3A7IElORk8gDQp4b3JwX3J0cm1ncjo3MzUwIFJU Uk1HUiArMjE2IG1vZHVsZV9tYW5hZ2VyLmNjIHRlcm1pbmF0ZSBdIFRlcm1pbmF0aW5nIG1vZHVs ZTogDQppbnRlcmZhY2VzPEJSPlsgMjAwNS8wNS8xOCAyMjowNDo0MCZuYnNwOyBJTkZPIHhvcnBf cnRybWdyOjczNTAgUlRSTUdSICsyNjIgDQptb2R1bGVfbWFuYWdlci5jYyB0ZXJtaW5hdGUgXSBL aWxsaW5nIG1vZHVsZTogaW50ZXJmYWNlcyAocGlkID0gNzM1MSk8QlI+WyANCjIwMDUvMDUvMTgg MjI6MDQ6NDAmbmJzcDsgSU5GTyB4b3JwX3J0cm1ncjo3MzUwIFJUUk1HUiArNTQ3IG1vZHVsZV9t YW5hZ2VyLmNjIA0Ka2lsbGVkIF0gTW9kdWxlIGtpbGxlZCBkdXJpbmcgc2h1dGRvd246IGludGVy ZmFjZXM8QlI+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgDQpzaXplPTI+ IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyM8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj5JIGNvbXBpbGVkIFhvcnAgYXQgdGhpcyBlbnZp cm9tZW50OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj5GcmVl QlNEIDQuMTA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+R05V IE1ha2UgMy44MDxCUj5nY2MgdmVyc2lvbiAyLjk1LjQgMjAwMjAzMjAgDQpbRnJlZUJTRF08QlI+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPlRoZSBLZXJuZWwg aGFzIHRoaXMgb3B0aW9ucyANCmNvbXBpbGVkOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyIA0Kc2l6ZT0yPiNNVUxUSUNBU1Q8QlI+b3B0aW9ucyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCk1ST1VUSU5HPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1Db3VyaWVyIA0Kc2l6ZT0yPiNEVU1NWU5FVDxCUj5vcHRpb25zJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRFVNTVlORVQ8QlI+b3B0 aW9ucyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCklQ RklSRVdBTEw8QlI+b3B0aW9ucyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCklQRklSRVdBTExfVkVSQk9TRTxCUj5vcHRpb25zJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KSVBGSVJFV0FMTF9WRVJCT1NFX0xJ TUlUPTU8QlI+b3B0aW9ucyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCklQRklSRVdBTExfRk9SV0FSRDxCUj5vcHRpb25zJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KSVBGVzI8QlI+b3B0aW9ucyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCklQRElWRVJUPEJSPm9w dGlvbnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpI Wj0xMDAwPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPm9wdGlv bnMmbmJzcDsmbmJzcDsmbmJzcDsgDQpJUEZJUkVXQUxMX0RFRkFVTFRfVE9fQUNDRVBUPEJSPm9w dGlvbnMmbmJzcDsmbmJzcDsmbmJzcDsgDQpJUFY2RklSRVdBTEw8QlI+b3B0aW9ucyZuYnNwOyZu YnNwOyZuYnNwOyANCklQVjZGSVJFV0FMTF9WRVJCT1NFPEJSPm9wdGlvbnMmbmJzcDsmbmJzcDsm bmJzcDsgDQpJUFY2RklSRVdBTExfVkVSQk9TRV9MSU1JVDxCUj5vcHRpb25zJm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KSVBWNkZJUkVXQUxMX0RFRkFVTFRfVE9fQUNDRVBUPEJSPjwvRElWPjwvRk9OVD4N CjxESVY+PFBSRT5BdGVuY2lvc2FtZW50ZSwNCg0KPFNUUk9ORz5EaW9nbyBEZWxsYSBUb3JyZXMg T2xpdmVpcmE8L1NUUk9ORz4NCjxBIGhyZWY9Imh0dHA6Ly93d3cuZGVsbGEuZW5nLmJyIj5odHRw Oi8vd3d3LmRlbGxhLmVuZy5icjwvQT4gICAgDQo8QSBocmVmPSJtYWlsdG86ZGlvZ29kdG9AdGVy cmEuY29tLmJyIj5kaW9nb2R0b0B0ZXJyYS5jb20uYnI8L0E+ICAgICAgICAgICAgICANCk1TTjog PEEgaHJlZj0ibWFpbHRvOmRpb2dvZHRvQGhvdG1haWwuY29tIj5kaW9nb2R0b0Bob3RtYWlsLmNv bTwvQT4gICAgICAgICAgICAgICAgICAgICAgDQorNTUgKDYxKSA4NDAxLTcwNzANCg0KPC9QUkU+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_006E_01C55BF5.CB8CBAC0-- From bms@spc.org Thu May 19 12:47:52 2005 From: bms@spc.org (Bruce M Simpson) Date: Thu, 19 May 2005 12:47:52 +0100 Subject: [Xorp-users] compiling problems In-Reply-To: <007101c55c0e$f1835220$01c8a8c0@apolo> References: <007101c55c0e$f1835220$01c8a8c0@apolo> Message-ID: <20050519114752.GB773@empiric.icir.org> On Wed, May 18, 2005 at 10:06:09PM -0300, Diogo Della wrote: > I'm having problems compiling Xorp 1.1. The error messages you report raise the following questions:- Did you create the user and group 'xorp' on your system (as explained in the documentation) ? Did you have any RTF_REJECT or RTF_DISCARD routes in your kernel forwarding table (as shown by netstat -rn) before running XORP? Does your configuration file contain a soft discard interface (needed if you intend to do blackhole routing on FreeBSD or Linux) ? Are you attempting to use Click without having installed it first? From ap010@terra.com.br Fri May 20 15:47:35 2005 From: ap010@terra.com.br (Diogo Della) Date: Fri, 20 May 2005 11:47:35 -0300 Subject: [Xorp-users] compiling problems Message-ID: --_=__=_XaM3_.1116600455.2A.158169.42.18709.52.42.007.507554675 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable For what I read, the documentation do not obligate a xorp group, but I ad= ded and the errors are the same. I don't think I have any RTF_REJECT (Flag R) at netstat as shown in APEND= IX I. About RTF_DISCARD, I did not find at is the flag of this. I did not find what is a soft discard interface and how to configure it a= t the User's Manual and the getting started. I have already installed XORP, but there were some errors as I said previ= ously. What do you mean about Click? Best Regards, Diogo Della ########### APENDIX I ############### router1# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expir= e default 192.168.67.122 UGSc 0 5 sis0 127.0.0.1 127.0.0.1 UH 0 220706 lo0 192.168.67 link#1 UC 11 0 sis0 192.168.67.2 00:60:1d:f4:d3:34 UHLW 0 19674 sis0 116= 9 192.168.67.3 00:60:1d:f4:d2:d6 UHLW 0 10062 sis0 117= 9 192.168.67.5 00:60:94:19:57:4a UHLW 1 2179 sis0 118= 1 192.168.67.49 00:90:4b:4f:85:16 UHLW 0 13083 sis0 80= 3 192.168.67.92 00:20:35:71:d6:e1 UHLW 0 156 sis0 90= 3 192.168.67.93 00:10:b5:54:0a:ac UHLW 0 9 sis0 36= 7 192.168.67.106 00:0c:6e:b2:f2:ef UHLW 1 14005 sis0 118= 4 192.168.67.122 00:80:5f:31:d9:74 UHLW 1 2 sis0 117= 8 192.168.67.126 00:0c:6e:33:0a:94 UHLW 0 147 sis0 80= 0 192.168.67.161 00:0c:6e:00:68:d3 UHLW 0 15 lo0 192.168.67.177 00:01:e6:76:8c:5d UHLW 0 4 sis0 27= 1 192.168.68 link#2 UC 1 0 fxp0 192.168.68.2 00:04:ac:25:ec:e5 UHLW 1 26466 fxp0 117= 6 Internet6: Destination Gateway Flags = Netif Expire ::/96 ::1 UGRSc = lo0 ::1 ::1 UH = lo0 ::ffff:0.0.0.0/96 ::1 UGRSc = lo0 fe80::/10 ::1 UGRSc = lo0 fe80::%sis0/64 link#1 UC = sis0 fe80::20c:6eff:fe00:68d3%sis0 00:0c:6e:00:68:d3 UHL = lo0 fe80::%fxp0/64 link#2 UC = fxp0 fe80::260:94ff:fe63:d554%fxp0 00:60:94:63:d5:54 UHL = lo0 fe80::%lo0/64 fe80::1%lo0 Uc = lo0 fe80::1%lo0 link#5 UHL = lo0 ff01::/32 ::1 U = lo0 ff02::/16 ::1 UGRS = lo0 ff02::%sis0/32 link#1 UC = sis0 ff02::%fxp0/32 link#2 UC = fxp0 ff02::%lo0/32 ::1 UC = lo0 ----- Original Message ----- From: Bruce M Simpson To: Diogo Della Cc: xorp-users@xorp.org Sent: Thursday, May 19, 2005 8:47 AM Subject: Re: [Xorp-users] compiling problems On Wed, May 18, 2005 at 10:06:09PM -0300, Diogo Della wrote: > I'm having problems compiling Xorp 1.1. The error messages you report raise the following questions:- Did you create the user and group 'xorp' on your system (as explained in the documentation) ? Did you have any RTF_REJECT or RTF_DISCARD routes in your kernel forwardi= ng table (as shown by netstat -rn) before running XORP? Does your configuration file contain a soft discard interface (needed if = you intend to do blackhole routing on FreeBSD or Linux) ? Are you attempting to use Click without having installed it first? _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users --_=__=_XaM3_.1116600455.2A.158169.42.18709.52.42.007.507554675 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
For what I read, the documentation do not= obligate a xorp group, but I added and the errors are the same.
 
I don't think I have any RTF_REJECT (Flag= R) at netstat as shown in APENDIX I. About RTF_DISCARD, I did not find a= t is the flag of this.
 
I did not find what is a soft discard int= erface and how to configure it at the User's Manual and the getting start= ed.
 
I have already installed XORP, but there = were some errors as I said previously. What do you mean about Click?
 
Best Regards,
 
Diogo Della
 
########### APENDIX  I #############= ##
router1# netstat -nr=
Routing tables
Internet:
Destina= tion        Gateway   &= nbsp;        Flags    R= efs      Use  Netif Expire
default =            192.168.67.1= 22     UGSc       = 0        5   sis0
127.0.= 0.1          127.0.0.1 =          UH   &nbs= p;      0   220706    l= o0
192.168.67         link#1&n= bsp;            UC=          11   &nbs= p;    0   sis0
192.168.67.2   =     00:60:1d:f4:d3:34  UHLW    &n= bsp;   0    19674   sis0   1= 169
192.168.67.3       00:60:1d:f4:d2:d6=   UHLW        0   = 10062   sis0   1179
192.168.67.5   = ;    00:60:94:19:57:4a  UHLW    &= nbsp;   1     2179   sis0 &n= bsp; 1181
192.168.67.49      00:90:4b:4f:85:1= 6  UHLW        0   = ; 13083   sis0    803
192.168.67.92 &nbs= p;    00:20:35:71:d6:e1  UHLW    =     0      156   sis0&n= bsp;   903
192.168.67.93      00:10= :b5:54:0a:ac  UHLW        0 =        9   sis0   = 367
192.168.67.106     00:0c:6e:b2:f2:ef  UH= LW        1    14005&nb= sp;  sis0   1184
192.168.67.122    = 00:80:5f:31:d9:74  UHLW        1=         2   sis0  = 1178
192.168.67.126     00:0c:6e:33:0a:94  U= HLW        0    &n= bsp; 147   sis0    800
192.168.67.161 &n= bsp;   00:0c:6e:00:68:d3  UHLW    &nbs= p;   0       15   = lo0
192.168.67.177     00:01:e6:76:8c:5d  UH= LW        0    &nb= sp;   4   sis0    271
192.168.68&nb= sp;        link#2   &nb= sp;         UC   &= nbsp;      1      =   0   fxp0
192.168.68.2     &n= bsp; 00:04:ac:25:ec:e5  UHLW      &nbs= p; 1    26466   fxp0   1176
Internet6:
Destin= ation           &n= bsp;           Gateway&= nbsp;           &n= bsp;          Flags &nb= sp;    Netif Expire
::/96     =             &= nbsp;           ::1&nbs= p;            = ;            =   UGRSc       lo0
::1  &n= bsp;           &nb= sp;           &nbs= p;    ::1        &= nbsp;           &n= bsp;      UH      =     lo0
::ffff:0.0.0.0/96     =             ::1&nb= sp;           &nbs= p;            = ;  UGRSc       lo0
fe80::/10 &= nbsp;           &n= bsp;           ::1 = ;            =             &= nbsp; UGRSc       lo0
fe80::%sis0/64&nbs= p;            = ;       link#1     = ;            =        UC     &nbs= p;   sis0
fe80::20c:6eff:fe00:68d3%sis0   &nb= sp; 00:0c:6e:00:68:d3        &nbs= p;    UHL         = lo0
fe80::%fxp0/64        &nbs= p;           link#2&nbs= p;            = ;           UC &nb= sp;       fxp0
fe80::260:94ff:fe63:d554%= fxp0     00:60:94:63:d5:54    &nb= sp;        UHL    =      lo0
fe80::%lo0/64    &nbs= p;            = ;    fe80::1%lo0       =             Uc&nbs= p;         lo0
fe80::1%lo0&nbs= p;            = ;          link#5  = ;            =           UHL  &nb= sp;      lo0
ff01::/32    = ;            =          ::1   &nb= sp;           &nbs= p;           U &nb= sp;         lo0
ff02::/16 = ;            =             ::1&nb= sp;           &nbs= p;            = ;  UGRS        lo0
ff02::%sis0= /32           &nbs= p;        link#1   &nbs= p;            = ;        UC    &nb= sp;    sis0
ff02::%fxp0/32     = ;            =    link#2         =             &= nbsp;  UC         fxp0
ff= 02::%lo0/32          &n= bsp;          ::1  = ;            =              = UC          lo0
 
----- Original Message -----
Sent: Thursday, May 19, 2005 8:47 AM
Subject: Re: [Xorp-users] compiling problems

On Wed, May 18, 2005 at 10:06:09PM -0300, Diogo Della wrot= e:
> I'm having problems compiling Xorp 1.1.

The error messa= ges you report raise the following questions:-

Did you create the = user and group 'xorp' on your system (as explained
in the documentatio= n) ?

Did you have any RTF_REJECT or RTF_DISCARD routes in your ker= nel forwarding
table (as shown by netstat -rn) before running XORP?
Does your configuration file contain a soft discard interface (neede= d if you
intend to do blackhole routing on FreeBSD or Linux) ?

= Are you attempting to use Click without having installed it first?
___= ____________________________________________
Xorp-users mailing listXorp-users@xorp.o= rg
http://mailman.ICSI.Berkeley.EDU/mailman/list= info/xorp-users
--_=__=_XaM3_.1116600455.2A.158169.42.18709.52.42.007.507554675-- From Norbert.Chan@gdcanada.com Fri May 20 17:51:47 2005 From: Norbert.Chan@gdcanada.com (Chan, Norbert) Date: Fri, 20 May 2005 10:51:47 -0600 Subject: [Xorp-users] Simulating multiple routers on a single platform Message-ID: <0843D0F1EEBB2E49A2156C6981B4A17E97CA0C@CGYSVW100.gdcan.com> Hi all, I am in the process of planning a lab setup where I am interested in simulating the behavior of 100 routers. Due to equipment and financial constraints, I may only be able to purchase 10 routers and computers. Does anyone have any experience in being able to have a computer (running XORP) act like 10 routers? In other words, I have software code for one router, but would like to have the ability to provide a network of 10 routers (say, with only a couple of routers). I am interested in the clustering behavior of large nodes, but setting up 100 nodes is arduous and expensive. An alternate solution is to find a tool that generates exactly the traffic from each and every node but that is extremely difficult without knowing the individual router characteristics. If anyone has any ideas or references, I would appreciate it. I'm a newcomer to this forum, so I hope my question is directed to the right area. Regards Norbert Chan Systems Engineer General Dynamics Canada The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From pavlin@icir.org Fri May 20 20:42:15 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 20 May 2005 12:42:15 -0700 Subject: [Xorp-users] compiling problems In-Reply-To: Message from "Diogo Della" of "Fri, 20 May 2005 11:47:35 -0300." Message-ID: <200505201942.j4KJgFKv008334@possum.icir.org> > For what I read, the documentation do not obligate a xorp group, but I ad= > ded and the errors are the same. >From reading the source code related to the error, it appears that you have some users that belong to group "xorp", but somehow the system doesn't recognize that group (system library call to getgrnam("xorp") fails). Could you verify that your /etc/group file contains a line for group "xorp", and that line lists all users that are suppose to belong to that group. A simple way of testing that the change has taken effect is to run "id ". > I don't think I have any RTF_REJECT (Flag R) at netstat as shown in APEND= > IX I. About RTF_DISCARD, I did not find at is the flag of this. > > I did not find what is a soft discard interface and how to configure it a= > t the User's Manual and the getting started. You can ignore the "Cannot map a discard route back to an FEA soft discard interface" errors, because those are harmless during startup. They are leftover from some earlier FEA mods and should be cleanup in the future. > I have already installed XORP, but there were some errors as I said previ= > ously. What do you mean about Click? If you started with config.boot.sample configuration, it has "click {}" subsection inside the "fea{}" section. If you don't use Click for forwarding, then delete the "click {}" subsection. Regards, Pavlin From pavlin@icir.org Fri May 20 20:56:57 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 20 May 2005 12:56:57 -0700 Subject: [Xorp-users] Simulating multiple routers on a single platform In-Reply-To: Message from "Chan, Norbert" of "Fri, 20 May 2005 10:51:47 MDT." <0843D0F1EEBB2E49A2156C6981B4A17E97CA0C@CGYSVW100.gdcan.com> Message-ID: <200505201957.j4KJuvD8008449@possum.icir.org> > I am in the process of planning a lab setup where I am interested > in simulating the behavior of 100 routers. Due to equipment and > financial constraints, I may only be able to purchase 10 routers > and computers. Does anyone have any experience in being able to > have a computer (running XORP) act like 10 routers? In other > words, I have software code for one router, but would like to > have the ability to provide a network of 10 routers (say, with > only a couple of routers). I am interested in the clustering > behavior of large nodes, but setting up 100 nodes is arduous and > expensive. An alternate solution is to find a tool that generates > exactly the traffic from each and every node but that is extremely > difficult without knowing the individual router characteristics. > > If anyone has any ideas or references, I would appreciate it. I'm > a newcomer to this forum, so I hope my question is directed to the > right area. IMUNES should be the perfect candidate for you: http://www.imunes.org/ Basically, you need to install FreeBSD and apply the IMUNES patch to the kernel. Then you can use the cool GUI to create virtual nodes within the same machine. Each node can run the routing software of your choice. You can choose even to connect some of those nodes to any of the physical network interface on the system so your virtual nodes can communicate with the rest of the world. In other words, install IMUNES on 10 FreeBSD boxes and within each box create a virtual topology of 10 IMUNES nodes (each INUMES node running XORP or anything else you like). Interconnect the 10 FreeBSD boxes in any way you want, and this will give you 100 routers in the same topology. Marko Zec (the INUMES author) should be on this mailing list so he can give you more information. Regards, Pavlin From ap010@terra.com.br Fri May 27 17:04:52 2005 From: ap010@terra.com.br (Diogo Della) Date: Fri, 27 May 2005 13:04:52 -0300 Subject: [Xorp-users] multicast problem Message-ID: --_=__=_XaM3_.1117209892.2A.864940.42.7401.52.42.007.1915648451 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have tried initially to use mrouted of FreeBSD. It does not work. Then I installed xorp and properly configured it, but it does not seems t= o work too. The traffic (udp packets) of one interface it is not routed to the other = on the two tries (mrouted and xorp). I am using PIM-SM, than the traffic = should not be replicated to all interfaces, but there is proporly igmp me= mbership request and pim join running on the network. The architeture is: C1 --192.168.67.0/24 -- R1 --192.168.68.0/24-- R2 --192.168.69.0/24-- C2= The video (multicast traffic) flows from C2 to C1. C1 sends IGMP Membership Report. R2 receives PIM join. R2 is set as a sta= tic RP and this seems to be well configured as it can be seem with show p= im rps. "show pim mfc" and "show pim mrib" returns nothing. I think this is not c= onstructing the table but I cant figure out why. I made another test, taking of R2 and running Xorp to route multicast pac= kets from 192.168.68.0/24 to 192.168.67.0/24. Nothing again. I tried the = same with mrouted that should send the traffic to every interface other t= han where it receives the traffic. Againg nothig. Can anyone help me? Additional information: 1- Kernel recompiled with the following options: options MROUTING options PIM options IPFW options DUMMYNET and other more of ipfw, ipfw2 and etc.. 2- Xorp is configured for igmp rip interfaces pim4sm mfea fea Thank you all! Diogo Della --_=__=_XaM3_.1117209892.2A.864940.42.7401.52.42.007.1915648451 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have tried initially to use mrouted of FreeBSD. It does not work.<= /DIV>
 
Then I installed xorp and properly configured it, but it does not se= ems to work too.
 
The traffic (udp packets) of one interface it is not routed to the o= ther on the two tries (mrouted and xorp). I am using PIM-SM, than the tra= ffic should not be replicated to all interfaces, but there is proporly ig= mp membership request and pim join running on the network.
 
The architeture is:
 
C1 --192.168.67.0/24 --  R1 --192.168.68.0/24-- R2 --192.168.69= .0/24-- C2
 
The video (multicast traffic) flows from C2 to C1.
 
C1 sends IGMP Membership Report. R2 receives PIM join. R2 is set as = a static RP and this seems to be well configured as it can be seem with s= how pim rps.
 
"show pim mfc" and "show pim mrib" returns nothing. I think this is = not constructing the table but I cant figure out why.
 
I made another test, taking of R2 and running Xorp to route multicas= t packets from 192.168.68.0/24 to 192.168.67.0/24. Nothing again. I tried= the same with mrouted that should send the traffic to every interface ot= her than where it receives the traffic. Againg nothig.
 
Can anyone help me?
 
Additional information:
1- Kernel recompiled with the following options:
options MROUTING
options PIM
options IPFW
options DUMMYNET
and other more of ipfw, ipfw2 and etc..
 
2- Xorp is configured for
igmp
rip
interfaces
pim4sm
mfea
fea
 
Thank you all!
 
Diogo Della
 
--_=__=_XaM3_.1117209892.2A.864940.42.7401.52.42.007.1915648451-- From pavlin@icir.org Fri May 27 17:46:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 27 May 2005 09:46:24 -0700 Subject: [Xorp-users] multicast problem In-Reply-To: Message from "Diogo Della" of "Fri, 27 May 2005 13:04:52 -0300." Message-ID: <200505271646.j4RGkOR7012655@possum.icir.org> > I have tried initially to use mrouted of FreeBSD. It does not work. > > Then I installed xorp and properly configured it, but it does not seems t= > o work too. > > The traffic (udp packets) of one interface it is not routed to the other = > on the two tries (mrouted and xorp). I am using PIM-SM, than the traffic = > should not be replicated to all interfaces, but there is proporly igmp me= > mbership request and pim join running on the network. > > The architeture is: > > C1 --192.168.67.0/24 -- R1 --192.168.68.0/24-- R2 --192.168.69.0/24-- C2= > > > The video (multicast traffic) flows from C2 to C1. > > C1 sends IGMP Membership Report. R2 receives PIM join. R2 is set as a sta= > tic RP and this seems to be well configured as it can be seem with show p= > im rps. > > "show pim mfc" and "show pim mrib" returns nothing. I think this is not c= > onstructing the table but I cant figure out why. > > I made another test, taking of R2 and running Xorp to route multicast pac= > kets from 192.168.68.0/24 to 192.168.67.0/24. Nothing again. I tried the = > same with mrouted that should send the traffic to every interface other t= > han where it receives the traffic. Againg nothig. > > Can anyone help me? > > Additional information: > 1- Kernel recompiled with the following options: > options MROUTING > options PIM > options IPFW > options DUMMYNET > and other more of ipfw, ipfw2 and etc.. > > 2- Xorp is configured for > igmp > rip > interfaces > pim4sm > mfea > fea You need to configure fib2mrib as well. Also, make sure that the TTL of the multicast packets is large enough to reach the receiver. If things still don't work, make sure that there are no firewall rules that filter-out the multicast traffic. Regards, Pavlin From mehdi.bensaid@rd.francetelecom.com Mon May 30 10:03:53 2005 From: mehdi.bensaid@rd.francetelecom.com (zze-BEN SAID Mehdi RD-CORE-ISS) Date: Mon, 30 May 2005 11:03:53 +0200 Subject: [Xorp-users] MIB Message-ID: Hi, I want to extract information from RIB (Routing Information Base) such as: routes, flow sources and destinations; IGMP groups, how many time a multicast flow is replicated, etc... To be clearer, I want to query the RIB. Is that possible? Thanks for help. Best Regards Mehdi From chethana_ps@yahoo.com Mon May 30 13:58:38 2005 From: chethana_ps@yahoo.com (Chethana Savalgi) Date: Mon, 30 May 2005 05:58:38 -0700 (PDT) Subject: [Xorp-users] Could not download XORP 1.1 live CD Message-ID: <20050530125838.86033.qmail@web50305.mail.yahoo.com> Hello , We could not download the XORP 1.1 live CD from http://www.xorp.org and the mirror site : http://www2.xorp.org/ The download program gets into infinite loop and the image it is trying to download, grows to 500+ MB (which is more than the specified size , 132MB. ) Could you please let us know , if this is a temporary problem and fixed soon. Also please specify an alternate location (if exists) for downloading the image. thanks Chethana __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From M.Handley@cs.ucl.ac.uk Mon May 30 15:38:52 2005 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 30 May 2005 15:38:52 +0100 Subject: [Xorp-users] Could not download XORP 1.1 live CD In-Reply-To: Your message of "Mon, 30 May 2005 05:58:38 PDT." <20050530125838.86033.qmail@web50305.mail.yahoo.com> Message-ID: <900.1117463932@vulture.xorp.org> >We could not download the XORP 1.1 live CD from > >http://www.xorp.org and >the mirror site : >http://www2.xorp.org/ > >The download program gets into infinite loop and the >image it is trying to download, grows to 500+ MB >(which is more than the specified size , 132MB. ) Maybe your downloading software is uncompressing the gzipped ISO on the fly? If so, then you'd expect the resulting image to be 584MB (613341184 bytes) bytes in size. The uncompressed ISO should have an MD5 checksum of: ca60c040f3366f517ebf12da353b7a8a Cheers, Mark From pavlin@icir.org Mon May 30 18:04:24 2005 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 30 May 2005 10:04:24 -0700 Subject: [Xorp-users] MIB In-Reply-To: Message from "zze-BEN SAID Mehdi RD-CORE-ISS" of "Mon, 30 May 2005 11:03:53 +0200." Message-ID: <200505301704.j4UH4OkV049590@possum.icir.org> > I want to extract information from RIB (Routing Information Base) such > as: routes, flow sources and destinations; IGMP groups, how many time a > multicast flow is replicated, etc... To be clearer, I want to query the > RIB. Is that possible? Can you clarify what you mean by "routes". The RIB contains only the routes used for unicast routing (URIB), and the MRIB routes used by multicast routing protocols to obtain the Reverse Path Forwarding information. That information can be obtained by the "show route table ..." xorpsh commands. The PIM-SM module itself contains the PIM-SM derived multicast routing information (the so-called Tree Information Base (TIB)). You can see that information by the "show pim join" xorpsh command. The PIM-SM module also contains the multicast forwarding information that is installed in the kernel. That information is per source-group and can be obtained by the "show pim mfc" xorpsh command. The info contains the incoming interface and the set of outgoing interfaces. The IGMP group information can be obtained from the IGMP module by the "show igmp group" xorpsh command. Currently, the only MIB implemented in XORP is for BGP so if you want to use SNMP to obtain the above information you have to implement the corresponding MIBs. The mibs/README, the "XORP SNMP Agent" document (http://www.xorp.org/design_docs.html), and the BGP MIB implementation can be a starting point. Regards, Pavlin