We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 605 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


361 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. That would be a good idea. I’ll write something soon.

  2. Hi Adrian,

    Once the GRE tunnel is up, it acts like a regular interface. With normal interfaces we also don’t see the next hop IP address within the IP packet.

    Here’s the logic of the router:

    1. When HQ sends a packet with destination it has to check its routing table for a match:
    HQ#show ip route eigrp 
 is variably subnetted, 3 subnets, 2 masks
    D [90/27008000] via, 00:00:07, Tunnel1
    1. Above you can see that the next hop is the remote IP address of the tunnel. Now it has to do another lookup to figure out how to get there:
    HQ#show ip route
    Routing entry for
      Known via "connected", distance 0, metric 0 (connected, via interface)
      Redistributing via eigrp 13
      Routing Descriptor Blocks:
      * directly connected, via Tunnel1
          Route metric is 0, traffic share count is 1
    1. To the router, the tunnel interface is “directly connected”. With regular interfaces (FastEthernet / Gigabit etc) this means we can do an ARP for the IP address and reach it directly. However this time, the router knows we are using a GRE interface so it will encapsulate the IP packet…its puts a GRE header in front of it and a new IP header with the source/destination IP addresses that we used to build the tunnel:
    HQ#show interfaces tunnel 1 | include source
      Tunnel source, destination
    1. Now the router will have to figure out how to get to, the tunnel destination so it does another lookup:
    HQ#show ip route
    Routing entry for
      Known via "static", distance 1, metric 0
      Routing Descriptor Blocks:
          Route metric is 0, traffic share count is 1
    1. It sees there is a static route for with as the next hop. Time to figure out how to get there:
    HQ#show ip route
    Routing entry for
      Known via "connected", distance 0, metric 0 (connected, via interface)
      Routing Descriptor Blocks:
      * directly connected, via GigabitEthernet0/1
          Route metric is 0, traffic share count is 1

    This IP address can be reached directly since we have an interface that is directly connected to Time to figure out the L2 address:

    HQ#show ip arp
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet           10   fa16.3e73.b9df  ARPA   GigabitEthernet0/1

    Now we have the L2 address and the Ethernet frame will be on its way…

    Hope this helps!


  3. Hi Rene,

    In the above example, when we ping Branch loopback from HQ without specifying any source in ping command, then in the wireshark I can see the source IP of the ICMP ping packet is the IP address of tunnel interface i.e. and same thing in the EIGRP Hello packet.

    So can we say that any packet going out of f0/0 of R1 will have source IP (i.e. IP address of tunnel for which f0/0 is configured as source)? as we have configured f0/0 as tunnel source.

    And also I think we cannot configure one interface as a source for more than one tunnel…right?


  4. Hi Trevor,

    The goal of this example is to demonstrate how GRE tunneling works, you could use any other routing protocol. Here’s a quick example though how you can use BGP instead.

    First we create an access-list that matches the loopback interface and we create a route-map:

    R1(config)#ip access-list standard L0
    R1(config)#route-map L0_ONLY permit 10
    R1(config-route-map)#match ip address L0
    R1(config)#route-map L0_ONLY permit 20

    Now you can configure BGP, configure the remote neighbor and redistribute only the loopback interface:

    R1(config)#router bgp 13
    R1(config-router)#neighbor remote-as 13
    R1(config-router)#redistribute connected route-map L0_ONLY

    Hope this helps!


  5. Hi Vitaly,

    The loopbacks won’t affect your neighbor adjacency whatsoever. The neighbor adjacency is established on the tunnel interface so any other interfaces don’t have any effect on it. It won’t matter if you use a /24 or /32 on the loopback interfaces :slight_smile:

    Do you still have your config with the /24s on the loopback that is not working?


49 more replies! Ask a question or join the discussion by visiting our Community Forum