Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

Problems with multipoint GRE / NHRP

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


dr at cluenet

Feb 12, 2005, 7:10 PM

Post #1 of 3 (1015 views)
Permalink
Problems with multipoint GRE / NHRP

Hi,

I'm trying to set up a GRE tunnel with roadwarrior support (one endpoint
with dynamic IP).

R1: hub router, 12.3(11)T2
R2: spoke router, with dynamic IP on Dialer4, 12.3(8)T6

Hub router config:
==================
interface Tunnel12
ip address 10.0.12.1 255.255.255.252
no ip redirects
ip mtu 1500
ip router isis
ip pim sparse-mode
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp network-id 99
ip nhrp holdtime 1000
ip nhrp server-only
...
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel key xxx

Spoke router config:
====================
interface Tunnel12
ip address 10.0.12.2 255.255.255.252
no ip redirects
ip mtu 1500
ip router isis
ip pim sparse-mode
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp map 10.0.12.1 192.168.22.22
ip nhrp map multicast 192.168.22.22
ip nhrp network-id 99
ip nhrp holdtime 1000
ip nhrp nhs 10.0.12.1
tunnel source Dialer4
tunnel mode gre multipoint
tunnel key xxx

R2 sends NHRP registration request to R1, R1 accepts and replies.
NHRP debugging on R2 never shows the reply reception, although R1
correctly addresses it to R2's Dialer4 IP address.

Debugging on R2 showing the NHRP Reg Request:

NHRP: Setting retrans delay to 64 for nhs dst 10.0.12.1
NHRP: Attempting to send packet via DEST 10.0.12.1
NHRP: Encapsulation succeeded. Tunnel IP addr 192.168.22.22
NHRP: Send Registration Request via Tunnel12 vrf 0, packet size: 81
src: 10.0.12.2, dst: 10.0.12.1
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 81 bytes out Tunnel12

Debug log on R1 showing reception of the request and sending of reply:

NHRP: Receive Registration Request via Tunnel12 vrf 0, packet size: 81
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 99, to_us = 1
NHRP: NAT-check: matched destination address $R2Dialer4IP
NHRP: Cache update for target 10.0.12.2/32 next-hop 10.0.12.2
$R2Dialer4IP
NHRP: Converted internal dynamic cache entry for 10.0.12.2/32 interface Tunnel12 to external
NHRP: Attempting to send packet via DEST 10.0.12.2
NHRP: Encapsulation succeeded. Tunnel IP addr $R2Dialer4IP
NHRP: Send Registration Reply via Tunnel12 vrf 0, packet size: 101
src: 10.0.12.1, dst: 10.0.12.2
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 101 bytes out Tunnel12

R2 never seems to receive the reply. Bug? Unfortunately, can't easily
sniff the traffic to see wether the reply is actually put on the wire
by R1 towards R2.

When reconfiguring R2 from "tunnel mode gre multipoint" to "tunnel mode
gre ip" and specificing R1 as tunnel destination, NHRP registration
succeeds. But then I have the problem that R2 tries to send P2P IIH
instead of LAN IIH, and thus IS-IS adjacency not comming up as R1
rejects the P2P IIHs. PIM works fine (at least brings up adjacency)
though.

Any insight?


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0


luan.nguyen at mci

Feb 13, 2005, 9:36 PM

Post #2 of 3 (1000 views)
Permalink
RE: Problems with multipoint GRE / NHRP [In reply to]

I can say that your configuration work fine with both router using 12.3.11T.
Strange that changing over to tunnel mode gre ip would make it work since
both the debug look exactly the same regarding receiving registration reply
packets:

Feb 14 04:20:20.232 GMT: NHRP: Receive Registration Reply via Tunnel1 vrf 0,
packet size: 100
Feb 14 04:20:20.232 GMT: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
Feb 14 04:20:20.236 GMT: shtl: 4(NSAP), sstl: 0(NSAP)
Feb 14 04:20:20.236 GMT: (M) flags: "unique", reqid: 45
Feb 14 04:20:20.236 GMT: src NBMA: R2WAN
Feb 14 04:20:20.236 GMT: src protocol: 10.0.0.2, dst protocol: 10.0.0.1
Feb 14 04:20:20.236 GMT: (C-1) code: no error(0)
Feb 14 04:20:20.236 GMT: prefix: 255, mtu: 1514, hd_time: 600
Feb 14 04:20:20.236 GMT: addr_len: 0(NSAP), subaddr_len: 0(NSAP),
proto_len: 0, pref: 0
Feb 14 04:20:20.240 GMT: Responder Address Extension(3):
Feb 14 04:20:20.240 GMT: (C) code: no error(0)
Feb 14 04:20:20.240 GMT: prefix: 0, mtu: 1514, hd_time: 600
Feb 14 04:20:20.240 GMT: addr_len: 4(NSAP), subaddr_len: 0(NSAP),
proto_len: 4, pref: 0
Feb 14 04:20:20.240 GMT: client NBMA: R1WAN
Feb 14 04:20:20.240 GMT: client protocol: 10.0.0.1
Feb 14 04:20:20.240 GMT: Forward Transit NHS Record Extension(4):
Feb 14 04:20:20.244 GMT: Reverse Transit NHS Record Extension(5):
Feb 14 04:20:20.244 GMT: Authentication Extension(7):
Feb 14 04:20:20.244 GMT: type:Cleartext(1), data:test
Feb 14 04:20:20.244 GMT: NHRP: netid_in = 0, to_us = 1
Feb 14 04:20:20.244 GMT: NHRP: NHS-UP: 10.0.0.1

