09-12-2008 06:05 PM - edited 03-06-2019 01:21 AM
I'd like a little clarification regarding GRE encapsulation.
From the way I have always understood it, an IP packet is encapsulated into/by a GRE packet that has a 20 byte header. But nowhere in that header exists a source IP or destination IP address field (The tunnel source and destination addresses would be the ones of interest to GRE). So, how does GRE forward the packet to the tunnel destination?
Moreover, it seems that, logically speaking, GRE sits between IP (network layer) and the data link layer. Is that correct?
I have yet to find any web link, including Cisco's, that really explains the nuts and bolts -- the mechanics -- of GRE to the degree I am describing here. Does anyone have one?
Thanks, folks
Victor
Solved! Go to Solution.
09-13-2008 11:42 AM
Hi Victor!
It's good to hear from you, too.
For the last several months I've been having a lot of other tasks to do and I have little time to participate in the forum.
However, when I find some time, I always return to this site because it's an excellent place to find challenging problems.
I found a good stuff for you:
http://www.ciscopress.com/content/images/9781587201509/samplechapter/158720150X_CH14.pdf
Cheers:
Istvan
09-12-2008 06:52 PM
Victor
My understanding of GRE appears to be very different from yours. Yes GRE involves a 20 byte header - and that is an additional IP header (what is the length of an IP header?). In the GRE header the source address is the address specified in tunnel source and the destination address is the address specified in tunnel destination.
If you have not done so before, I suggest that you try a packet capture (wireshark or whatever you prefer) on a GRE packet.
HTH
Rick
09-12-2008 07:08 PM
"In the GRE header the source address is the address specified in tunnel source and the destination address is the address specified in tunnel destination."
Rick, that's just it; there are no address fields in the GRE header, yet the GRE packet encapsulates the IP datagram and forwards it.
RFC: http://www.ietf.org/rfc/rfc1701.txt
What I think MAY be the case is that the IP datagram gets encapsulated by GRE, BUT the IP header remains "outside." So, what you have is the IP header, then the GRE header, and then the IP datagram inside the data portion of the GRE packet. Then ALL of that gets encapsulated by a L2 frame.
[EDIT] Better stated, I think GRE creates a NEW IP header with the tunnel souce and destination addresses, and THAT header's info is used to route to the tunnel endpoint. [EDIT]
This is what I think MAY be the case, although I cant seem to find any really good documentation on the nitty gritty mechanics of it.
What do you think?
Victor
09-12-2008 10:37 PM
Hi Victor,
This is the point:
"GRE creates a NEW IP header with the tunnel souce and destination addresses, and THAT header's info is used to route to the tunnel endpoint."
GRE header minimum length is 24 bytes, not 20 bytes: after the NEW IP header it contains a 2 byte flags field and a 2 byte protocol field that tells the next header information.
The protocol field's value is dependent on what type of packet is encapsulated. If IPv4 packet is encapsulated, then the protocol field contains 0x0800.
After this protocol field follows the original IP header and the rest of the original IP packet.
This is the link on cisco.com about GRE:
http://www.cisco.com/en/US/tech/tk827/tk369/tk287/tsd_technology_support_sub-protocol_home.html
Cheers:
Istvan
09-13-2008 04:52 AM
Hey, Istvan! Long time, man....where have you been?
OK, I'm glad that someone has validated my suspicion. Thanks for your answer.
I did go to that link you gave me before and it has about 30 links on it. They are all about configuring GRE. Which is the one that discusses the theory and the detailed mechanics of how it works?
Thanks
Victor
09-13-2008 11:42 AM
Hi Victor!
It's good to hear from you, too.
For the last several months I've been having a lot of other tasks to do and I have little time to participate in the forum.
However, when I find some time, I always return to this site because it's an excellent place to find challenging problems.
I found a good stuff for you:
http://www.ciscopress.com/content/images/9781587201509/samplechapter/158720150X_CH14.pdf
Cheers:
Istvan
09-13-2008 01:12 PM
Istvan:
Well, I'm glad then that you decided to come back to the forum exactly when I asked this question! LOL
That's an excellent link, by the way.
Thank you!
Victor
09-14-2008 12:37 AM
You're always welcome!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: