Timo,
I built the packages this weekend and had a few issues, they all proved to
be on my side however and I now have the package built and deployed inside
OpenWrt.
I see my registrations created without the unique keyword and it's working
as expected:
router0003#sh ip nhrp 172.24.12.230
172.24.12.230/32 via 172.24.12.230
Tunnel813 created 00:02:58, expire 01:59:48
Type: dynamic, Flags: registered nhop
NBMA address: 10.2.0.151
What is your next step for this patch? Will you integrate it into a new
point release or will we run with the patch for a while?
-JohnF
On Fri, May 1, 2015 at 9:59 AM, Timo Teras <timo.te...@iki.fi> wrote:
> Hi,
>
> Can you try if the attached patch, along with adding the non-unique
> keyword fixes the issue?
>
> Thanks,
> Timo
>
> On Fri, 1 May 2015 09:47:04 -0400
> John Marrett <jo...@zioncluster.ca> wrote:
>
> > Unfortunately adding the cisco keyword doesn't appear to have
> > resolved the problem.
> >
> > My configuration is now:
> >
> > interface gre-tun814
> > map 172.24.14.1/23 x.x.x.x register cisco
> > cisco-authentication limitedvalue
> > shortcut
> > redirect
> > non-caching
> >
> > I reloaded a device and it changed it's WAN IP address. I see the
> > following every 2 seconds in the log:
> >
> > Thu Apr 30 17:14:23 2015 daemon.info opennhrp[2211]: Sending
> > Registration Request to 172.24.14.1 (my mtu=0)
> > Thu Apr 30 17:14:23 2015 daemon.info opennhrp[2211]: Received
> > Registration Reply from 172.24.14.1: unique address already registered
> > Thu Apr 30 17:14:23 2015 daemon.info opennhrp[2211]: Sending Purge
> > Request (of protocol address) to 172.24.14.1
> >
> > When I validate the address on the hub I see the following:
> >
> > router0004#sh ip nhrp 172.24.14.227
> > 172.24.14.227/32 (vrf-name) via 172.24.14.227
> > Tunnel814 created 12:15:00, expire 01:23:47
> > Type: dynamic, Flags: unique registered used nhop
> > NBMA address: 10.2.0.174
> >
> > However my device is no longer present at 10.2.0.174 and is now at
> > 10.2.0.149.
> >
> > If I clear the nhrp registration on the hub:
> >
> > router0004#clear ip nhrp 172.24.14.227
> >
> > Then my device immediately registers.
> >
> > Thu Apr 30 17:15:11 2015 daemon.info opennhrp[2211]: Sending
> > Registration Request to 172.24.14.1 (my mtu=0)
> > Thu Apr 30 17:15:11 2015 daemon.info opennhrp[2211]: Received
> > Registration Reply from 172.24.14.1: success
> >
> > router0004#sh ip nhrp 172.24.14.227
> > 172.24.14.227/32 (vrf-name) via 172.24.14.227
> > Tunnel814 created 00:02:55, expire 01:57:04
> > Type: dynamic, Flags: unique registered used nhop
> > NBMA address: 10.2.0.149
> >
> > For my application support of the no-unique attribute is critical. I
> > can provide packet captures of registration from a Cisco device if
> > required. If you can provide guidance on where the change needs to be
> > made in the source I can start investigating it myself. I could also
> > reduce the hold time as a temporary measure.
> >
> > Thanks for your help and for the excellent opennhrp tool.
> >
> > -JohnF
> >
> >
> > On Mon, Apr 27, 2015 at 2:52 PM, Timo Teras <timo.te...@iki.fi> wrote:
> >
> > > On Mon, 27 Apr 2015 10:02:49 -0400
> > > John Marrett <jo...@zioncluster.ca> wrote:
> > >
> > > > I'm using opennhrp to register with a Cisco hub router. in my
> > > > Cisco configuration I use the option "ip nhrp registration
> > > > no-unique" [1]. this tells the hub that other devices registering
> > > > can overwrite an existing registration. As my devices use dynamic
> > > > IP addresses for some of their connections to the core it allows
> > > > different devices to either change their NBMA IP or replace
> > > > another existing NBMA address.
> > > >
> > > > [1]
> > > >
> > >
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr/command/iad-cr-book/ip_nat_source_through_iterate-ip-addrs.html#GUID-69654F06-92CF-4124-8BF0-A1B8BBA44B02
> > > >
> > > > How can I configure this option with opennhrp?
> > >
> > > I must've somehow missed this option. In map directive with
> > > registration you can add 'cisco' to fix statically the packet
> > > registration ids, so it'll purge the old registration first.
> > >
> > > However, seems adding this bit is more appropriate. It's fairly
> > > simple to toggle this bit.
> > >
> > > Though, I'm not sure if Cisco is doing the right thing RFC wise by
> > > *replacing* existing registrations. The rfc seems ambiguous whether
> > > the registration with differing address should replace, or be added
> > > as alternate mapping. Replacing the registration seems probably the
> > > correct thing in dmvpn context. But protocol wise I'm slightly
> > > puzzled with this.
> > >
> > > In any case, it'd probably be good idea to add that.
> > >
> > > /Timo
> > >
>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
opennhrp-devel mailing list
opennhrp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
