DMVPN Question

Hi, this may be a silly question but I've been scratching my head with it.

I'm working the dual hub single DMVPN cloud. The thing is that everything works, I have the tunnels working and the routes are been learned as expected.

The weird thing is that I just can see the EIGRP neighbors from the hubs, is that normal?

should I see the spokes neighbors? I have that question because theres no tunnel until we create some traffic, it must be up with the EIGRP hellos right?

Heres the configuration, may be Im leaving something out:

HUB 1

interface Tunnel0
 ip address 172.16.23.1 255.255.255.0
 no ip redirects
 no ip next-hop-self eigrp 123
 no ip split-horizon eigrp 123
 ip nhrp authentication donttell
 ip nhrp map multicast dynamic
 ip nhrp network-id 99
 ip nhrp shortcut
 ip nhrp redirect
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100000
 tunnel protection ipsec profile vpnprof
end

router eigrp 123
 network 10.2.2.0 0.0.0.255
 network 172.16.23.0 0.0.0.255

HUB 2

interface Tunnel0
 ip address 172.16.23.2 255.255.255.0
 no ip redirects
 no ip next-hop-self eigrp 123
 no ip split-horizon eigrp 123
 ip nhrp authentication donttell
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.23.1 172.16.18.1
 ip nhrp map multicast 172.16.18.1
 ip nhrp network-id 99
 ip nhrp nhs 172.16.23.1
 ip nhrp shortcut
 ip nhrp redirect
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100000
 tunnel protection ipsec profile vpnprof
end

router eigrp 123
 network 10.2.2.0 0.0.0.255
 network 172.16.23.0 0.0.0.255

SPOKE 1

interface Tunnel0
 ip address 172.16.23.4 255.255.255.0
 no ip redirects
 ip nhrp authentication donttell
 ip nhrp map 172.16.23.1 172.16.18.1
 ip nhrp map multicast 172.16.18.1
 ip nhrp map 172.16.23.2 172.16.18.2
 ip nhrp map multicast 172.16.18.2
 ip nhrp network-id 99
 ip nhrp holdtime 300
 ip nhrp nhs 172.16.23.1
 ip nhrp nhs 172.16.23.2
 ip nhrp shortcut
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 100000
 tunnel protection ipsec profile vpnprof
end

router eigrp 123
 network 10.2.2.0 0.0.0.255
 network 172.16.23.0 0.0.0.255

I dont think we need the other spokes config since its the same and just change the tunnel ip address.

heres the output of routes and neighbors.

spoke routing table:

      10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D        10.2.2.1/32 [90/27008000] via 172.16.23.1, 00:11:02, Tunnel0
D        10.2.2.2/32 [90/27008000] via 172.16.23.2, 00:11:02, Tunnel0
D        10.2.2.4/32 [90/28288000] via 172.16.23.5, 00:11:02, Tunnel0
                     [90/28288000] via 172.16.23.5, 00:11:02, Tunnel0

spoke neighbors:

1   172.16.23.1             Tu0                      12 00:11:37    6  1428  0  80
0   172.16.23.2             Tu0                      11 00:11:46   18  1470  0  82

hub routing table:

D        10.2.2.2/32 [90/27008000] via 172.16.23.2, 00:25:00, Tunnel0
D        10.2.2.3/32 [90/27008000] via 172.16.23.4, 00:13:02, Tunnel0
D        10.2.2.4/32 [90/27008000] via 172.16.23.5, 00:13:02, Tunnel0

hub neighbors:

2   172.16.23.5             Tu0                      14 00:13:28   23  1434  0  66
1   172.16.23.4             Tu0                      10 00:13:28    3  1434  0  63
0   172.16.23.2             Tu0                      12 00:25:23    9  1434  0  82

As you can see the hubs can see all the neighbors but the spokes just see the hubs neighbors.

I understand that the hubs are the ones who control the routing traffic, thats why we need the no split-horizon and the no next-hop self but I want to be sure.

Any ideas?

Regards

Conesh

«1

