From esj at cs.fiu.edu Tue May 1 07:47:07 2012 From: esj at cs.fiu.edu (Eric S. Johnson) Date: Tue, 01 May 2012 10:47:07 -0400 Subject: [Xorp-users] [Xorp-hackers] ospfv3 for IPv6 ospf - oddity In-Reply-To: <20120427224212.6432F3680006@cheetah.cs.fiu.edu> References: <20120427224212.6432F3680006@cheetah.cs.fiu.edu> Message-ID: <20120501144707.C4B473680003@cheetah.cs.fiu.edu> Answering myself. I kinda decided it is a bug. Everybody else doing V6 ospf seems to send metrics with Intra-Area prefix LSA, and everybody else seems to want to see them to give a cost to a link. (everybody else == cisco and quagga :) Here is a patch a worked up that seems to let xorp "do the right thing". I left in the sending of /128 interface prefix along with the /64 network prefix becuase I have no "virtual links" nor experience with them. I kinda think that those /128's should be advertised ONLY on virtual links and certainly not on broadcast networks... But haven't worked that out yet. Patch is against a git pull on 4-29-2012 but applies clean to 1.8.5 also. C++ is not my native language, and I am not certain on some OSPF3 things still, so I would appreciate some feedback. Thoughts? Anyone out there acutally trying to use xorp ospf6 besides me? :) E esj at cs.fiu.edu said: > I started playing vith ospf for v6 recently. I have noticed an > oddity. I am curious if I have something miss-configured or I have > found a bug. > OSPFv3 for ipv6 has a couple new link-state adv types. The one I am > running into interoperability issues with is the Intra-area prefix > type. > It appears that xorp is sending these out with a cost of zero. No > matter what the config file cost setting is. > This causes all the other ospf3 impelmentations it talks to (well, > ok, cisco IOS and quagga are the only ones I have tested) to count > the cost to that network as zero. > xorp sends the ole fashioned router lsa's with the appropriate > costs. But not the new fangled intra-area prefix costs. > xorp also seems to send a /128 IA prefix LSA with the address of > the interface also with metric of 0. This doesn't impact things as > much as the network prefixs being 0, but seems odd too. > I have verified with wireshark that it is sending the IA prefix > lsa's with cost 0. > Below are relavant snips of my configs. > Xorp showing this behavior is 1.8.5 and git pulled on 2012-04-19 > Running on centos 5.6 (RHEL 5). Linux test-router 2.6.18-164.6.1.el5 > #1 SMP Tue Nov 3 16:18:27 EST 2009 i686 i686 i386 GNU/Linux > Am I missing something? Or is this a bug? > E diff -r -U5 /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/area_router.cc ./area_router.cc --- /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/area_router.cc 2012-04-29 08:34:47.000000000 -0400 +++ ./area_router.cc 2012-04-29 09:01:10.000000000 -0400 @@ -3444,11 +3444,10 @@ if (prefix.get_nu_bit() /*|| prefix.get_la_bit()*/) continue; if (prefix.get_network().masked_addr(). is_linklocal_unicast()) continue; - prefix.set_metric(0); prefixes.push_back(prefix); } } } else if (configured_virtual_link()) { uint32_t interface_id = pm.get_interface_id(i->first); diff -r -U5 /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer.cc ./peer.cc --- /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer.cc 2012-04-29 08:34:47.000000000 -0400 +++ ./peer.cc 2012-04-29 08:50:33.000000000 -0400 @@ -706,18 +706,18 @@ return _areas[area]->get_attached_routers(routers); } template bool -PeerOut::add_advertise_net(OspfTypes::AreaID area, A addr, uint32_t prefix) +PeerOut ::add_advertise_net(OspfTypes::AreaID area, A addr, uint32_t prefix, uint16_t interface_cost) { if (0 == _areas.count(area)) { XLOG_ERROR("Unknown Area %s", pr_id(area).c_str()); return false; } - return _areas[area]->add_advertise_net(addr, prefix); + return _areas[area]->add_advertise_net(addr, prefix, interface_cost); } template bool PeerOut ::remove_all_nets(OspfTypes::AreaID area) @@ -3220,37 +3220,39 @@ return _hello_packet.get_interface_id(); } template <> bool -Peer::add_advertise_net(IPv4 /*addr*/, uint32_t /*prefix_length*/) +Peer::add_advertise_net(IPv4 /*addr*/, uint32_t /*prefix_length*/, uint16_t /*cost*/ ) { XLOG_FATAL("Only IPv6 not IPv4"); return true; } template <> bool -Peer::add_advertise_net(IPv6 addr, uint32_t prefix_length) +Peer::add_advertise_net(IPv6 addr, uint32_t prefix_length, uint16_t interface_cost) { XLOG_ASSERT(OspfTypes::VirtualLink != get_linktype()); LinkLsa *llsa = dynamic_cast(_link_lsa.get()); XLOG_ASSERT(llsa); if (addr.is_linklocal_unicast()) return false; - IPv6Prefix prefix(_ospf.get_version()); + IPv6Prefix prefix(_ospf.get_version(), true); prefix.set_network(IPNet(addr, prefix_length)); + prefix.set_metric(interface_cost); llsa->get_prefixes().push_back(prefix); // Add a host route that can be used if necessary to advertise a // virtual link endpoint. - IPv6Prefix host_prefix(_ospf.get_version()); + IPv6Prefix host_prefix(_ospf.get_version(), true); host_prefix.set_network(IPNet(addr, IPv6::ADDR_BITLEN)); + host_prefix.set_metric(interface_cost); host_prefix.set_la_bit(true); llsa->get_prefixes().push_back(host_prefix); return true; } diff -r -U5 /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer.hh ./peer.hh --- /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer.hh 2012-04-29 08:34:47.000000000 -0400 +++ ./peer.hh 2012-04-29 08:43:09.000000000 -0400 @@ -327,11 +327,11 @@ list& routes); /** * Set a network to advertise OSPFv3 only. */ - bool add_advertise_net(OspfTypes::AreaID area, A addr, uint32_t prefix); + bool add_advertise_net(OspfTypes::AreaID area, A addr, uint32_t prefix, uint16_t interface_cost); /** * Remove all the networks that are being advertised OSPFv3 only. */ bool remove_all_nets(OspfTypes::AreaID area); @@ -1110,11 +1110,11 @@ uint32_t get_interface_id() const; /** * Set a network to advertise OSPFv3 only. */ - bool add_advertise_net(A addr, uint32_t prefix); + bool add_advertise_net(A addr, uint32_t prefix, uint16_t interface_cost); /** * Remove all the networks that are being advertised OSPFv3 only. */ bool remove_all_nets(); diff -r -U5 /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer_manager.cc ./peer_manager.cc --- /opt/router/src/xorp.ct.20120429.orig/xorp/ospf/peer_manager.cc 2012-04-29 08:34:47.000000000 -0400 +++ ./peer_manager.cc 2012-04-29 08:57:46.000000000 -0400 @@ -704,10 +704,11 @@ XLOG_ERROR("Unknown PeerID %u", peerid); return false; } set >& info = _peers[peerid]->get_address_info(area); + uint16_t interface_cost = _peers[peerid]->get_interface_cost() ; // Unconditionally remove all the global addresses that are being // advertised. _peers[peerid]->remove_all_nets(area); @@ -739,21 +740,21 @@ interface_prefix_length)) { XLOG_ERROR("Unable to get prefix length for %s", cstring(*i)); continue; } if (!_peers[peerid]->add_advertise_net(area, (*i), - interface_prefix_length)) { + interface_prefix_length,interface_cost)) { XLOG_WARNING("Unable to advertise %s in Link-LSA\n", cstring(*i)); } } } else { typename set >::iterator i; for (i = info.begin(); i != info.end(); i++) { if ((*i)._enabled) { if (!_peers[peerid]->add_advertise_net(area, (*i)._address, - (*i)._prefix)) { + (*i)._prefix,interface_cost)) { XLOG_WARNING("Unable to advertise %s in Link-LSA\n", cstring((*i)._address)); } } } From greearb at candelatech.com Tue May 1 09:07:51 2012 From: greearb at candelatech.com (Ben Greear) Date: Tue, 01 May 2012 09:07:51 -0700 Subject: [Xorp-users] [Xorp-hackers] ospfv3 for IPv6 ospf - oddity In-Reply-To: <20120501144707.C4B473680003@cheetah.cs.fiu.edu> References: <20120427224212.6432F3680006@cheetah.cs.fiu.edu> <20120501144707.C4B473680003@cheetah.cs.fiu.edu> Message-ID: <4FA00A57.1060607@candelatech.com> On 05/01/2012 07:47 AM, Eric S. Johnson wrote: > > Answering myself. > > I kinda decided it is a bug. Everybody else doing V6 ospf seems > to send metrics with Intra-Area prefix LSA, and everybody else > seems to want to see them to give a cost to a link. > > (everybody else == cisco and quagga :) > > Here is a patch a worked up that seems to let xorp > "do the right thing". > > I left in the sending of /128 interface prefix along with > the /64 network prefix becuase I have no "virtual links" nor > experience with them. I kinda think that those /128's should be > advertised ONLY on virtual links and certainly not on broadcast > networks... But haven't worked that out yet. > > Patch is against a git pull on 4-29-2012 but applies clean to > 1.8.5 also. > > C++ is not my native language, and I am not certain on some OSPF3 > things still, so I would appreciate some feedback. > > Thoughts? > > Anyone out there acutally trying to use xorp ospf6 besides me? :) We do a bit of testing with it, but not extensively, and only xorp to xorp so far. I'm about to do a release of our LANforge product, but as soon as we kick that out the door I'll add apply this patch unless someone suggests otherwise. It looks sane enough to me. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From adrian.fm at tesla.cujae.edu.cu Mon May 14 12:11:11 2012 From: adrian.fm at tesla.cujae.edu.cu (Adrian =?iso-8859-1?Q?Fern=E1ndez?= Morales) Date: Mon, 14 May 2012 15:11:11 -0400 Subject: [Xorp-users] Fwd: Does XORP...? Message-ID: When a router XORP is configured as an ABR of a stub area in OSPF, does it flood a default route into the area? I'm performing some tests and I've discovered that it doesn't do that, at least automatically. Is there a special configuration option to enable this feature? Thanks in advance Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120514/031f23a4/attachment.html From adrian.fm at tesla.cujae.edu.cu Mon May 14 12:11:34 2012 From: adrian.fm at tesla.cujae.edu.cu (Adrian =?iso-8859-1?Q?Fern=E1ndez?= Morales) Date: Mon, 14 May 2012 15:11:34 -0400 Subject: [Xorp-users] (no subject) Message-ID: Currently I'm testing some options of XORP and have found myself into a problem with authentication. When I use that functionality it works correctly but when I try to disable it, nothing happens. The software keeps setting authentication parameters in messages and discarding the received ones that doesn't use authentication at all. To delete the previouly configured authentication in OSPF I use the command: delete protocols ospf4 area x.x.x.x interface ethy vif ethy address z.z.z.z authentication simple-password "password" I also use the same command without specifying the password explitcily but result is the same. When I'm inserting commands I use tab to complete, to avoid mistakes and be sure of correctness. Thanks in advance. Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120514/d4d09d99/attachment.html From esj at cs.fiu.edu Mon May 14 13:08:00 2012 From: esj at cs.fiu.edu (Eric S. Johnson) Date: Mon, 14 May 2012 16:08:00 -0400 Subject: [Xorp-users] (no subject) In-Reply-To: References: Message-ID: <20120514200800.EF63E3680009@cheetah.cs.fiu.edu> Hi Adrian, You should include the version of xorp you are using when posing questions. There were some problems with md5 auth in some older versions of xorp, but these were fixed and in the current version of xorp (1.8.5) md5 auth on OSPF works fine and inter-operates with cisco IOS/quagga. I have not tried "simple" ospf auth. Below is a example config with md5 auth. ospf4 { router-id: 10.1.1.1 rfc1583-compatibility: true ip-router-alert: false area 0.0.0.0 { area-type: "normal" interface "eth0" { link-type: "broadcast" vif "eth0" { address 10.1.1.1 { priority: 1 hello-interval: 10 router-dead-interval: 40 interface-cost: 70 retransmit-interval: 5 transit-delay: 1 authentication { md5 1 { password: "supersecret" } } disable: false } } } } } From david at commroom.net Mon May 14 22:13:19 2012 From: david at commroom.net (David Davidson) Date: Mon, 14 May 2012 22:13:19 -0700 Subject: [Xorp-users] (no subject) In-Reply-To: References: Message-ID: <4FB1E5EF.7080500@commroom.net> Hi Folks, I have tested this and I agree with Adrian. It seems that the only way to get an OSPF adjacency formed again is to disable the authentication and then force the OSPF4 daemon to be restarted (either by saving the new configuration and then restarting the router manager, OR deleting OSPF, committing, and reconfiguring OSPF without the authentication, and then committing again). One should not have to cause the ospf4 daemon to restart completely in order to load up the new OSPF configuration for that interface. Upon committing the configuration change, there should be a way for the OSPF4 daemon to detect the configuration change, and to notice that the authentication was just removed from that interface, the OSPF process/protocol should only be modified just for that interface, without having to reload the OSPF daemon, and also without having to disrupt any other OSPF processes and/or adjacencies on that router (i.e. on other interfaces). Another user mentioned trying this with MD5 authentication, but I have found this to be the same result. Upon changing the configuration and completely removing the authentication for that interface, and also following the commit, no non-authenticated OSPF adjacency can be formed on that interface - the OSPF4 daemon continues to send OSPF4 packets with the authentication parameter set, it continues to send the MD5 authentication key in the OSPF header, and, like Adrian mentions, it ignores any packets from directly-connected OSPF neighbors whose OSPF header has no authentication key. It perpetually sends the key and ignores any OSPF hello's where there is no MD5 key in in the header. This happens whether I use simple password authentication, and it also happens if I use MD5 authentication. Upon deleting the authentication requirement for a particular interface, no non-authenticated OSPF adjacencies can be formed on that interface, regardless of whether MD5 or simple password authentication was used. The result is the same for both. I have included an attachment that documents the way I tested this. This was tested on a GIT clone from 4/17/2012. a "show version" output is as follows: root at XORPROUTER> show version Version 1.8.5 Launching the xorpsh shell produces the following version information: Welcome to XORP v1.8.6-WIP on XORPROUTER Version tag: 08cde50 Build Date: 2012-04-17 10:35 32-bit Also, clearing the OSPF database after the change didn't have any effect either. If anyone has some more thoughts or anything they would like me to try, please let me know. Thank you Adrian for the interesting find... David On 05/14/2012 12:11 PM, Adrian Fern?ndez Morales wrote: > > Currently I'm testing some options of XORP and have found myself into > a problem with authentication. > When I use that functionality it works correctly but when I try to > disable it, nothing happens. The software keeps setting authentication > parameters in messages and discarding the received ones that doesn't > use authentication at all. > To delete the previouly configured authentication in OSPF I use the > command: > delete protocols ospf4 area x.x.x.x interface ethy vif ethy address > z.z.z.z authentication simple-password "password" > I also use the same command without specifying the password explitcily > but result is the same. When I'm inserting commands I use tab to > complete, to avoid mistakes and be sure of correctness. > Thanks in advance. > > Participe en la XVI Convenci?n Cient?fica de Ingenier?a y Arquitectura > del 26 al 30 de noviembre de 2012. La Habana, Cuba: > http://ccia.cujae.edu.cu > Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120514/ff238911/attachment-0001.html -------------- next part -------------- ############################################################### #TOPOLOGY # [eth1 xorp1 eth0]----------[eth0 xorp2 eth1]----------[eth0 xorp3 eth1] ############################################################### ########################## #xorp1 ########################## configure exclusive set rtrmgr config-directory /etc/xorp set protocols ospf4 router-id 10.10.10.1 set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 disable false set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.20.20.1 disable false set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 authentication simple-password "password" set interfaces interface eth0 vif eth0 address 10.10.10.1 prefix-length 24 set interfaces interface eth1 vif eth1 address 10.20.20.1 prefix-length 24 set fea unicast-forwarding4 disable false commit exit configuration-mode ########################## #xorp2 ########################## configure exclusive set rtrmgr config-directory /etc/xorp set protocols ospf4 router-id 172.16.10.1 set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.2 disable false set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 172.16.10.1 disable false set interfaces interface eth0 vif eth0 address 10.10.10.2 prefix-length 24 set interfaces interface eth1 vif eth1 address 172.16.10.1 prefix-length 24 set fea unicast-forwarding4 disable false commit exit configuration-mode ########################## #xorp3 ########################## configure exclusive set rtrmgr config-directory /etc/xorp set protocols ospf4 router-id 172.16.10.2 set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 172.16.10.2 disable false set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 192.168.10.1 disable false set interfaces interface eth0 vif eth0 address 172.16.10.2 prefix-length 24 set interfaces interface eth1 vif eth1 address 192.168.10.1 prefix-length 24 set fea unicast-forwarding4 disable false commit exit configuration-mode ########################## #Okay, now, delete the authentication on xorp1. ########################## configure exclusive delete protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 authentication commit exit configuration-mode #[at this point, the OSPF adjacency with xorp2 should form successfully, but it never does.] #The following causes the adjacency to form, but it kills the ospf4 daemon in the process and then forces ospf4 #to re-initialize. The adjacency forms without authentication then, but one should never have to manually kill the ospf4 #daemon this way. The router should be intelligent enough to modify the protocol for just that interface, without having #to reinitialize or interrupt the OSPF4 daemon at all. This is a clunky way of doing it, because we have to rebuild #the whole OSPF database and do all the SPF calculations again, and then wait for the network to reconverge. configure exclusive delete protocols ospf4 commit #[ospf4 daemon killed now] set protocols ospf4 router-id 10.10.10.1 set protocols ospf4 area 0.0.0.0 interface eth0 vif eth0 address 10.10.10.1 disable false set protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address 10.20.20.1 disable false set interfaces interface eth0 vif eth0 address 10.10.10.1 prefix-length 24 set interfaces interface eth1 vif eth1 address 10.20.20.1 prefix-length 24 commit From adrian.fm at tesla.cujae.edu.cu Mon May 21 08:07:18 2012 From: adrian.fm at tesla.cujae.edu.cu (Adrian =?iso-8859-1?Q?Fern=E1ndez?= Morales) Date: Mon, 21 May 2012 11:07:18 -0400 Subject: [Xorp-users] (no subject) In-Reply-To: <20120514200800.EF63E3680009@cheetah.cs.fiu.edu> References: <20120514200800.EF63E3680009@cheetah.cs.fiu.edu> Message-ID: Erick: I think you missunderstodd what I was trying to explain. My problem isn't about using authentication but disabling it after being configured and used successfully. The only way I've found is by restarting the daemon. By the way, the version I'm using is 1.8.5. I've had another situation regarding ospf in XORP. It's when you configure a XORP on an ABR of a stub area. The problem is that a default route isn't advertised into the area and the concept of stub is completely lost. Thank you. -----Original Message----- From: "Eric S. Johnson" To: "Adrian Fern?ndez Morales" Cc: "xorp-users at xorp.org" Date: Mon, 14 May 2012 16:08:00 -0400 Subject: Re: [Xorp-users] (no subject) Hi Adrian, You should include the version of xorp you are using when posing questions. There were some problems with md5 auth in some older versions of xorp, but these were fixed and in the current version of xorp (1.8.5) md5 auth on OSPF works fine and inter-operates with cisco IOS/quagga. I have not tried "simple" ospf auth. Below is a example config with md5 auth. ospf4 { router-id: 10.1.1.1 rfc1583-compatibility: true ip-router-alert: false area 0.0.0.0 { area-type: "normal" interface "eth0" { link-type: "broadcast" vif "eth0" { address 10.1.1.1 { priority: 1 hello-interval: 10 router-dead-interval: 40 interface-cost: 70 retransmit-interval: 5 transit-delay: 1 authentication { md5 1 { password: "supersecret" } } disable: false } } } } } Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120521/d585fdd1/attachment.html From Mustapha.Bilal at imag.fr Wed May 23 01:26:15 2012 From: Mustapha.Bilal at imag.fr (BILAL Mustapha) Date: Wed, 23 May 2012 10:26:15 +0200 Subject: [Xorp-users] tunneling using IPIP (or GRE) Message-ID: <4FBC9F27.3070209@imag.fr> Hello, I don't know if I am in the right mailing list to ask my question. 1) I have 2 Gateways and 2 LBRs. I would like to create 4 tunnels(2 tunnels per each Gateway of destination of the 2 different LBRs) using IPIP (or GRE, although I prefer IPIP for security reasons since GRE doesn't provide any security). 2) The packets transferred in these tunnels are IPv6, once the packet arrive to the LBR, it should know which tunnel was used and the source of each packet (was it Gateway 1 or Gateway 2?). I would be grateful if you can provide me with complete code for the first part of my question (creating the tunnels) since it's my first experience in this topic and if you have any idea about the second part (recovering the source of each packet arriving to the LBR) I would be more than thankful as well. Many thanks From danro at kth.se Wed May 23 04:46:39 2012 From: danro at kth.se (Dan Rosenqvist) Date: Wed, 23 May 2012 11:46:39 +0000 Subject: [Xorp-users] Problems with bootstrap and rp selection in pimsm Message-ID: <54DD4F682C240845BF5F7D0EECBDB6F208399D67@EXDB3.ug.kth.se> Hi, There seems to be an error/bug in xorps bootstrap mechanism for the pimsm4 protocol. In my test network, I've set up two adjacent routers both running ospf4 as well as pimsm4. Each of these have bootstrap enabled with one cand-bsr and one cand-rp each. As the bootstrap router gets elected, one of the routers will have one selected rp in the list of rps (from "show pim rps"), while the other one will have two rps. This will cause strange behaviour in the routing of multicast packets. If I remove one cand-rp from one of the nodes, I get the normal (expected) behaviour. I suspect that this is a bug. If you can't post several candidate rps, what's the use of a bootstrap mechanism? Has anyone else seen similar errors/problems? Is there a known solution? Here's the bootstrap part of router 1 and router 2: --- R1 --- bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth1" bsr-priority: 189 } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth1" rp-priority: 189 } } } --- R2 --- bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth0" bsr-priority: 190 } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth0" rp-priority: 190 } } } In these configurations R1s eth1 interface and R2s eth0 interface are connected to the same subnet. I haven't posted the entire configurations of the two routers, but they are in line with the configurations in www.xorp.org/config/. Regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120523/92488c18/attachment.html From rps at maine.edu Wed May 23 07:40:28 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 23 May 2012 10:40:28 -0400 Subject: [Xorp-users] tunneling using IPIP (or GRE) In-Reply-To: <4FBC9F27.3070209@imag.fr> References: <4FBC9F27.3070209@imag.fr> Message-ID: Neither IPIP nor GRE tunnels provide security alone, and both are stateless. You might be thinking of VPNs built over these protocols. An IPIP tunnel will not work with IPv6 (or any non-IP protocol for that matter). A GRE tunnel can do the job just fine. You can also look into using a IPv6-in-IP tunnel; in Linux this is referred to as a SIT tunnel. http://www.linuxfoundation.org/collaborate/workgroups/networking/tunneling Once created, tunnel interfaces are treated like any other interface in XORP. Unfortunately, you need to create them outside of XORP with a shell script unless that functionality has been added recently. Be careful not to block ICMPv6 traffic for path MTU discovery, otherwise you'll experience MTU issues. FWIW I use IPIP tunnels in a few places with XORP and it works OK. In IPv4 you want to adjust the TCP MSS (via iptables on Linux) if you want reliable communication; if PMTUD isn't filtered for IPv6 you shouldn't need to worry about it, but if you run into filtering ip6tables does offer MSS adjustment as well. A lot of people forget about and wonder why their tunnels don't perform well. To get a feel for setting up a SIT tunnel, you might try getting a free IPv6 tunnel from HE.net (or your tunnel broker of choice) and following their setup instructions. On Wed, May 23, 2012 at 4:26 AM, BILAL Mustapha wrote: > Hello, > > ?I don't know if I am in the right mailing list to ask my question. > > ?1) I have 2 Gateways and 2 LBRs. I would like to create 4 tunnels(2 > tunnels per each Gateway of destination of the 2 different LBRs) using > IPIP (or GRE, although I prefer IPIP for security reasons since GRE > doesn't provide any security). > > ?2) The packets transferred in these tunnels are IPv6, once the packet > arrive to the LBR, it should know which tunnel was used and the source > of each packet (was it Gateway 1 or Gateway 2?). > > ?I would be grateful if you can provide me with complete code for the > first part of my question (creating the tunnels) since it's my first > experience in this topic and if you have any idea about the second part > (recovering the source of each packet arriving to the LBR) I would be > more than thankful as well. > > ?Many thanks > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/