NHPR behaves unexpectedly

Discussion in 'Cisco' started by mathias.gummert@gmx.de, Oct 10, 2008.

  1. Guest

    I set up a DMVPN with NHRP between two networks connected to the UMTS
    net (my spokes) and one connected via DSL (my hub).

    Everything seems to be fine, but when I traceroute from one spoke to
    the other, I find that they communicate via the hub, and not - as I
    expect - directly with each other.

    The "show ip nhrp" output tells me, that the spokes learned the other
    spoke´s outside IP address so they ought to be able to connect
    directly to each other without the hub in between.

    I attach the "show ip nhrp" output from one of my spokes, the
    "traceroute" output of the same spoke an my configurations.

    I use eigrp for routing.

    Maybe someone has an idea?

    Thank´s a lot.
    Mathias


    Spoke Router:

    RT_UMTS#sho ip nhrp
    172.16.1.10/32 via 172.16.1.10, Tunnel0 created 00:25:04, never expire
    Type: static, Flags:
    NBMA address: 1.2.3.4
    172.16.1.30/32 via 172.16.1.30, Tunnel0 created 00:08:13, expire
    01:52:42
    Type: dynamic, Flags: router implicit
    NBMA address: 80.187.114.1
    (Claimed NBMA address: 172.20.225.217)
    (no-socket)
    192.168.30.10/32, Tunnel0 created 00:00:06, expire 00:02:58
    Type: incomplete, Flags: negative
    Cache hits: 1

    RT_UMTS#traceroute 192.168.30.10

    Type escape sequence to abort.
    Tracing the route to 192.168.30.10

    1 172.16.1.10 228 msec 260 msec 228 msec
    2 172.16.1.30 460 msec 468 msec 460 msec
    3 192.168.30.10 468 msec 1200 msec 448 msec



    Spoke Router:

    interface FastEthernet0/0
    ip address 192.168.20.1

    interface Tunnel0
    ip address 172.16.1.20 255.255.255.0
    ip mtu 1400
    ip nhrp authentication DMVPN_NW
    ip nhrp map multicast dynamic
    ip nhrp map 172.16.1.10 1.2.3.4
    ip nhrp network-id 1
    ip nhrp nhs 172.16.1.10
    ip nhrp cache non-authoritative
    ip nhrp shortcut
    ip nhrp redirect
    ip tcp adjust-mss 1360
    delay 1000
    cdp enable
    tunnel source Cellular0/1/0
    tunnel destination 1.2.3.4
    tunnel key 10000
    tunnel protection ipsec profile DMVPN-PROF

    Hub Router:

    interface Tunnel0
    ip address 172.16.1.10 255.255.255.0
    no ip redirects
    ip mtu 1400
    ip nhrp authentication DMVPN_NW
    ip nhrp map multicast dynamic
    ip nhrp network-id 1
    ip nhrp holdtime 360
    ip nhrp cache non-authoritative
    ip nhrp redirect
    ip tcp adjust-mss 1360
    no ip split-horizon eigrp 1
    delay 1000
    cdp enable
    tunnel source Dialer1
    tunnel mode gre multipoint
    tunnel key 10000
    tunnel protection ipsec profile DMVPN-PROF
    , Oct 10, 2008
    #1
    1. Advertising

  2. Helmut Guest

    Does "show ip route" show 172.16.1.30 as the gateway for
    192.168.30.0/24? I think no.
    So why should your traceroute go directly to 172.16.1.30?
    Add the line "no ip next-hop-self eigrp 1" to the tunnel configuration
    of your hub router. Reset the eigrp adjacency and look again into your
    routing table.



    > I set up a DMVPN with NHRP between two networks connected to the UMTS
    > net (my spokes) and one connected via DSL (my hub).
    >
    > Everything seems to be fine, but when I traceroute from one spoke to
    > the other, I find that they communicate via the hub, and not - as I
    > expect - directly with each other.
    >
    > The "show ip nhrp" output tells me, that the spokes learned the other
    > spoke´s outside IP address so they ought to be able to connect
    > directly to each other without the hub in between.
    >
    > I attach the "show ip nhrp" output from one of my spokes, the
    > "traceroute" output of the same spoke an my configurations.
    >
    > I use eigrp for routing.
    >
    > Maybe someone has an idea?
    >
    > Thank´s a lot.
    > Mathias
    >
    >
    > Spoke Router:
    >
    > RT_UMTS#sho ip nhrp
    > 172.16.1.10/32 via 172.16.1.10, Tunnel0 created 00:25:04, never expire
    > Type: static, Flags:
    > NBMA address: 1.2.3.4
    > 172.16.1.30/32 via 172.16.1.30, Tunnel0 created 00:08:13, expire
    > 01:52:42
    > Type: dynamic, Flags: router implicit
    > NBMA address: 80.187.114.1
    > (Claimed NBMA address: 172.20.225.217)
    > (no-socket)
    > 192.168.30.10/32, Tunnel0 created 00:00:06, expire 00:02:58
    > Type: incomplete, Flags: negative
    > Cache hits: 1
    >
    > RT_UMTS#traceroute 192.168.30.10
    >
    > Type escape sequence to abort.
    > Tracing the route to 192.168.30.10
    >
    > 1 172.16.1.10 228 msec 260 msec 228 msec
    > 2 172.16.1.30 460 msec 468 msec 460 msec
    > 3 192.168.30.10 468 msec 1200 msec 448 msec
    >
    >
    >
    > Spoke Router:
    >
    > interface FastEthernet0/0
    > ip address 192.168.20.1
    >
    > interface Tunnel0
    > ip address 172.16.1.20 255.255.255.0
    > ip mtu 1400
    > ip nhrp authentication DMVPN_NW
    > ip nhrp map multicast dynamic
    > ip nhrp map 172.16.1.10 1.2.3.4
    > ip nhrp network-id 1
    > ip nhrp nhs 172.16.1.10
    > ip nhrp cache non-authoritative
    > ip nhrp shortcut
    > ip nhrp redirect
    > ip tcp adjust-mss 1360
    > delay 1000
    > cdp enable
    > tunnel source Cellular0/1/0
    > tunnel destination 1.2.3.4
    > tunnel key 10000
    > tunnel protection ipsec profile DMVPN-PROF
    >
    > Hub Router:
    >
    > interface Tunnel0
    > ip address 172.16.1.10 255.255.255.0
    > no ip redirects
    > ip mtu 1400
    > ip nhrp authentication DMVPN_NW
    > ip nhrp map multicast dynamic
    > ip nhrp network-id 1
    > ip nhrp holdtime 360
    > ip nhrp cache non-authoritative
    > ip nhrp redirect
    > ip tcp adjust-mss 1360
    > no ip split-horizon eigrp 1
    > delay 1000
    > cdp enable
    > tunnel source Dialer1
    > tunnel mode gre multipoint
    > tunnel key 10000
    > tunnel protection ipsec profile DMVPN-PROF
    Helmut, Oct 10, 2008
    #2
    1. Advertising

  3. In article
    <>,
    <> wrote:
    > I set up a DMVPN with NHRP between two networks connected to the UMTS
    > net (my spokes) and one connected via DSL (my hub).
    >
    > Everything seems to be fine, but when I traceroute from one spoke to
    > the other, I find that they communicate via the hub, and not - as I
    > expect - directly with each other.
    >
    > The "show ip nhrp" output tells me, that the spokes learned the other
    > spoke´s outside IP address so they ought to be able to connect
    > directly to each other without the hub in between.
    >
    > I attach the "show ip nhrp" output from one of my spokes, the
    > "traceroute" output of the same spoke an my configurations.
    >
    > I use eigrp for routing.
    >
    > Maybe someone has an idea?
    >
    > Thank´s a lot.
    > Mathias


    <snip>


    > Spoke Router:
    >
    > interface FastEthernet0/0
    > ip address 192.168.20.1
    >
    > interface Tunnel0
    > ip address 172.16.1.20 255.255.255.0
    > ip mtu 1400
    > ip nhrp authentication DMVPN_NW
    > ip nhrp map multicast dynamic
    > ip nhrp map 172.16.1.10 1.2.3.4
    > ip nhrp network-id 1
    > ip nhrp nhs 172.16.1.10
    > ip nhrp cache non-authoritative
    > ip nhrp shortcut
    > ip nhrp redirect
    > ip tcp adjust-mss 1360
    > delay 1000
    > cdp enable
    > tunnel source Cellular0/1/0
    > tunnel destination 1.2.3.4
    > tunnel key 10000
    > tunnel protection ipsec profile DMVPN-PROF


    On the spokes, you only need "ip nhrp shortcut", but for dynamic
    spoke-to-spoke connectivity, you need to configure a multipoint GRE (mGRE)
    tunnel interface on the spokes (similar configuration to the hub); this is
    a pt-pt spoke as there is a "tunnel destination" command present.

    As you're using DMVPN Phase 3 (i.e. in 12.4(6)T or later) with NHRP
    shortcuts, then it's possible to have just a summary route advertised from
    the hub(s), and the improved NHRP process will correctly determine the
    next-hop. Note that traffic will still be forwarded via the hub until the
    spoke-spoke tunnel is built.

    I'd also consider configuring a hold timer on all tunnels, (ip nhrp
    holdtime 300 is recommended).

    Cheers,

    Matt

    --
    Matthew Melbourne
    Matthew Melbourne, Oct 10, 2008
    #3
  4. Guest

    Thank you guys for your hints.

    Helmut, I followed your suggestion ("Add the line "no ip next-hop-self
    eigrp 1" to the tunnel configuration of your hub router. Reset the
    eigrp adjacency and look again into your routing table."), but it did
    not change the situation; I still have only the hub router as an eigrp
    neighbor.

    Matt, do you suggest to configure an additional tunnel interface for
    the spoke-to-spoke communication, or do you want me to change my
    existing Tunnel0 interface into a mGRE tunnel?

    ("for dynamic spoke-to-spoke connectivity, you need to configure a
    multipoint GRE (mGRE) tunnel interface on the spokes (similar
    configuration to the hub); this is a pt-pt spoke as there is a "tunnel
    destination" command present.")

    As I can either have a tunnel destination or a multipoint GRE tunnel,
    how would find the spokes their hub then (if I change my T0
    interface)?

    Mathias
    , Oct 14, 2008
    #4
  5. In article
    <>,
    <> wrote:
    >
    > Matt, do you suggest to configure an additional tunnel interface for
    > the spoke-to-spoke communication, or do you want me to change my
    > existing Tunnel0 interface into a mGRE tunnel?
    >
    > ("for dynamic spoke-to-spoke connectivity, you need to configure a
    > multipoint GRE (mGRE) tunnel interface on the spokes (similar
    > configuration to the hub); this is a pt-pt spoke as there is a "tunnel
    > destination" command present.")
    >
    > As I can either have a tunnel destination or a multipoint GRE tunnel,
    > how would find the spokes their hub then (if I change my T0


    You only need a single mGRE tunnel interface; NHRP will discover the Hub.

    Here's a fragment from a working lab configuration (which was dual hubs
    within a single DMVPN network, but a similar configuration with the
    addition of "ip nhrp shortcut" should permit the dynamic spoke-spoke
    tunnels).

    interface Tunnel0
    bandwidth 10000
    ip address 10.0.1.1 255.255.255.0
    no ip redirects
    ip mtu 1400
    ip nhrp authentication cisco
    ip nhrp map multicast 192.0.2.254
    ip nhrp map 10.0.1.254 192.0.2.254
    ip nhrp map multicast 192.0.2.253
    ip nhrp map 10.0.1.253 192.0.2.253
    ip nhrp network-id 1
    ip nhrp holdtime 300
    ip nhrp nhs 10.0.1.254
    ip nhrp nhs 10.0.1.253
    ip nhrp shortcut
    ip nhrp registration no-unique
    ip nhrp cache non-authoritative
    ip tcp adjust-mss 1360
    delay 1000
    tunnel source FastEthernet0/0
    tunnel mode gre multipoint
    !
    interface FastEthernet0/0
    description DMVPN Spoke-1 NBMA Address
    ip address 192.0.2.1 255.255.255.0
    duplex half
    speed auto

    interface FastEthernet1/0
    ip address 10.200.0.1 255.255.255.0
    duplex auto
    speed auto
    no keepalive
    !
    router eigrp 1
    network 10.0.0.0
    no auto-summary
    eigrp stub connected

    Cheers,

    Matt

    --
    Matthew Melbourne
    Matthew Melbourne, Oct 14, 2008
    #5
  6. Helmut Guest

    Hi Mathias,

    sorry I have not seen that your spoke tunnel is configured as point to
    point. Please follow the instruction from Matt and it should work.

    Regards
    Helmut

    > Thank you guys for your hints.
    >
    > Helmut, I followed your suggestion ("Add the line "no ip next-hop-self
    > eigrp 1" to the tunnel configuration of your hub router. Reset the
    > eigrp adjacency and look again into your routing table."), but it did
    > not change the situation; I still have only the hub router as an eigrp
    > neighbor.
    >
    > Matt, do you suggest to configure an additional tunnel interface for
    > the spoke-to-spoke communication, or do you want me to change my
    > existing Tunnel0 interface into a mGRE tunnel?
    >
    > ("for dynamic spoke-to-spoke connectivity, you need to configure a
    > multipoint GRE (mGRE) tunnel interface on the spokes (similar
    > configuration to the hub); this is a pt-pt spoke as there is a "tunnel
    > destination" command present.")
    >
    > As I can either have a tunnel destination or a multipoint GRE tunnel,
    > how would find the spokes their hub then (if I change my T0
    > interface)?
    >
    > Mathias
    Helmut, Oct 15, 2008
    #6
  7. Guest

    Thank´s again, Helmut and Matt!

    Matt, my problem is, that at the spokes, which are connected to the
    UMTS network, I do not have static IP addresses - each time they are
    switched off and on again, they have another address. I only have a
    static address for my hub router which is connected to the ADSL
    network (which is the 1.2.3.4 in my configuration).

    It is not possible here in Germany to get a static IP address for
    UMTS.

    Sorry, I missed to give you that information.

    So I cannot just add another "ip nhrp map" with the address of my
    other spoke as your example suggests.

    Do you see any chance to get this running with changing IP addresses
    at the spokes?

    Thank´s again
    Mathias
    , Oct 15, 2008
    #7
  8. In article
    <>,
    <> wrote:
    > Thank´s again, Helmut and Matt!


    > Matt, my problem is, that at the spokes, which are connected to the UMTS
    > network, I do not have static IP addresses - each time they are switched
    > off and on again, they have another address. I only have a static
    > address for my hub router which is connected to the ADSL network (which
    > is the 1.2.3.4 in my configuration).
    >
    > It is not possible here in Germany to get a static IP address for UMTS.


    No, you don't need static IPs on the spokes. Just configure your 'ip nhrp
    map' with the address of the hub; NHRP sorts out everything else. Your hub
    will advertise routes to the other spokes (or just a summary/default
    route) via the mGRE tunnel interface. NHRP will determine next-hop
    addresses, so you don't need a "tunnel destination" on the spoke; just an
    mGRE interface.

    For spoke-to-spoke connectivity, the initial packets will go via the hub
    which will issue NHRP redirects telling the spokes of the direct address
    they can use to reach the spokes. There needs to be an mGRE interface on
    the spokes to terminate (potentially multiple) dynamic spoke-to-spoke
    tunnels.

    Just remove your 'tunnel destination' and turn it into a mGRE tunnel
    interface and everything should just work.

    Cheers,

    Matt

    --
    Matthew Melbourne
    Matthew Melbourne, Oct 15, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Martindale
    Replies:
    1
    Views:
    442
  2. Andy
    Replies:
    7
    Views:
    4,390
    tpt_mike
    Apr 26, 2007
  3. David Ellis

    10D software behaves badly - what's your experience?

    David Ellis, Oct 1, 2003, in forum: Digital Photography
    Replies:
    10
    Views:
    727
    Kenny
    Oct 3, 2003
  4. Doc
    Replies:
    1
    Views:
    420
    Jon Kennedy
    Feb 24, 2007
  5. write2atif
    Replies:
    0
    Views:
    4,261
    write2atif
    Apr 30, 2009
Loading...

Share This Page