10-01-2012 02:59 PM
Hi,
I have few doubts regarding GRE basics:
LAN1------------R1----------R2-----------R3-----------LAN3
|
|
LAN2
R1
-----
interface loopback0
ip address 1.1.1.1 255.255.255.255
!
interface fastethernet0/0
ip address 192.168.1.1 255.255.255.0
!
interface Serial 0/0
description connection to R2
ip address 172.16.0.1 255.255.255.252
!
interface tunnel0
ip address 10.10.10.1 255.255.255.0
tunnel source loopback0
tunnel destination 2.2.2.2
!
R2
------
interface loopback0
ip address 2.2.2.2 255.255.255.255
!
interface fastethernet0/0
ip address 192.168.2.1 255.255.255.0
!
interface Serial0/0
description connection to R1
ip address 172.16.0.2 255.255.255.252
!
interface tunnel0
ip address 10.10.10.2 255.255.255.0
tunnel source loopback0
tunnel destination 1.1.1.1
!
Questions:
1. When a pkt travels from LAN1 to LAN2 over the tunnel between R1 & R2, The enacpsulation will be of the format : [ IP | GRE | IP | Payload ] right?
2. In the outer IP header Source IP = Tunnel source IP on R1=1.1.1.1
Destination IP = Tunnel destination IP on R1 = 2.2.2.2
Protocol number = 47
Correct?
3. R2 sees that pkt as destined to its own loopback IP & hence strips the IP header and gives the [ GRE | IP | Payload ] part to the upper layer. Then if R2 has many tunnel interfaces how will it decide to which tunnel interface this pkt belongs? Anything lies in the GRE field that tells it the pkt belongs to Tunnel0? I searched the RFC 1701 & 1702 for GRE field contents but couldnt confirm how its implemented on Cisco?
Thanks a lot in advance!
Solved! Go to Solution.
10-01-2012 11:12 PM
Hello,
See inline OP>
Questions:
1. When a pkt travels from LAN1 to LAN2 over the tunnel between R1 & R2, The enacpsulation will be of the format : [ IP | GRE | IP | Payload ] right?
OP> Correct
2. In the outer IP header Source IP = Tunnel source IP on R1=1.1.1.1
Destination IP = Tunnel destination IP on R1 = 2.2.2.2
Protocol number = 47
Correct?
OP> Correct
3. R2 sees that pkt as destined to its own loopback IP & hence strips the IP header and gives the [ GRE | IP | Payload ] part to the upper layer. Then if R2 has many tunnel interfaces how will it decide to which tunnel interface this pkt belongs? Anything lies in the GRE field that tells it the pkt belongs to Tunnel0? I searched the RFC 1701 & 1702 for GRE field contents but couldnt confirm how its implemented on Cisco?
OP> yes indeed your explanation is correct. Let's imagine we have 2 tunnels between R1 and R2 [ same source and same destination ]. Then we would have an ambiguity since we dont know on what tunnel we should land. In this scenario, we remove the ambiguity by configuring a tunnel key on each tunnel.
int tunnel0
...
tunnel key 100
int tunnel 1
...
tunnel key 200
[ Configured the same way on both side].
This will add 4 bytes overhead in the gre header.
Then the code will do the following lookup. Check tunnel src and tunnel dst + tunnel key in order to anchor the decapsulation to the tunnel matching the same tunnel key.
Thanks a lot in advance!
10-02-2012 04:18 AM
Hello Pradeep,
If I am not wrong we can not have that scenario and if we configure that, the tunnel interface will never come up.
I have simulated this in the lab and observed
regards
Harish.
10-01-2012 11:12 PM
Hello,
See inline OP>
Questions:
1. When a pkt travels from LAN1 to LAN2 over the tunnel between R1 & R2, The enacpsulation will be of the format : [ IP | GRE | IP | Payload ] right?
OP> Correct
2. In the outer IP header Source IP = Tunnel source IP on R1=1.1.1.1
Destination IP = Tunnel destination IP on R1 = 2.2.2.2
Protocol number = 47
Correct?
OP> Correct
3. R2 sees that pkt as destined to its own loopback IP & hence strips the IP header and gives the [ GRE | IP | Payload ] part to the upper layer. Then if R2 has many tunnel interfaces how will it decide to which tunnel interface this pkt belongs? Anything lies in the GRE field that tells it the pkt belongs to Tunnel0? I searched the RFC 1701 & 1702 for GRE field contents but couldnt confirm how its implemented on Cisco?
OP> yes indeed your explanation is correct. Let's imagine we have 2 tunnels between R1 and R2 [ same source and same destination ]. Then we would have an ambiguity since we dont know on what tunnel we should land. In this scenario, we remove the ambiguity by configuring a tunnel key on each tunnel.
int tunnel0
...
tunnel key 100
int tunnel 1
...
tunnel key 200
[ Configured the same way on both side].
This will add 4 bytes overhead in the gre header.
Then the code will do the following lookup. Check tunnel src and tunnel dst + tunnel key in order to anchor the decapsulation to the tunnel matching the same tunnel key.
Thanks a lot in advance!
10-01-2012 11:37 PM
Hello Pradeep,
Hope this packet flow helps
S0 10.1.1.0/30 s0
192.168.1.0----RouterA-------------RouterB----------192.168.2.0
T0-------------T0
1.Packet originates from 192.168.1.10.( LAN)
2.Packet received by the router at Site A on eth 0/1 (192.168.1.1) ( LAN Interface)
3.routerA checks route table for routing information (destination 192.168.2.0) and determines the destination network is available through the tunnel interface, T0
4.Packet is encased in GRE header with source IP (10.1.1.1) and destination IP (10.1.1.2) and routed back through the route stack.
5.Router A checks route table for routing information for destination IP 10.1.1.2 and routes the packet out the WAN interface, S0
6.Router B receives the packet on the WAN interface (10.1.1.2). The system recognizes that there is a GRE header on the packet and sends it to the tunnel interface associated with the source and destination IP addresses (10.1.1.1 and 10.1.1.2).
7.GRE header is stripped and the packet is routed through the route stack with a destination IP in 192.168.2.0.
8.Packet is routed out LAN interface of Router B for delivery.
Harish.
10-02-2012 02:31 AM
Hi Olpeleri & Harish,
Thanks for your replies. Again need some more clarifications:
1. If tunnel key is not configured, will the packets between the 2 routers with 2 tunnels of same source, destination, & encapsulation be dropped? I was guessing the source router would automatically insert something in the source routing field of the GRE header to make it reach the right tunnel interface!
2. Should the configuration always be like tunnel source on R1 is tunnel destination on R2 & vice versa? or will this configuration work?
R1
-----
tunnel source = loopback0 on R1
tunnel destination = loopback0 on R2
R2
----
tunnel source = loopback1 on R2
tunnel destination = loopback1 on R1
3. I have seen on some of the routers in our network there are tunnel interfaces with single tunnel source & multiple tunnel destination statements may I know what is the purpose of such a configuration?
Thanks a lot in advance!
10-02-2012 02:53 AM
Hello pradeep.
1. Even without tunnel keys, the packet will never get dropped and when packet arrives router checks the source and destination of the tunnel to identify the actual tunnel to suppose to get routed
2. Yes it has to be some else the tunnel may not come up ( you need to configure keepalive for the tunnel)
3.To my knowledge normal GRE does only support 1 destination. There is another version of GRE called multipoint GRE uses another protocol called NHRP
Regards
harish
10-02-2012 04:01 AM
Hi Harish,
As I previously asked If there are 2 tunnels between 2 routers with same tunnel source, tunnel destination & tunnel encapsulation, with no tunnel keys configured then where will the packets go if they are not dropped?
Regards
Pradeep
10-02-2012 04:18 AM
Hello Pradeep,
If I am not wrong we can not have that scenario and if we configure that, the tunnel interface will never come up.
I have simulated this in the lab and observed
regards
Harish.
10-02-2012 05:01 AM
Since source and Destination are the same. the router NEED the tunnel key in order to find out on what tunnel you have to decapsulate. That's the only way.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide