[c-nsp] Problems with multipoint GRE / NHRP
Luan Nguyen
luan.nguyen at mci.com
Sun Feb 13 23:36:28 EST 2005
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.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Daniel Roesen
Sent: Saturday, February 12, 2005 9:10 PM
To: cisco-nsp at puck.nether.net
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.de -- dr at IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list