2

In a GRE tunnel, when R1 (public IP 172.16.0.1, tunnel address 10.0.0.1) sends a packet to R3 (public IP 172.16.0.6, tunnel address 10.0.0.2) and R3 receives it, the following happens:

  1. A packet is received on R3's physical interface.

  2. A routing decision determines that the destination address belongs to R3.

  3. The router recognizes the destination IP address (172.16.0.6)and GRE header as belonging to the tunnel interface. The tunnel interface removes the outer IP and GRE headers, and the original IP packet is sent back "in" to the router.

  4. A second routing decision is performed based on the original destination IP address.

  5. The IP TTL is decremented by one and the packet is transmitted out the appropriate interface.

See here for the example I'm gonna discuss now and for more details.

I'm wondering about point 3. If the packet's destination in the outer IP header set by the tunnel on R1 is 172.16.0.6, why doesn't R3 immediately get rid of the extra IP and GRE headers?

Instead, R3 checks its configured tunnels to find one with source tunnel address 172.16.0.6 and passes the packet there.

It means that the destination tunnel address on R1 needs to match the source address on R3, and vice versa (proof by example). If they don't, R1 won't be able ping 10.0.0.2. What is a logical explanation for this requirement?

Maybe I'd like the packets to take different physical paths over the tunnel, depending on the direction they are travelling (R1 to R3 or R3 to R1)?

Improve this question

2 Answers 2

Reset to default
3

One simple explanation is that R3 needs to determine which tunnel the packet came from. It's often that there may be more than one tunnel terminating on the same interface on R3.

EDIT: More importantly, if you allow the tunnel configuration on R3 to specify a different endpoint, there's no guarantee that that address is actually on R1-- it could be anywhere. That would mean the interface for the other end of the tunnel, 10.0.0.1, could exist in two different places. That will cause, as we say, a bad routing day.

Another explanation is that it allows keepalives so R1 and R3 know that the other end other end of the tunnel is up.

You can certainly have asymmetric paths if you want. That depends on the route information on R3.

Improve this answer
13
  • But why would R3 even care about where the packet came from? R3 just receives the packet and removes the extra IP and GRE headers, and forwards the original packet. I could easily imagine the implementation of GRE allowing R1 and R3 to ping each other over the tunnel, even if the tunnel dst address on R1 doesn't match the tunnel source on R3.
    – user4205580
    Dec 12, 2015 at 22:52
  • 2
    A tunnel interface is treated like a physical interface, so the assumption is that packets can be forwarded out the interface too.
    – Ron Trunk
    Dec 12, 2015 at 23:18
  • I know. They are pretty much virtual interfaces. The physical source and destination interfaces are specified in the configuration of the tunnel (source and destination address). I just don't get why Cisco forced everyone to specify source physical interface address on R1 that matches dst physical interface on R3 and vice versa. What could possibly go wrong with tunneling if it was allowed?
    – user4205580
    Dec 12, 2015 at 23:56
  • Ok, I can see one problem if src/dst tunnel IPs didn't match dst/src tunnel IPs on the other end. I could basically send a ping from R1 to R3, but then R3 would send the reply to a completely different router.
    – user4205580
    Dec 13, 2015 at 9:33
  • Seriously, I can't understand your point here: A tunnel interface is treated like a physical interface, so the assumption is that packets can be forwarded out the interface too. A tunnel configured on the router consists of the tunnel IP address, tunnel source and tunnel destination. As long as a physical interface with the IP of the tunnel source IP exists on the router, I don't see any problem. When a packet is forwarded out the tunnel interface, it leaves the router through the physical interface specified in the 'tunnel source'.
    – user4205580
    Dec 13, 2015 at 15:06
0

The 'tunnel destination' on Src needs to match the 'tunnel source' on peer to ensure the packet gets delivered to the right int. Once it arrives at the right int, that int looks at 'IP protocol field' and IDs it is a GRE packet -- that triggers it to send the packet to GRE process to get decapsulated, etc

Based on above, think what would happen if R1 (sender) believes Tu Dst is R2 g0/1, BUT.. R2 is configured to source packets from Loop 1. The packet arrives on R2 g0/1. That is final destination so R2 g0/1 looks at IP proto and sees it is GRE packet. It says, I'm not sourcing any tunnels from this int so drops packet.

R2 can't assume the packet addressed for g0/1 should be associated with the tunnel sourced from Lo 1. That tunnel could be to some other device (reached out g0/1 or a different int).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.