From phil.wiggins at gmail.com Tue Sep 11 12:52:15 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Tue, 11 Sep 2012 16:52:15 -0300 Subject: [Xorp-users] RIP over GRE issue Message-ID: We have an issue with RIP over GRE which we can resolve with other routers, but not with XORP. A file is attached with detailed linux network commands as well as XORP config.boot files for each node described. Context: ====== We have three routers (n3, n14 and n20) which connect over an intermediate network that is statically linked. The physical interface to the non-private network is statically routed to its remote private neighbour; for example, n3 has static routes to n14 and n20, n14 has static routes to n3 and n20, and n20 has reciprocal routes to n3 and n14.. n3 has an interface 10.0.4.1, n14 has an interface 10.0.9.1, and n20 has an interface 10.0.0.1. An external network connects n3, n14, and n20 together. GRE tunnels: ========== Each router is linked via GRE tunnels with n3 acting as the central point of distribution. Tunnels GRE1 on n3 and GRE2 on n14 are mated and tunnels GRE5 n3 and GRE6 on n20 are also mated. GRE1 is 20.0.0.1 and GRE2 is 20.0.0.2 in subnet 20.0.0.0/30 while GRE5 is 20.0.0.5 and GRE6 is 20.0.0.6 in subnet 20.0.0.4/30. We are running RIP over the GRE tunnels to link the n3, n14 and n20 routers. RIP routing: ========= To establish the RIP routing plane, we have added the gre interfaces n3 (gre1, gre5), n14 (gre2), and n20 (gre6) plus an assortment of local ethxx interfaces for the attached subnets. We have deliberately excluded the statically routed physical interfaces that the GRE tunnel runs over. For example, on node n3, eth1 (10.0.4.1) is not declared in xorp, but the gre interfaces are. The four tunnel endpoints are pingable. The ingress interface at each remote router is pingable (10.0.4.1, 10.0.9.1, 10.0.0.1). A traceroute verifies that the path goes over the GRE tunnel in each case. RIP over GRE issue: ================ Each router (n3, n14, and n20) also has two attached subnets which also run RIP, with the exception of n3 which has 1 subnet running RIP and 1 subnet running OSPF. When running RIP, n3, n14 and n20 see RIP peers from the attached subnets, but not over the GRE tunnels. Wireshark was used to instrument the interfaces and we can see well-formed RIP packets going over the tunnels. To verify the tunnels further, we replaced XORP with Quagga which was able to establish RIP peering and then converged as a network. I hope that describes the problem well enough. Thanks for any help that you can provide. Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120911/3c92b61d/attachment.html -------------- next part -------------- On node n3 ========== /sbin/ip route add 10.0.0.0/24 via 10.0.4.2 /sbin/ip route add 10.0.9.0/24 via 10.0.4.2 #GRE tunnel on n3 ip tunnel add gre1 mode gre remote 10.0.9.1 local 10.0.4.1 ttl 64 ip link set gre1 up ip link set gre1 multicast on ip addr add 20.0.0.1 dev gre1 #ip route add 20.0.0.0/30 dev gre1 #GRE tunnel on n3 ip tunnel add gre5 mode gre remote 10.0.0.1 local 10.0.4.1 ttl 64 ip link set gre5 up ip link set gre5 multicast on ip addr add 20.0.0.5 dev gre5 #ip route add 20.0.0.4/30 dev gre5 On node n14 =========== /sbin/ip route add 10.0.0.0/24 via 10.0.9.2 /sbin/ip route add 10.0.4.0/24 via 10.0.9.2 #GRE tunnel on n14 ip tunnel add gre2 mode gre remote 10.0.4.1 local 10.0.9.1 ttl 64 ip link set gre2 up ip link set gre2 multicast on ip addr add 20.0.0.2 dev gre2 #ip route add 20.0.0.0/30 dev gre2 On node n20 =========== /sbin/ip route add 10.0.9.0/24 via 10.0.0.2 /sbin/ip route add 10.0.4.0/24 via 10.0.0.2 #GRE tunnel on n20 ip tunnel add gre6 mode gre remote 10.0.4.1 local 10.0.0.1 ttl 64 ip link set gre6 up ip link set gre6 multicast on ip addr add 20.0.0.6 dev gre6 #ip route add 20.0.0.4/30 dev gre6 config.boot on node n3 ====================== interfaces { interface eth0 { vif eth0 { address 10.254.80.1 { prefix-length: 16 } address fe80::200:ff:fe00:0 { prefix-length: 64 } } } interface eth2 { vif eth2 { address 10.0.6.2 { prefix-length: 24 } address fe80::200:ff:feaa:3a { prefix-length: 64 } } } interface gre1 { vif gre1 { address 20.0.0.1 { prefix-length: 30 } } } interface gre5 { vif gre5 { address 20.0.0.5 { prefix-length: 30 } } } } fea { unicast-forwarding4 { disable:false } } protocols { ospf4 { export: "RIPtoOSPF4" router-id: 10.254.80.1 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.254.80.1 { priority: 1 hello-interval: 10 router-dead-interval: 40 disable: false } } } } } rip { export: "OSPF4toRIP" interface eth0 { vif eth0 { address 10.254.80.1 { disable: false } } } interface eth2 { vif eth2 { address 10.0.6.2 { disable: false } } } interface gre1 { vif gre1 { address 20.0.0.1 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } interface gre5 { vif gre5 { address 20.0.0.5 { disable: false metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } } } policy { policy-statement RIPtoOSPF4 { term 10 { from { protocol: "rip" } then { external-type: 1 } } term 20 { from { protocol: "connected" } then { external-type: 1 } } } } policy { policy-statement OSPF4toRIP { term 10 { from { protocol: "ospf4" } } term 20 { from { protocol: "connected" } } } } config.boot on node n14 ======================= interfaces { interface eth0 { vif eth0 { address 10.0.7.2 { prefix-length: 24 } address fe80::200:ff:feaa:6b { prefix-length: 64 } } } interface eth1 { vif eth1 { address 10.0.8.1 { prefix-length: 24 } address fe80::200:ff:feaa:6c { prefix-length: 64 } } } interface gre2 { vif gre2 { address 20.0.0.2 { prefix-length: 30 } } } } fea { unicast-forwarding4 { disable:false } } policy { policy-statement export-connected { term 100 { from { protocol: "connected" } } } } protocols { rip { export: "export-connected" interface eth0 { vif eth0 { address 10.0.7.2 { disable: false } } } interface eth1 { vif eth1 { address 10.0.8.1 { disable: false } } } interface gre2 { vif gre2 { address 20.0.0.2 { disable: false metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } } } config.boot on n20 ================== interfaces { interface gre6 { vif gre6 { address 20.0.0.6 { prefix-length: 30 } } } interface eth1 { vif eth1 { address 10.0.12.1 { prefix-length: 24 } address fe80::200:ff:feaa:159 { prefix-length: 64 } } } interface eth2 { vif eth2 { address 10.0.13.1 { prefix-length: 24 } address fe80::200:ff:feaa:15b { prefix-length: 64 } } } } fea { unicast-forwarding4 { disable:false } } policy { policy-statement export-connected { term 100 { from { protocol: "connected" } } } } protocols { rip { export: "export-connected" interface gre6 { vif gre6 { address 20.0.0.6 { metric: 1 horizon: "split-horizon-poison-reverse" disable: false passive: false accept-non-rip-requests: true accept-default-route: true advertise-default-route: true route-timeout: 180 deletion-delay: 120 triggered-delay: 3 triggered-jitter: 66 update-interval: 30 update-jitter: 16 request-interval: 30 interpacket-delay: 50 } } } interface eth1 { vif eth1 { address 10.0.12.1 { disable: false } } } interface eth2 { vif eth2 { address 10.0.13.1 { disable: false } } } } } From greearb at candelatech.com Fri Sep 14 09:10:35 2012 From: greearb at candelatech.com (Ben Greear) Date: Fri, 14 Sep 2012 09:10:35 -0700 Subject: [Xorp-users] RIP over GRE issue In-Reply-To: References: Message-ID: <505356FB.90500@candelatech.com> On 09/11/2012 12:52 PM, Phil Wiggins wrote: > We have an issue with RIP over GRE which we can resolve with other routers, but not with XORP. A file is attached with detailed linux network commands as well > as XORP config.boot files for each node described. We fixed some GRE issues sometime around last spring I think...please try the top-of-tree from github if you are using an older release. It's always good to report exactly what version of xorp you are using when reporting problems.... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From phil.wiggins at gmail.com Fri Sep 14 09:31:25 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Fri, 14 Sep 2012 13:31:25 -0300 Subject: [Xorp-users] RIP over GRE issue In-Reply-To: <505356FB.90500@candelatech.com> References: <505356FB.90500@candelatech.com> Message-ID: OK..thanks Ben. We've been using stock xorp-1.8.5. We'll try the latest git tree. Has the 15-part patch from Igor with the new RR operators been applied in git as well? If I recall there are different git branches that you each maintain. Phil On Fri, Sep 14, 2012 at 1:10 PM, Ben Greear wrote: > On 09/11/2012 12:52 PM, Phil Wiggins wrote: > >> We have an issue with RIP over GRE which we can resolve with other >> routers, but not with XORP. A file is attached with detailed linux network >> commands as well >> as XORP config.boot files for each node described. >> > > We fixed some GRE issues sometime around last spring I think...please try > the > top-of-tree from github if you are using an older release. > > It's always good to report exactly what version of xorp you > are using when reporting problems.... > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120914/dc7c4e44/attachment.html From greearb at candelatech.com Fri Sep 14 09:58:00 2012 From: greearb at candelatech.com (Ben Greear) Date: Fri, 14 Sep 2012 09:58:00 -0700 Subject: [Xorp-users] RIP over GRE issue In-Reply-To: References: <505356FB.90500@candelatech.com> Message-ID: <50536218.8050701@candelatech.com> On 09/14/2012 09:31 AM, Phil Wiggins wrote: > OK..thanks Ben. We've been using stock xorp-1.8.5. We'll try the latest git tree. > > Has the 15-part patch from Igor with the new RR operators been applied in git as well? If I recall there are different git branches that you each maintain. > > Phil I haven't applied his latest series yet...might wait until he's back from vacation in case it causes issues... Ben > > On Fri, Sep 14, 2012 at 1:10 PM, Ben Greear > wrote: > > On 09/11/2012 12:52 PM, Phil Wiggins wrote: > > We have an issue with RIP over GRE which we can resolve with other routers, but not with XORP. A file is attached with detailed linux network commands > as well > as XORP config.boot files for each node described. > > > We fixed some GRE issues sometime around last spring I think...please try the > top-of-tree from github if you are using an older release. > > It's always good to report exactly what version of xorp you > are using when reporting problems.... > > Thanks, > Ben > > -- > Ben Greear > > Candela Technologies Inc http://www.candelatech.com > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From phil.wiggins at gmail.com Fri Sep 14 12:41:37 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Fri, 14 Sep 2012 16:41:37 -0300 Subject: [Xorp-users] RIP over GRE issue In-Reply-To: <50536218.8050701@candelatech.com> References: <505356FB.90500@candelatech.com> <50536218.8050701@candelatech.com> Message-ID: One of our team members found the fix: "...The packet was being dropped because it didn't know the ip of the other end of the tunnel. So it was setting it's own IP as the both ends. If you go to xrl_port_manager.cc:234 endpoint_addr() had both IPs as the local IP. So to fix this you need to set the destination of tunnel in the config so: (For N14) interface gre2 { vif gre2 { address 20.0.0.2 { prefix-length: 30 destination: 20.0.0.1 } } } Just do this for every tunnel iface and it works. ..." I confirmed that this fix works in 1.8.5 and in xorp-head pulled today. Phil On Fri, Sep 14, 2012 at 1:58 PM, Ben Greear wrote: > > On 09/14/2012 09:31 AM, Phil Wiggins wrote: >> >> OK..thanks Ben. We've been using stock xorp-1.8.5. We'll try the latest git tree. >> > From sumi.techno at gmail.com Wed Sep 26 06:28:37 2012 From: sumi.techno at gmail.com (sumi) Date: Wed, 26 Sep 2012 18:58:37 +0530 Subject: [Xorp-users] XORP 1.5 PIM_HELLO from a specific interface IP In-Reply-To: References: Message-ID: Hi All, Is there a way to force the PIM to use a specific interface IP to send the PIM_HELLO messages? Or is it by design that it uses the lowest interface IP? I have few alias IP's configured in my XORP router and it always uses the smallest IP's in the list to send the PIM_HELLO. Looked around some of the documents and release notes of XORP 1.5, it documents: LIBXIPC: - Bug fix in the internal mechanism for obtaining the IPv4 addresses from the system. After the bug fix, a secondary (alias) IP address can be specified with the "-i " command-line option to the xorp_rtrmgr or xorp_finder binaries. But i do not see any config option with xorpsh. Plz let me know if you have the insight. Thanks, Niki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120926/b845b3ae/attachment.html From greearb at candelatech.com Wed Sep 26 07:46:06 2012 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2012 07:46:06 -0700 Subject: [Xorp-users] XORP 1.5 PIM_HELLO from a specific interface IP In-Reply-To: References: Message-ID: <5063152E.5070009@candelatech.com> On 09/26/2012 06:28 AM, sumi wrote: > Hi All, > Is there a way to force the PIM to use a specific interface IP to send the PIM_HELLO messages? Or is it by design that it uses the lowest interface IP? > > I have few alias IP's configured in my XORP router and it always uses the smallest IP's in the list to send the PIM_HELLO. > Looked around some of the documents and release notes of XORP 1.5, it documents: > > LIBXIPC: > - Bug fix in the internal mechanism for obtaining the IPv4 addresses > from the system. After the bug fix, a secondary (alias) IP address > can be specified with the "-i " command-line option to > the xorp_rtrmgr or xorp_finder binaries. That comment doesn't apply to PIM I think, just the xorp internal process communication API. Not sure there is a way to do what you want in the current code... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From matsuzaki at nclc.co.jp Wed Sep 26 19:43:40 2012 From: matsuzaki at nclc.co.jp (M.Matsuzaki) Date: Thu, 27 Sep 2012 11:43:40 +0900 Subject: [Xorp-users] Allowance XORP logo use. Message-ID: <20120927114336.2113.6A5851DA@nclc.co.jp> Hello Xorp team stuff We are NCL communication, a distributor of Pica8 in Japan. I am a Director of NCLC. (See our web site for your refference, http://www.nclc.co.jp.) We need to expose XORP logo because we would like to explain Pica8 architecture on it. Could you allow us to use XORP logo in our Web site? I'm looking forward to get your good reply. Best Regards M.Matsuzaki mail: matsuzaki at nclc.co.jp NCL Communications K.K. From greearb at candelatech.com Wed Sep 26 20:59:12 2012 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2012 20:59:12 -0700 Subject: [Xorp-users] Allowance XORP logo use. In-Reply-To: <20120927114336.2113.6A5851DA@nclc.co.jp> References: <20120927114336.2113.6A5851DA@nclc.co.jp> Message-ID: <5063CF10.6040108@candelatech.com> On 09/26/2012 07:43 PM, M.Matsuzaki wrote: > Hello Xorp team stuff > > We are NCL communication, a distributor of Pica8 in Japan. > I am a Director of NCLC. > (See our web site for your refference, http://www.nclc.co.jp.) > We need to expose XORP logo because we would like to explain Pica8 > architecture on it. > Could you allow us to use XORP logo in our Web site? > I'm looking forward to get your good reply. I think that would be fine, but please make sure you add a link back to the xorp.org site as well. Thanks, Ben > > Best Regards > M.Matsuzaki > mail: matsuzaki at nclc.co.jp > NCL Communications K.K. > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From matsuzaki at nclc.co.jp Wed Sep 26 23:58:02 2012 From: matsuzaki at nclc.co.jp (M.Matsuzaki) Date: Thu, 27 Sep 2012 15:58:02 +0900 Subject: [Xorp-users] Allowance XORP logo use. In-Reply-To: <5063CF10.6040108@candelatech.com> References: <20120927114336.2113.6A5851DA@nclc.co.jp> <5063CF10.6040108@candelatech.com> Message-ID: <20120927155755.2153.6A5851DA@nclc.co.jp> Ben san, Thank you for your reply. We will add the link back on the Logo. Best Regards M.Matsuzaki mail: matsuzaki at nclc.co.jp NCL Communications K.K. ----------------------- Original Message ----------------------- On Wed, 26 Sep 2012 20:59:12 -0700 Ben Greear wrote: > On 09/26/2012 07:43 PM, M.Matsuzaki wrote: > > Hello Xorp team stuff > > > > We are NCL communication, a distributor of Pica8 in Japan. > > I am a Director of NCLC. > > (See our web site for your refference, http://www.nclc.co.jp.) > > We need to expose XORP logo because we would like to explain Pica8 > > architecture on it. > > Could you allow us to use XORP logo in our Web site? > > I'm looking forward to get your good reply. > > I think that would be fine, but please make sure you add a link > back to the xorp.org site as well. > > Thanks, > Ben > > > > > Best Regards > > M.Matsuzaki > > mail: matsuzaki at nclc.co.jp > > NCL Communications K.K. > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > From mackay.jm at gmail.com Fri Sep 28 11:28:24 2012 From: mackay.jm at gmail.com (Jean Michel MacKay) Date: Fri, 28 Sep 2012 14:28:24 -0400 Subject: [Xorp-users] xorpsh and ip route not matching Message-ID: Hi everyone, I seem to getting some weird results from xorpsh, where it doesn't match the expected results but that are shown in 'ip route'. Don't mind the excessive metrics for RIP, just some tweaks to the rib. Here's what I get show route table ipv4 unicast final terse Destination P Prf Metric 1 Next hop 10.0.0.0/24 r 110 23884 10.0.1.2 10.0.1.0/24 c 0 0 eth0/eth0 10.0.2.0/24 r 110 16942 10.0.5.2 10.0.3.0/24 r 110 16942 10.0.5.2 10.0.4.0/24 r 110 16942 10.0.5.2 10.0.5.0/24 c 0 0 eth1/eth1 10.0.6.0/24 c 0 0 eth2/eth2 10.0.7.0/24 r 110 23884 10.0.1.2 10.0.8.0/24 r 110 23884 10.0.1.2 10.0.9.0/24 r 110 23884 10.0.1.2 10.0.10.0/24 r 110 23884 10.0.1.2 10.0.11.0/24 r 110 20413 10.0.1.2 10.0.12.0/24 r 110 16942 10.0.1.2 ip route 10.0.12.0/24 via 10.0.1.2 dev eth0 proto xorp metric 16942 notify 10.0.4.0/24 via 10.0.5.2 dev eth1 proto xorp metric 16942 notify 10.0.5.0/24 dev eth1 proto kernel scope link src 10.0.5.1 10.0.6.0/24 dev eth2 proto kernel scope link src 10.0.6.1 10.0.7.0/24 via 10.0.6.2 dev eth2 proto xorp metric 11 notify 10.0.0.0/24 via 10.0.6.2 dev eth2 proto xorp metric 1 notify 10.0.8.0/24 via 10.0.6.2 dev eth2 proto xorp metric 11 notify 10.0.9.0/24 via 10.0.6.2 dev eth2 proto xorp metric 21 notify 10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.1 10.0.10.0/24 via 10.0.6.2 dev eth2 proto xorp metric 21 notify 10.0.2.0/24 via 10.0.5.2 dev eth1 proto xorp metric 16942 notify 10.0.11.0/24 via 10.0.6.2 dev eth2 proto xorp metric 1 notify 10.0.3.0/24 via 10.0.5.2 dev eth1 proto xorp metric 16942 notify Anyone ever see something like this? Here's my OSPF and RIP tables. show route table ipv4 unicast ospf terse Destination P Prf Metric 1 Next hop 10.0.0.0/24 o 110 1 10.0.6.2 10.0.7.0/24 o 110 11 10.0.6.2 10.0.8.0/24 o 110 11 10.0.6.2 10.0.9.0/24 o 110 21 10.0.6.2 10.0.10.0/24 o 110 21 10.0.6.2 10.0.11.0/24 o 110 1 10.0.6.2 10.0.12.0/24 o 110 16943 10.0.6.2 show route table ipv4 unicast rip terse Destination P Prf Metric 1 Next hop 10.0.0.0/24 r 110 23884 10.0.1.2 10.0.2.0/24 r 110 16942 10.0.5.2 10.0.3.0/24 r 110 16942 10.0.5.2 10.0.4.0/24 r 110 16942 10.0.5.2 10.0.7.0/24 r 110 23884 10.0.1.2 10.0.8.0/24 r 110 23884 10.0.1.2 10.0.9.0/24 r 110 23884 10.0.1.2 10.0.10.0/24 r 110 23884 10.0.1.2 10.0.11.0/24 r 110 20413 10.0.1.2 10.0.12.0/24 r 110 16942 10.0.1.2 Cheers, JM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120928/53c23209/attachment.html