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
> >
diff --git a/man/opennhrp.conf.5 b/man/opennhrp.conf.5
index aacec80..fa0a431 100644
--- a/man/opennhrp.conf.5
+++ b/man/opennhrp.conf.5
@@ -36,7 +36,7 @@ directive must be present to enable NHRP on that interface.
These configuration keywords can appear only in the interface context.
.PP
-.BI "map " protocol-address[/prefix] " " nbma-address " [register] [cisco]"
+.BI "map " protocol-address[/prefix] " " nbma-address " [register] [non-unique] [cisco]"
.RS
Creates static peer mapping of
.I protocol-address
@@ -55,12 +55,22 @@ The optional parameter
specifies that Registration Request should be sent to this peer on
startup.
.PP
-If the statically mapped peer is running Cisco IOS, specify the
+Use
+.B non-unique
+keyword to disable setting of unique flag for registration requests.
+This is required if the peer is running Cisco IOS and this node has
+a dynamic IP.
+.PP
+The deprecated
.B cisco
-keyword. It is used to fix statically the Registration Request ID
-so that a matching Purge Request can be sent if NBMA address has changed.
-This is to work around broken IOS which requires Purge Request ID to
-match the original Registration Request ID.
+keyword will fix statically the Registration Request ID so that
+a matching Purge Request can be sent if NBMA address has changed.
+Use non-unique instead on new installations.
+.PP
+Use
+.B non-unique
+keyword to disable setting of unique flag for registration requests.
+This shou
.RE
.BI "dynamic-map " protocol-address/prefix " " nbma-domain-name
diff --git a/nhrp/nhrp_peer.c b/nhrp/nhrp_peer.c
index b7748d5..9f8f45f 100644
--- a/nhrp/nhrp_peer.c
+++ b/nhrp/nhrp_peer.c
@@ -1075,6 +1075,8 @@ static void nhrp_peer_send_register_cb(struct ev_loop *loop, struct ev_timer *w,
.flags = NHRP_FLAG_REGISTRATION_UNIQUE |
NHRP_FLAG_REGISTRATION_NAT
};
+ if (peer->flags & NHRP_PEER_FLAG_REG_NON_UNIQUE)
+ packet->hdr.flags &= ~NHRP_FLAG_REGISTRATION_UNIQUE;
if (peer->flags & NHRP_PEER_FLAG_CISCO) {
/* Cisco IOS seems to require reqistration and purge
* request id to match, so we need to used a fixed
diff --git a/nhrp/nhrp_peer.h b/nhrp/nhrp_peer.h
index 1cb292a..e0e77f6 100644
--- a/nhrp/nhrp_peer.h
+++ b/nhrp/nhrp_peer.h
@@ -65,6 +65,7 @@
#define NHRP_PEER_FLAG_UNIQUE 0x01 /* Peer is unique; see RFC2332 */
#define NHRP_PEER_FLAG_REGISTER 0x02 /* For TYPE_STATIC: send registration */
#define NHRP_PEER_FLAG_CISCO 0x04 /* For TYPE_STATIC: peer is Cisco */
+#define NHRP_PEER_FLAG_REG_NON_UNIQUE 0x08
#define NHRP_PEER_FLAG_USED 0x10 /* Peer is in kernel ARP table */
#define NHRP_PEER_FLAG_LOWER_UP 0x20 /* Script executed succesfully */
#define NHRP_PEER_FLAG_UP 0x40 /* Can send all packets (registration ok) */
diff --git a/nhrp/opennhrp.c b/nhrp/opennhrp.c
index f8b1207..76b0600 100644
--- a/nhrp/opennhrp.c
+++ b/nhrp/opennhrp.c
@@ -240,6 +240,9 @@ static int load_config(const char *config_file)
} else if (strcmp(word, "cisco") == 0) {
NEED_PEER();
peer->flags |= NHRP_PEER_FLAG_CISCO;
+ } else if (strcmp(word, "non-unique") == 0) {
+ NEED_PEER();
+ peer->flags |= NHRP_PEER_FLAG_REG_NON_UNIQUE;
} else if (strcmp(word, "holding-time") == 0) {
read_word(in, &lineno, sizeof(word), word);
if (peer != NULL &&
------------------------------------------------------------------------------
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