Comments

  • JoeMJoeM ✭✭✭

    Hi Conesh,

    You are using DMVPN phase-3. Try removing the lines that I have highlighted.  See if that makes a difference.

     

    HUB 1

    interface Tunnel0
     ip address 172.16.23.1 255.255.255.0
     no ip redirects
     no ip next-hop-self eigrp 123  <-- for phase-2. remove for phase-3
     no ip split-horizon eigrp 123
     ip nhrp authentication donttell
     ip nhrp map multicast dynamic
     ip nhrp network-id 99
     ip nhrp shortcut   <-- ??? for the other hub?
     ip nhrp redirect
     tunnel source GigabitEthernet0/0
     tunnel mode gre multipoint
     tunnel key 100000
     tunnel protection ipsec profile vpnprof
    end

    router eigrp 123
     network 10.2.2.0 0.0.0.255
     network 172.16.23.0 0.0.0.255

    HUB 2

    interface Tunnel0
     ip address 172.16.23.2 255.255.255.0
     no ip redirects
     no ip next-hop-self eigrp 123  <--- not needed in phase-3
     no ip split-horizon eigrp 123
     ip nhrp authentication donttell
     ip nhrp map multicast dynamic
     ip nhrp map 172.16.23.1 172.16.18.1
     ip nhrp map multicast 172.16.18.1
     ip nhrp network-id 99
     ip nhrp nhs 172.16.23.1
     ip nhrp shortcut  <-- ???
     ip nhrp redirect
     tunnel source GigabitEthernet0/0
     tunnel mode gre multipoint
     tunnel key 100000
     tunnel protection ipsec profile vpnprof
    end

     

  • Hi,

    tunnel interface (protected or not) is up by default without any traffic (not like with IPsec tunnel). In DMVPN Hub-Spoke tunnel is up all the time. The only one difference is with spoke-to-spoke communication (supported by phase 2 and 3) where the tunnel is created dynamically when required
    regards

    Hubert

  • Try that, no luck :( everything works fine with the traffic the only thing is that Im not sure if I need to see the spokes as neighbors between them.

     

    Thanks for your help

  • JoeMJoeM ✭✭✭

    Oh ok.  I misunderstood.  

    No, the spokes are never eigrp neighbors to each other.  The "nhrp redirect" is for specific routes.

  • Got it!! thanks for making it clear.

    Regards.

    Conesh

  • Dears,
    Maybe i missed something regarding ip nhrp redirect and ip nhrp shortcut:
    Which one(s) do we add on the hub side and which one(s) do we add on the spoke side?
    Some guides show that only ip nhrp redirect is applied on the hub and both on the spoke while in other documents, the reverse is correct.
    Please advise about their usage specially when i have a single hub or dual hub.

  • Hi,

     

    "


    To enable NHRP shortcut switching:


    • All spokes need to have the commands ip nhrp shortcut and the ip nhrp redirect added to their tunnel interfaces. For the hubs use only ip nhrp redirect.

    "

    I recommend this white paper:

    http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/converged-vpn-solution-managed-services/prod_white_paper0900aecd8055c34e.html

     

    regards

    Hubert

  • Hi,

       Cisco documentation is not clear when should you use which command, where and why. Just to clarify, in a Phase3 non-hierarchical DMVPN deployment (number of hubs does not matter), "nhrp redirect" is required only on hub, while "nhrp shortcut" only on spokes; redirect on hub is required because when the hub receives traffic inbound on the tunnel from one spoke and routes it out the same tunnel towards another spoke, it will send a NHRP Redirect on the initiating spoke which will trigger the NHRP Resolution Request on the spoke in order to build the spoke-to-spoke tunnel; shortcut is required on spokes so that when NHRP builds the spoke-to-spoke tunnel, routing table gets modified by NHRP routes or NHO(next-hop-override) depending how routing is configured over DMVPN.

       Spoke to-spoke routing is not needed, but you can make it happen with unicast adjacency (as by default spoke-to-spoke tunnel is not multicast enabled), or with multicast adjacency if you statically configure spoke-to-spoke to be multicast enabled.

    Regards,

    Cristian.

     

  • nothing will happen, dmvpn will work as expected even if you have both commands on hub/spoke (try it! =) )

  • Why would you add unneeded command in unneeded places?

    Sent from my iPhone

    On Apr 8, 2015, at 22:22, Martinl <[email protected]> wrote:

    I know hub can have both  ip nhrp redirect and ip nhrp shortcut. but can spoke have both?  what happens when u add  ip nhrp redirect to spoke?




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • JoeMJoeM ✭✭✭

    well, in case of a mistake or if u don't remember which goes where.

    good to know it works either way.

    BUZZZZ  sorry  wrong answer  

    [8-|]

    But seriously, these configs should be down solid, or DMVPN is going to be a huge problem.  Very basic if we know the steps (including with crypto and/or nat)    No doubts.  IMO, dmvpn should be easy.  Nothing really tricky about it.

  • Hi,

        Here, again, Cisco documentation is wrong; network id does NOT have to match because it is a value which is not sent in any headers, it is only used to activate NHRP on the tunnel. Still, NHRP network ID has to match in hierarchical DMVPN, but beetween different tunnel interfaces on the same router. As for the lab tshoot ticket, a tshoot ticket means something does not work because of a missconfiguration; so why would you correct it if it has nothing to do with the problem?

    Regards,

    Cristian.

  • JoeMJoeM ✭✭✭

    heheh it is called creative thinking hehehe


    well, recently I found out that ip nhrp network-id x does not
    have to match between hub-spokes.  everyone was arguing that it must
    match. now, lab TS ticket, would you correct it even thou it is not causing the
    main problem?


    same with shortcut and redirect, if u see both on hub and
    spokes in TS ticket but those are not "causing problem", would you correct it, remove it?


    Thinking here is that removing config lines from TS sections is not recommanded, right?  Suggestion is to edit incorect line rather than remove it.

     

    You should have talked to me.  hee hee   I have never said that network-id's have to match, but it is mandatory --  or the tunnel will not come up.   I always look to be sure a network-id exists on a dmvpn tunnel config.

    Would I change it if it was preconfigured?   It would be a waste of time to put thinking cycles into changing the network-id.  It doesn't matter, unless the ticket says that it must be X or Y.

    BUT remember that tunnel keys  do have to match (but are optional). That number does matter.

     

    Would I change/remove shortcut or redirect?   yes   

    not needed in phase-2     needed in phase 3 

    hub (redirects the spokes)    spokes (request a shortcut)

  • Hi,

       The tunnel logical state (UP/DOWN) is NOT  dependent on NHRP network-id being configured or not. But if that command is missing, NHRP is not active, which means spoke-to-hub is not established, thus any spoke-to-spoke tunnel cannot be established.

    Regards,

    Cristian.

  • JoeMJoeM ✭✭✭

    Interesting.  Thanks for the correction.   I will play with this on my next dmvpn setup.

  • Sometimes, they ask us to tshoot a question and they specify the number of config errors. In this case, we need to count them or the answer will be wrong.

  • JoeMJoeM ✭✭✭

    I have never seen a count of errors.   I think this is a myth. 

    What I have seen in the past with some INE questions, are restrictions.  For example, an access-list needs to be one-line, or make changes only on this router etc etc.

    The tshoot tickets say that there is a problem -- and here is a verification -- something that isn't happening and needs to be fixed.

  • A config error does not mean one command, thus there is nothing to count; they say that just to help you out;a config error means like for example NSSA area is missconfigured.

    Sent from my iPhone

    On Apr 9, 2015, at 19:07, moustapha <[email protected]> wrote:

    Sometimes, they ask us to tshoot a question and they specify the number of config errors. In this case, we need to count them or the answer will be wrong.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • JoeMJoeM ✭✭✭


    ....


       The tunnel logical state (UP/DOWN) is NOT  dependent on NHRP network-id being configured or not. But if that command is missing, NHRP is not active, which means spoke-to-hub is not established, thus any spoke-to-spoke tunnel cannot be established.


    ....



    Hi Cristian, I just tested this, and it is as I previously thought it was. 

    DMVPN tunnels will not come up (spoke-to-hub) without a network-id.   

    Very basic tests fail:  end-to-end tunnel pings,  no IGP neighbor connectivity (hub-to-spoke).

     

    As soon as the nhrp network-id is input, it is possible to ping tunnel end-to-end (spoke-to-hub) and the IGP neighbors come up.

     NHRP Network-ID is mandatory on all end-points of DMVPN Tunnels.

  • Hi, 

       I gues you did not read my statements clear enough. I said that "network id does NOT have to match because it is a value which is not sent in any headers, it is only used to activate NHRP on the tunnel."  and that " But if that command is missing, NHRP is not active, which means spoke-to-hub is not established, thus any spoke-to-spoke tunnel cannot be established." How could any spoke-to-hub or spoke-to-spoke tunnel be formed if NHRP is not working, cause it is not active? So, yes, NHRP network ID is mandatory to enable NHRP.

       The tunnel interface logical state does NOT depend on NHRP being active or not, on the spoke being able to succesfully register to the hub or not (by default, as this can be changed). A mGRE interface is in the UP/UP state as long as the tunnel source is UP/UP. A PTP GRE interface is in the UP/UP state as long as tunnel source is UP/UP and the router has a route to the tunnel destination (of course, without GRE keepalives being set, which by default are not).

      Hopefully I've made myself clear enough this time.

    Regards,

    Cristian.

  • If i understand it correctly, the network-id must match on all routers sharing the same GRE tunnel. right? or things have changed in the newer implementations?

    Thanks

     

     

    Hi, 

       I gues you did not read my statements clear enough. I said that "network id does NOT have to match because it is a value which is not sent in any headers, it is only used to activate NHRP on the tunnel."  and that " But if that command is missing, NHRP is not active, which means spoke-to-hub is not established, thus any spoke-to-spoke tunnel cannot be established." How could any spoke-to-hub or spoke-to-spoke tunnel be formed if NHRP is not working, cause it is not active? So, yes, NHRP network ID is mandatory to enable NHRP.

       The tunnel interface logical state does NOT depend on NHRP being active or not, on the spoke being able to succesfully register to the hub or not (by default, as this can be changed). A mGRE interface is in the UP/UP state as long as the tunnel source is UP/UP. A PTP GRE interface is in the UP/UP state as long as tunnel source is UP/UP and the router has a route to the tunnel destination (of course, without GRE keepalives being set, which by default are not).

      Hopefully I've made myself clear enough this time.

    Regards,

    Cristian.

     

  • JoeMJoeM ✭✭✭

    ...The tunnel interface logical state does NOT depend on NHRP being active or not, on the spoke being able to succesfully register to the hub or not (by default, as this can be changed). A mGRE interface is in the UP/UP state as long as the tunnel source is UP/UP. A PTP GRE interface is in the UP/UP state as long as tunnel source is UP/UP and the router has a route to the tunnel destination (of course, without GRE keepalives being set, which by default are not).

    Maybe we agreed from the start, but the words being used are confusing things.   

    No candidates should be confused about this.

     

    Two important points that I made earlier about network-id

    1. Network-ID's do NOT have to match on a tunnel.  No confusion. We agree on this.

    2. the network-id is "mandatory" for the tunnels to come up (miniminal ping end-to-end tunnels.)

     

    For me, I never depend on up/up status, when I consider whether a tunnel is up or not.   A tunnel being up (for me), at a minimum must be able to ping the other side of the tunnel (simple one-to-one tunnel connection).

    If anyone wants to test this and see for themselves...

    1.  remove the network-id, and bounce the tunnel interface.  

    2.  try pinging the other end of the tunnel (does not work. tunnel not up)

    3.  add the network-id (immediate success on pings and IGP neighbors connect)

     

    Maybe we always agreed, but are saying it differently. ;-)

     

  • JoeMJoeM ✭✭✭

    If i understand it correctly, the network-id must match on all routers sharing the same GRE tunnel. right? or things have changed in the newer implementations?

    Not correct.  Be very clear on this.  It will save brain cycles in the exam. ;-)

    network-id must exist -- but does NOT have to match. period

    tunnel key must match -- but are optional.

  • Hi,

       Yes we agree, however, you need to make a difference between the logical state of the interface (and what are the conditions for it) and the tunnel actually being functional (and what are the requirements for that).

    Regards,
    Cristian. 

  • [Y]  Good points!

     

    Hi,

       Yes we agree, however, you need to make a difference between the logical state of the interface (and what are the conditions for it) and the tunnel actually being functional (and what are the requirements for that).

    Regards,
    Cristian. 

     

  • JoeMJoeM ✭✭✭

    Yes  Good points!




       Yes we agree, however, you need to make a difference between the logical state of the interface (and what are the conditions for it) and the tunnel actually being functional (and what are the requirements for that).


     





     

    I think talking about the "logical state" of one end of tunnel only confuses people.  This is why Candidates may be confused about the minimal requirements for DMVPN to come up.  If a Candidate knows the minimal configurations, it is very easy to look at two DMVPN interfaces and immediately see any issues (i.e. in all phases, with/without crypto).  HUGE TIME SAVED on lab exam tickets.

           show dmvpn   

    .....if the DMVPN tunnel says UP on either side, then ping verify the other side

    .....then verify that IGP neighbors come up over the tunnel (multicast vs static neighbors)

     

    I mean no disrespect, but I do not see a benefit to this thinking of the "logical state" (up/up) state
    vs having working DMVPN tunnels that can ping verify the other end.  
    Points on the exam require stable working tunnels.       

    UP/UP does not matter if one end of the tunnel
    cannot ping the other end of the tunnel.    A Candidate who thinks this matters will probably spend 30+ minutes on a single ticket -- vs understanding the basic DMVPN steps and then just moving along (with the requirements fulfilled).

    DMVPN should be easy points, whether it is a TS ticket or Config task.  Very basic (almost template), even with crypto or VRF's.

     

  • Hi,

    It's not about respect here. If the tunnel state is UP/DOWN you need to know why, when it becomes UP/UP and still spoke-to-hub tunnel or spoke-to-spoke is not functional you need to know why. Because the answer is different. In the lab you don't think REAL LIFE, you think technology wise, how does it work, and do only what you're told, it does not matter if it makes sense or not.

    If you just know the full template and don't know exactly which commands achieves what (like keep the tunnel UP/UP or make it actually work) you're not ready for the lab.

    Regards,

    Cristian.

  • JoeMJoeM ✭✭✭

    Hello Cristian,

    I appreciate you taking your time to help us candidates on these details.  I trust you, so I cannot walk away from this conversation, until I discover what I am missing.  Please explain the difference. You are making me doubt myself on this topic.  ;-)

    As far as being "ready for the lab" on this subject,  I invite CISCO to throw DMVPN at me in the R&S exam.   EASY FUN POINTS.  100's of hours spent just on mastering DMVPN configs. Bring it on Cisco!!! ;-)

     

    Below without any doubts (quick lab), I made the minimum config lines on R1's tunnel interface -- and no problems -- UP/UP.  Worthless status IMO.

    TEST-1:   I maintain that an UP/UP on a tunnel (which is a logical interface) does not matter at all for the purposes of a DMVPN connectivity.   It is a distractor from real DMVPN troubleshooting.  Completely worthless status.  Waste of time.

    I was able to break the UP/UP, by using TUN SOURCE F0/1, an interface without an IP ADDRESS/and shut down.  But as soon as I gave a random address on f0/1 -- UP/UP.  Worthless status for a DMVPN setup.

     

    Note:  this quick test is in GNS (lab exam is in IOU).  I believe it would be the same on hardware, because the tunnel is a logical interface.

                R1 <---> R2

    R2 has no configuration on anything.  All interfaces are down. default startup.

    R1 has a minimal config......and miraculously.....the tunnel is in UP/UP ????  

     

    R1# sh ip int br
    Interface                  IP-Address      OK? Method Status            Protocol
    FastEthernet0/0            12.12.12.1      YES manual up                    up
    FastEthernet0/1            unassigned      YES unset  administratively down down
    <snip>
    Loopback0                  1.1.1.1         YES manual up                    up
    Tunnel0                    12.0.0.1        YES manual up                 up

    R1# sh run int tun 0
    <snip>
    interface Tunnel0
          ip address 12.0.0.1 255.255.255.0
          no ip redirects
          tunnel source FastEthernet0/0
          tunnel mode gre multipoint 

     

    NOW let's look at R2's direct connection (f0/0)  to R1's f0/0.  Nothing is configured yet.

    R2# show ip int br
    Interface                  IP-Address      OK? Method Status             Protocol
    FastEthernet0/0            unassigned      YES unset  administratively down down
    FastEthernet0/1            unassigned      YES unset  administratively down down
    Serial1/0                  unassigned      YES unset  administratively down down
    Serial1/1                  unassigned      YES unset  administratively down down
    Serial1/2                  unassigned      YES unset  administratively down down
    Serial1/3                  unassigned      YES unset  administratively down down
          NO CONFIGURATION ON R2.  NO TUNNEL CREATED.   R1 IS LYING.  ;-)

     

     

    TEST-2:   same situation...with the following changes on R1 tunnel.

    remove mode --  NO TUNNEL MODE GRE MULTIPOINT

    add fake destination  -- TUN destination 2.2.2.2  (using a default route)

     

    same result,  the tunnel thinks it knows where the destination is, so it says UP/UP.

  • Tunnel is a virtual overly network. If the local interface which is the source for the tunnel is up with any IP address, does not matter if its correct IP or not it will show UP/UP. Tunnel does not care about the other end. we have to fix the underlying network for virtual/tunnel to make it work :-) before we can do anything with tunnels.

    HTH

     

     

    Hello Cristian,

    I appreciate you taking your time to help us candidates on these details.  I trust you, so I cannot walk away from this conversation, until I discover what I am missing.  Please explain the difference. You are making me doubt myself on this topic.  ;-)

    As far as being "ready for the lab" on this subject,  I invite CISCO to throw DMVPN at me in the R&S exam.   EASY FUN POINTS.  100's of hours spent just on mastering DMVPN configs. Bring it on Cisco!!! ;-)

     

    Below without any doubts (quick lab), I made the minimum config lines on R1's tunnel interface -- and no problems -- UP/UP.  Worthless status IMO.

    TEST-1:   I maintain that an UP/UP on a tunnel (which is a logical interface) does not matter at all for the purposes of a DMVPN connectivity.   It is a distractor from real DMVPN troubleshooting.  Completely worthless status.  Waste of time.

    I was able to break the UP/UP, by using TUN SOURCE F0/1, an interface without an IP ADDRESS/and shut down.  But as soon as I gave a random address on f0/1 -- UP/UP.  Worthless status for a DMVPN setup.

     

    Note:  this quick test is in GNS (lab exam is in IOU).  I believe it would be the same on hardware, because the tunnel is a logical interface.

                R1 <---> R2

    R2 has no configuration on anything.  All interfaces are down. default startup.

    R1 has a minimal config......and miraculously.....the tunnel is in UP/UP ????  

     

    R1# sh ip int br
    Interface                  IP-Address      OK? Method Status            Protocol
    FastEthernet0/0            12.12.12.1      YES manual up                    up
    FastEthernet0/1            unassigned      YES unset  administratively down down
    <snip>
    Loopback0                  1.1.1.1         YES manual up                    up
    Tunnel0                    12.0.0.1        YES manual up                 up

    R1# sh run int tun 0
    <snip>
    interface Tunnel0
          ip address 12.0.0.1 255.255.255.0
          no ip redirects
          tunnel source FastEthernet0/0
          tunnel mode gre multipoint 

     

    NOW let's look at R2's direct connection (f0/0)  to R1's f0/0.  Nothing is configured yet.

    R2# show ip int br
    Interface                  IP-Address      OK? Method Status             Protocol
    FastEthernet0/0            unassigned      YES unset  administratively down down
    FastEthernet0/1            unassigned      YES unset  administratively down down
    Serial1/0                  unassigned      YES unset  administratively down down
    Serial1/1                  unassigned      YES unset  administratively down down
    Serial1/2                  unassigned      YES unset  administratively down down
    Serial1/3                  unassigned      YES unset  administratively down down
          NO CONFIGURATION ON R2.  NO TUNNEL CREATED.   R1 IS LYING.  ;-)

     

     

    TEST-2:   same situation...with the following changes on R1 tunnel.

    remove mode --  NO TUNNEL MODE GRE MULTIPOINT

    add fake destination  -- TUN destination 2.2.2.2  (using a default route)

     

    same result,  the tunnel thinks it knows where the destination is, so it says UP/UP.

     

  • JoeMJoeM ✭✭✭

    Tunnel is a virtual overly network. If the local interface which is the source for the tunnel is up with any IP address, does not matter if its correct IP or not it will show UP/UP. Tunnel does not care about the other end. we have to fix the underlying network for virtual/tunnel to make it work :-) before we can do anything with tunnels.


    HTH

     

    Friend, I am giving you a gift.  Don't be confused by the config lines (i.e. network-id matching?, logical UP/UP?, etc etc etc).

    If you want to mess around with this as part of your TS/CONFIG verification in the real exam,  then go for it.  But the clock is ticking. 

     

    You should be able to look at the tunnel and crypto configs (as well as NAT) and 1,2,3 VERIFY...DONE.  It really is that easy.

    If you cannot get it by looking at the config -- then know the DEBUG and SHOW commands for the different steps.

     

    Don't waste your time with useless information.  You will kick yourself at the end of the exam for wasting time. I have already shown in the posted tests (my own sanity check) that UP/UP is useless for tunnel interfaces.  

    DMVPN and verification of the steps (TS) are important.   Also know the IGP fixes.

Sign In or Register to comment.