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 581 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

295 New Members signed up the last 30 days!

satisfaction-guaranteed

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. (contd.)
    probably related:
    We know that both sides of the tunnel should be in the same subnet. But why? Remote side of the tunnel receive a packet that doesn't seem to include ip address of the HQ side of the tunnel (192.168.13.1), so why does remote end cares? Thank you!

  3. 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 172.16.3.3 it has to check its routing table for a match:

    HQ#show ip route eigrp 
    
          172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
    D        172.16.3.0/24 [90/27008000] via 192.168.13.3, 00:00:07, Tunnel1

    2) 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 192.168.13.3
    Routing entry for 192.168.13.0/24
      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

    3) 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 192.168.12.1, destination 192.168.23.3

    4) Now the router will have to figure out how to get to 192.168.23.3, the tunnel destination so it does another lookup:

    HQ#show ip route 192.168.23.3
    Routing entry for 192.168.23.3/32
      Known via "static", distance 1, metric 0
      Routing Descriptor Blocks:
      * 192.168.12.2
          Route metric is 0, traffic share count is 1

    5) It sees there is a static route for 192.168.23.3/3 with 192.168.12.2 as the next hop. Time to figure out how to get there:

    HQ#show ip route 192.168.12.2
    Routing entry for 192.168.12.0/24
      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 192.168.12.0/24. Time to figure out the L2 address:

    HQ#show ip arp 192.168.12.2
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet  192.168.12.2           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!

    Rene

  4. Hi Rene,

    In the above example, when we ping Branch loopback 172.16.3.3 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. 192.168.13.1 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 192.168.13.1 (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?

    Regards,
    Nanu

  5. 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-std-nacl)#permit 172.16.1.0 0.0.0.255
    
    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 192.168.13.3 remote-as 13
    R1(config-router)#redistribute connected route-map L0_ONLY

    Hope this helps!

    Rene

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