If the ip address changes, it would give error like:" Feb 14 02:54:50.245
GMT: %NHRP-3-PAKREPLY: Receive Registration Reply packet with error - unique
address registered already(14)"
Have you try coming back to gre multipoint? Personally I don't think it's a
bug if one router send and the other one doesn't get...probably get dropped
somewhere :). Also keep in mind that mode gre ip work (they are the same
regarding spoke-hub communication) the spoke multipoint mode only kick in
when you have another spoke.
About ISIS, I don't know much about it, but I would think that if you flat
your network out with all level-1 or level1-2 then it should work? I also
saw on CCO suggesting that you do some thing like:

A Level 1 area and a Level 1-2 area:
interface Tunnel12
ip router isis BB
interface Ethernet1
ip router isis AA
router isis BB
net 49.2222.0000.0000.0005.00
router isis AA
net 49.0553.0001.0000.0000.0005.00
is-type level-1

Hope that help a little.

Luan


-----Original Message-----
From: cisco-nsp-bounces [at] puck
[mailto:cisco-nsp-bounces [at] puck] On Behalf Of Daniel Roesen
Sent: Saturday, February 12, 2005 9:10 PM
To: cisco-nsp [at] puck
Subject: [c-nsp] Problems with multipoint GRE / NHRP

Hi,

I'm trying to set up a GRE tunnel with roadwarrior support (one endpoint
with dynamic IP).

R1: hub router, 12.3(11)T2
R2: spoke router, with dynamic IP on Dialer4, 12.3(8)T6

Hub router config:
==================
interface Tunnel12
ip address 10.0.12.1 255.255.255.252
no ip redirects
ip mtu 1500
ip router isis
ip pim sparse-mode
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp network-id 99
ip nhrp holdtime 1000
ip nhrp server-only
...
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel key xxx

Spoke router config:
====================
interface Tunnel12
ip address 10.0.12.2 255.255.255.252
no ip redirects
ip mtu 1500
ip router isis
ip pim sparse-mode
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp map 10.0.12.1 192.168.22.22
ip nhrp map multicast 192.168.22.22
ip nhrp network-id 99
ip nhrp holdtime 1000
ip nhrp nhs 10.0.12.1
tunnel source Dialer4
tunnel mode gre multipoint
tunnel key xxx

R2 sends NHRP registration request to R1, R1 accepts and replies.
NHRP debugging on R2 never shows the reply reception, although R1
correctly addresses it to R2's Dialer4 IP address.

Debugging on R2 showing the NHRP Reg Request:

NHRP: Setting retrans delay to 64 for nhs dst 10.0.12.1
NHRP: Attempting to send packet via DEST 10.0.12.1
NHRP: Encapsulation succeeded. Tunnel IP addr 192.168.22.22
NHRP: Send Registration Request via Tunnel12 vrf 0, packet size: 81
src: 10.0.12.2, dst: 10.0.12.1
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 81 bytes out Tunnel12

Debug log on R1 showing reception of the request and sending of reply:

NHRP: Receive Registration Request via Tunnel12 vrf 0, packet size: 81
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 99, to_us = 1
NHRP: NAT-check: matched destination address $R2Dialer4IP
NHRP: Cache update for target 10.0.12.2/32 next-hop 10.0.12.2
$R2Dialer4IP
NHRP: Converted internal dynamic cache entry for 10.0.12.2/32 interface
Tunnel12 to external
NHRP: Attempting to send packet via DEST 10.0.12.2
NHRP: Encapsulation succeeded. Tunnel IP addr $R2Dialer4IP
NHRP: Send Registration Reply via Tunnel12 vrf 0, packet size: 101
src: 10.0.12.1, dst: 10.0.12.2
(F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
(M) flags: "unique", reqid: 17
src NBMA: $R2Dialer4IP
src protocol: 10.0.12.2, dst protocol: 10.0.12.1
(C-1) code: no error(0)
prefix: 255, mtu: 1514, hd_time: 1000
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 101 bytes out Tunnel12

R2 never seems to receive the reply. Bug? Unfortunately, can't easily
sniff the traffic to see wether the reply is actually put on the wire
by R1 towards R2.

When reconfiguring R2 from "tunnel mode gre multipoint" to "tunnel mode
gre ip" and specificing R1 as tunnel destination, NHRP registration
succeeds. But then I have the problem that R2 tries to send P2P IIH
instead of LAN IIH, and thus IS-IS adjacency not comming up as R1
rejects the P2P IIHs. PIM works fine (at least brings up adjacency)
though.

Any insight?


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


dr at cluenet

Feb 13, 2005, 9:59 PM

Post #3 of 3 (986 views)
Permalink
Re: Problems with multipoint GRE / NHRP [In reply to]

On Sun, Feb 13, 2005 at 11:36:28PM -0500, Luan Nguyen wrote:
> I can say that your configuration work fine with both router using
> 12.3.11T.

Hrm.

> Have you try coming back to gre multipoint?

IIRC multiple times, yes.

> Personally I don't think it's a bug if one router send and the other
> one doesn't get...probably get dropped somewhere :).

FWIW, I can ping both ways just fine.

> Also keep in mind that mode gre ip work (they are the same
> regarding spoke-hub communication) the spoke multipoint mode only kick
> in when you have another spoke.

Jep, but it does influence the ISIS IIH type...

> About ISIS, I don't know much about it, but I would think that if
> you flat your network out with all level-1 or level1-2 then it should
> work?

It's flat single area level-2. Meanwhile I remember that IS-IS has
a general problem with NBMA networks like mGRE, so I might not be able
to run IS-IS on such a mGRE tunnel at all.

Thanks for taking the time to look into this problem!


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.