Multipoint GRE and VRF

Hi all
I'm been doing some experimenting with multipoint GRE over 3G and I've run into a problem I need some help with. My setup is best described with the attached network drawing. MAR-Router has a fiber Internet connection while the ECK-Router1 only has 3G connections using external modems with dynamic provider IPs, hence the need for multipoint GRE rather than static GRE tunnels. I've also had to use VRF lite on the ECK-Router1 as there is a need to keep the routing tables separate.
The tunnel9 interface on ECK-Router1 noVRF comes online nicely and OSPF does what it does. The tunnel can even handle when the 3G provider assign the modem a new IP. The tunnel 16 on ECK-Router1 VRF guest however does not handle nicely. When I set up the configuration the first time the tunnel comes up and OSPF goes adjacent with MAR-Router but whenever there is a disturbance in the 3G connection or the modem gets a new IP the tunnel goes down and doesn't activate until I remove and reenter the " tunnel vrf guest" command. The show dmvpn static detail command on ECK-Router1 gives the result below with the VRF guest tunnel in the NHRP state.
It seems multipoint GRE has a problem with VRF lite but it could also be a case where I've missed something. I would appreciate any pointers.
Regards
/Fredrik
ECK-Router1#sh dmvpn static det
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface Tunnel9 is up/up, Addr. is 172.16.14.2, VRF ""
Tunnel Src./Dest. addr: 192.168.14.30/194.112.9.140, Tunnel VRF ""
Protocol/Transport: "GRE/IP", Protect ""
Interface State Control: Disabled
nhrp event-publisher : Disabled
IPv4 NHS:
172.16.14.1 RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
1 194.112.9.140 172.16.14.1 UP 00:02:46 S 172.16.14.1/32
Interface Tunnel16 is up/up, Addr. is 172.16.14.3, VRF "guest"
Tunnel Src./Dest. addr: 192.168.15.30/194.112.9.140, Tunnel VRF "guest"
Protocol/Transport: "GRE/IP", Protect ""
Interface State Control: Disabled
nhrp event-publisher : Disabled
IPv4 NHS:
172.16.14.1 E priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
1 194.112.9.140 172.16.14.1 NHRP 00:00:45 S 172.16.14.1/32 (guest)
ECK-Router1
interface Tunnel9
bandwidth 10000
ip address 172.16.14.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast 194.112.9.140
ip nhrp map 172.16.14.1 194.112.9.140
ip nhrp network-id 1
ip nhrp holdtime 60
ip nhrp nhs 172.16.14.1
ip ospf network non-broadcast
ip ospf dead-interval 4
ip ospf hello-interval 1
ip ospf priority 0
ip ospf 1 area 0
ip ospf cost 2
tunnel source GigabitEthernet0/0.807
tunnel mode gre multipoint
interface Tunnel16
bandwidth 10000
ip vrf forwarding guest
ip address 172.16.14.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp map multicast 194.112.9.140
ip nhrp map 172.16.14.1 194.112.9.140
ip nhrp network-id 1
ip nhrp holdtime 60
ip nhrp nhs 172.16.14.1
ip ospf network non-broadcast
ip ospf dead-interval 4
ip ospf hello-interval 1
ip ospf priority 0
ip ospf 10 area 0
ip ospf cost 2
tunnel source GigabitEthernet0/0.810
tunnel mode gre multipoint
tunnel vrf guest
interface GigabitEthernet0/0.807
encapsulation dot1Q 807
ip address 192.168.14.30 255.255.255.0
interface GigabitEthernet0/0.810
encapsulation dot1Q 810
ip vrf forwarding guest
ip address 192.168.15.30 255.255.255.0
MAR-Router
interface Tunnel9
bandwidth 10000
ip address 172.16.14.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 60
ip ospf network broadcast
ip ospf dead-interval 4
ip ospf hello-interval 1
ip ospf priority 255
ip ospf 1 area 0
ip ospf cost 2
tunnel source 194.112.9.140
tunnel mode gre multipoint

Bump :)

Similar Messages

AAA Authentication and VRF-Lite

Hi!
I've run into a strange problem, when using AAA Radius authentication and VRF-Lite.
The setting is as follows. A /31 linknet is setup between PE and CE (7206/g1 and C1812), where PE sub-if is a part of an MPLS VPN, and CE uses VRF-Lite to keep the local services seperated (where more than one VPN is used..).
Access to the CE, via telnet, console etc, will be authenticated by our RADIUS servers, based on the following setup:
--> Config Begins <---
aaa new-model
aa group server radius radius-auth
server x.x.4.23 auth-port 1645 acct-port 1646
server x.x.7.139 auth-port 1645 acct-port 1646
aaa authentication login default group radius-auth local
aaa authentication enable default group radius-auth enable
radius-server host x.x.4.23 auth-port 1645 acct-port 1646 key <key>
radius-server host x.x.7.139 auth-port 1645 acct-port 1646 key <key>
ip radius source-interface <outside-if> vrf 10
---> Config Ends <---
The VRF-Lite instance is configured like this:
---> Config Begins <---
ip vrf 10
rd 65001:10
---> Config Ends <---
Now - if I remove the VRF-Lite setup, and use global routing on the CE (which is okey for a single-vpn setup), the AAA/RADIUS authentication works just fine. When I enable "ip vrf forwarding 10" on the outside and inside interface, the AAA/RADIUS service is unable to reach the two defined servers.
I compared the routing table when using VRF-Lite and global routing, and they are identical. All routes are imported via BGP correctly, and the service as a whole works without problems, in other words, the AAA/RADIUS part is the only service not working.

Just wanted to help future people as some of the answers I found here were confusing.
This is all you need from the AAA perspective:
aaa new-model
aaa group server radius RADIUS-VRF-X
server-private 192.168.1.10 auth-port 1812 acct-port 1813 key 7 003632222D6E3839240475
ip vrf forwarding X
aaa authentication login default group RADIUS-VRF-X local
aaa authorization exec default group X local if-authenticated
Per VRF AAA reference:
http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2b/12_2b4/feature/guide/12b_perv.html#wp1024168

1801w ISR and mapping VLAN, WLAN and VRF

I have a problem with getting SSID and local vlans to work unless I create subinterfaces on radio interface. If the VLAN is then associated to a VRF and VRF DHCP pool I won?t get an IP over WLAN.
Has anyone experience with such a solution with the intergrated radio?
Using LWAPP Hybrid REAP AP?s on a trunk (fa8) interface works just fine...

Try the command ip dhcp use vrf connected in order to assign the ip address through DHCP.

GRE with VRF on MPLS/VPN

Hi.
Backbone network is running MPLS/VPN.
I have one VRF (VRF-A) for client VPN network.
One requirement is to configure another VRF (VRF-B) for this client for a separate public VRF connection.
Sub-interfacing not allowed on CE-to-PE due to access provider limitation.
So GRE is our option.
CE config:
Note: CE is running on global. VRF-A is configured at PE.
But will add VRF-B here for the requirement.
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.22 255.255.255.252
tunnel source GigabitEthernet0/1
tunnel destination 10.12.0.133
PE1 config:
interface Tunnel0
ip vrf forwarding VRF-B
ip address 10.12.25.21 255.255.255.252
tunnel source Loopback133
tunnel destination 10.12.26.54
tunnel vrf VRF-A
Tunnel works and can ping point-to-point IP address.
CE LAN IP for VRF-B is configured as static route at PE1
PE1:
ip route vrf VRF-B 192.168.96.0 255.255.255.0 Tunnel0 10.12.25.22
But from PE2 which is directly connected to PE1 (MPLS/LDP running), connectivity doesnt works.
From PE2:
- I can ping tunnel0 interface of PE1
- I cant ping tunnel0 interface of CE
Routing is all good and present in the routing table.
From CE:
- I can ping any VRF-B loopback interface of PE1
- But not VRF-B loopback interfaces PE2 (even if routing is all good)
PE1/PE2 are 7600 SRC3/SRD6.
Any problem with 7600 on this?
Need comments/suggestions.

Hi Allan,
what is running between PE1 and PE2 ( what I mean is any routing protocol).
If No, then PE2 has no ways of knowing GRE tunnel IP prefixes and hence I suppose those will not be in its CEF table...
If Yes, then check are those Prefixes available in LDP table...
Regards,
Smitesh

Cisco 1700 with MP-BGP and VRF support

I have a Cisco 1721 with MP-BGP Support, you can create VRFs with it and every other MPLSVPN feature, but the commands for MPLS switching are not supported like Router(config-if)mpls ip , I read in some forums that you can create MPLS VPN without enabling MPLS at all, just with MPBGP, but I couldn't do it myself, Can someone tell me how to make it work or what can I do with a Cisco 1721 that supports MP-BGP?
thanks in advance

Here is an example. Take care about overhead for packets like VoIP. The overhead is 88 bytes.
The packet semms something like that.
IpHeader-pub@ - NAT-Tudp4500 - ESP - IpHeader-priv@(vrf discriminator) - GRE - Original IP Header - Data - Esp Trailer.
In this case you neet tunnel-mode because you use
private @ in order to determine vrf (vrf discriminator).
This is a LAB config, all other security parameters you need on a router are not configured. If you add access-list on the external interface of REMOTE you have to understand every encapsulation step in order to well tune it.
Good reading.
The PPT draw shows physically and logically views.
PS, take care about fragmentation issues, the problematic is still not well managed by the routers, I could not made Tunnel-path-mtu discovery work with vrf's. The workaround is to fragment packets. It's not good for performance but actually there is no other solution concerning that.
Kind Regards
Miguel

Where is the Forum for Multipoint Server and Licensing Issues?

I have installed MSDN release of Multipoint 2012 Standard in a VM for testing, and tried to use one of the assigned license codes from my MSDN subscription, and they are rejected by Multipoint server "Error, unable to validate the following codes..."
Please point me in the right direction.
Thanks.

Hi,
I'd probably ask over in the MSDN Subscriptions forum:
https://social.msdn.microsoft.com/Forums/en-US/home?forum=msdnfeedback&filter=alltypes&sort=lastpostdesc
EDIT: See below for a quicker contact option. That's a nice perk..
Don't retire TechNet! -
(Don't give up yet - 13,085+ strong and growing)

GRE and Tax Group

Could somebody share your experiences on 'Tax Group' Functionality? We have acquired a new company and need to maintain Tax group since we have to convert FICA, SSmax and stuff. In a way w2 should show 2 GRE for an employee and together the max amount should be met. Any suggestions/leads are most welcome
Thanks

Did you ever receive a response to your posted questions?
Thanks.

Advice required on optimal MTU and MSS settings for GRE and IPSEC connections

Hi,
We have 2 remote sites (Site A and Site B) which connect to our datacentres (DC) over IPSEC VPN and connect to each other over GRE tunnels.
We had some issues recently which we believe were MTU/MSS related (browsing web servers at one location not appearing correctly etc)
We got some advice from our Cisco partner and tweaked some settings but I'm still not convinced we have the optimal configuration - and we still have some problems I suspect may be MTU related. For example, from our DC (connected to Site A by IPSEC), we CANNOT browse to the webpage of the phone system hosted at Site A. Yet, we CAN browse to the webpage of the Site A phone system from Site B (connected over GRE)
Site A and Site B have two WAN internet circuits each - and each provider presents their circuit to us as ethernet.
Here are the relevant interface settings showing the currently configured MTU and MSS (both routers are configured the same way)
Can someone advise on what the optimal settings should be for our MTU and MSS values on the various interfaces or how we might best determine the values?
interface Tunnel1
description *** GRE Tunnel 1 to SiteB***
ip address [removed]
ip mtu 1400
ip tcp adjust-mss 1360
keepalive 30 3
tunnel source [removed]
tunnel destination [removed]
interface Tunnel2
description *** GRE Tunnel2 to SiteB***
ip address [removed]
ip mtu 1400
ip tcp adjust-mss 1360
keepalive 30 3
tunnel source [removed]
tunnel destination [removed]
interface GigabitEthernet0/0
description "WAN Connection to Provider1"
ip address [removed]
ip access-group firewall in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect cbac out
ip virtual-reassembly in
crypto map cryptomap
interface GigabitEthernet0/1
description "Connection to LAN"
no ip address
ip flow ingress
ip flow egress
duplex auto
speed auto
interface GigabitEthernet0/1.1
description DATA VLAN
encapsulation dot1Q 20
ip address [removed]
ip access-group 100 in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1320
interface GigabitEthernet0/1.2
description VOICE VLAN
encapsulation dot1Q 25
ip address [removed]
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1320
interface GigabitEthernet0/2
description "Connection to Provider2"
ip address [removed]
ip access-group firewall in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect cbac out
ip virtual-reassembly in
duplex auto
speed auto
crypto map grecrypto
Thanks.

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

3560 switch and VRF

Hello world,
How do configure a VRF on a 3560 ?
Seems like an easy question isn't it ? ;)
I have enable cef (ip cef distributed)
Can't not do "ip vrf blabla" it's an unrecognized command.
However, everything is there like "router ospf 10 vrf <name> "
Anyone have an idea ?
Oh, yes and my code is:
* 1 28 WS-C3560G-24TS 12.2(25)SEA C3560-ADVIPSERVICESK
- dan

If possible please try the same command in the router configuration mode and check the status.

Catalyst 6500 VS-S720-10G and VRF Capacity

Hi,
I have at the 6500 with vs-s720-10G. the datasheet say 1024 VRFs each populated with up to 700 routes/VRF for MPLS. MPLS in hardware to enable use of layer 3 VPNs and EoMPLS tunneling. Up to 1024 VRFs with a total of up to 256,000 routes per system.
I'am configurating 70 VRF with 883 routes with VRF-lite.
will it support this routes number ??
regards

With your VRF-lite deployment you described, are you planning to run any dynamic routing protocols, or are all the routes static? If you are using dynamic routing for these VRF lite instances, I would probably be worried about the number of IGP instances needed. However, maybe someone else has run a high number of VRF lite / IGP instances like that and could share their experiences.
Another concern with a 70 VRF deployment using VRF-Lite is the operational overhead, especially if you are running end-to-end VRF-lite. The Path Isolation Design Guide recommends as a rule of thumb no more than 10-15 VRF's when doing end to end VRF lite.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/PathIsol.pdf
Good luck,
Matt

6500 sup 720 with MPLS, GRE and FWSM problem

We have 6500 sup 720 with MPLS configured and FWSM in transparent mode. We also terminate GRE tunnels on the same 6500.
After implementing the command “mls mpls tunnel-recir” GRE tunnels are hardware switched (which we want them to be), but we don’t have any more connection from locations thru GRE tunnels to servers behind FWSM.
Does anybody have idea how to solve this problem?

Hi,
not sure what you mean exactly.
the command “mls mpls tunnel-recir” is needed to avoid packets corruption in cases where the Supervisor engine is handling both the GRE header encapsulation and the MPLS label stack imposition. Since it cannot do it in one single shot (without causing random corruption) recirculation is needed. Nevertheless its presence does not influence whether the GRE traffic is handled in hardware or in software. Even without it, IF THE GRE TUNNELS ARE CORRECTLY CONFIGURED (meaning that each GRE tunnels has its unique source address etc.), the traffic is handled in hardware.
However since you say that after you enabled it you don't have connectivty anymore I suppose that some issue related to recirculation is happening (i.e. traffic ends up in the wrong internal vlan after recirculation).
Unfortunately the support forum is not meant to help in this case as in-depth troubleshooting is required. For that you need a TAC case.
regards,
Riccardo

VoIP and VRFs

Does anyone know of any concerns, issues, problems, or hidden gotchas that have been experienced with creating a VRF for a VoIP network? What I would actually like to do is place everything (except the media gateways) in a VRF and firewall it. Thus only call signaling, management traffic, and any required database connectivity would have to pass through the firewall. Any thoughts, anyone?

Firewalling voice is always a headache. Unfortunately a lot of signaling protocols are proprietary like SCCP, and MGCP (not really). Or just change a lot, or not completely standardized like SIP.
Between the time a Dev on a VTG group decides to add a new field to a protocol like SCCP, and the time it takes the corresponding Dev on a Firewall group to add the support for that field on its 'Inspection' engine sometimes takes months. And the fact that all communications are opened on random dynamic ports between the 16K and 32K makes matters worst.
I do think it's a good idea, specially with cybersecuirty threads on the rise, and toll fraud so prevalent this days. I think SBC and Media relay points are a good way to get everything more in control.
I just wanted to raise some awareness that if you want to go down that path, you do need a solid roll-out and testing plan as things will likely get bizarre a few times.

IKEv2 with NAT-T and VRF (FlexVPN)

Hi,
I'm struggling to get this to work and the IOS debug commands show nothing.
Spoke1
======
crypto ikev2 keyring LAN-to-LAN
peer HUB
identity address 93.174.221.254
pre-shared-key local TEST
pre-shared-key remote TSET
crypto ikev2 profile IPSEC_IKEv2
match identity remote address 93.174.221.254 255.255.255.255
identity local fqdn spoke1.domain.com
authentication remote pre-share
authentication local pre-share
keyring local LAN-to-LAN
crypto ipsec transform-set ESP-TUNNEL esp-aes esp-sha-hmac
mode tunnel
crypto ipsec profile IPSEC
set transform-set ESP-TUNNEL
set ikev2-profile IPSEC_IKEv2
interface Tunnel2
description VTI2 | CUSTOMER2
vrf forwarding CUSTOMER2
ip unnumbered Loopback2
tunnel source Dialer1
tunnel mode ipsec ipv4
tunnel destination 93.174.221.254
tunnel path-mtu-discovery
tunnel protection ipsec profile IPSEC
interface Loopback2
vrf forwarding CUSTOMER2
ip address 10.47.255.1 255.255.255.255
interface Dialer1
ip address negociated
HUB
====
crypto ikev2 keyring LAN-to-LAN
peer spoke1.domain.com
identity fqdn spoke1.domain.com
pre-shared-key local TSET
pre-shared-key remote TEST
crypto ikev2 profile IPSEC_IKEv2
match identity remote fqdn spoke1.domain.com
identity local address 93.174.221.254
authentication remote pre-share
authentication local pre-share
keyring local LAN-to-LAN
virtual-template 2
crypto ipsec transform-set ESP-TUNNEL esp-aes esp-sha-hmac
mode tunnel
crypto ipsec profile IPSEC
set transform-set ESP-TUNNEL
set ikev2-profile IPSEC_IKEv2
interface Virtual-Template2 type tunnel
description VTI2 | CUSTOMER2
vrf forwarding CUSTOMER2
ip unnumbered Loopback2
tunnel source Loopback254
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile IPSEC
interface Loopback2
vrf forwarding CUSTOMER2
ip address 10.47.255.252 255.255.255.255
interface Loopback254
ip address 93.174.221.254 255.255.255.255
The spoke can ping anything on the internet including the hub public facing address 93.174.221.254 but the tunnel does not come up. Each end is running RIPv2 under the "CUSTOMER2" context with "network 10.0.0.0" and no auto-summary. Static routes don't seem to kick it into life either. Any help would be much appreciated, thanks.

thanks for the response.
For some unexplainable reason when I switch on the following debugs:
Spoke1#debug crypto ikev2 client flexvpn
FlexVPN debugging is on
Spoke1#debug crypto ikev2 error
IKEv2 error debugging is on
Spoke1#debug crypto ikev2 packet
IKEv2 packet debugging is on
Nothing seems to show on the console
Spoke1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 580/645/700 ms
Spoke1#ping 93.174.221.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 93.174.221.254, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 580/645/700 ms
*The high latency is because Dialer1 is currently on GPRS because 3G coverage where i'm testing is poor.
I have this in the Spoke1 config:
     ip route vrf CUSTOMER2 10.47.0.0 255.255.0.0 Tunnel2
So I'd have thought pinging something like 10.47.255.252 would bring Tunnel2 up or show some debug messsages. Unfortunately all I get is this:
Spoke1#ping vrf CUSTOMER2 10.47.255.252
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.47.255.252, timeout is 2 seconds:
Success rate is 0 percent (0/5)
Spoke1#sh ip route vrf CUSTOMER2:
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.47.1.0/24 is directly connected, Vlan2
L        10.47.1.1/32 is directly connected, Vlan2
C        10.47.255.1/32 is directly connected, Loopback2
How do I enable crypto logging session ?
And i'll try an MTU of 1452 just encase path-discovery isn't working?
My understanding is that a virtual-access interface should appear for each spoke that connects, but that doesn't seem to be happening.

Question to understand VRF and VRF-lite features

Hi,
when I look at METRO switches Feature list I see that most of them support only "VRF-Lite".
Does it mean that they can't work with MPLS lables and can't be placed as PE devices in cases where we need VPN services or any kinf of "Lable-switching" services?
Which role then does those METRO switches play in a network?

Hello Konstantin,
VRF lite is a subset of MPLS L3 VPN features missing MPLS forwarding plane capabilities.
An end to end dedicated IP path is needed for each VRF, practically a VRF-lite capable device should be connected to a fully capable PE node by using a L2 trunk and dedicating at least two Vlan and two SVI for each VRF: one towards customer and one towards PE.
you get a multi VRF CE that can be shared by multiple customers
a fully capable PE node uses N+1 links for N VRFs, a multiVRF CE requires 2*N logical interfaces for N VRFs
only one MPLS enabled backbone link is needed for handling traffic of multiple VRFs in a fully capable PE node.
in metro ethernet VRF lite multi VRF CE are used as feeders sort of satellite of PE nodes to provide an access layer to customers
Hope to help
Giuseppe

Difference between GRE and IPIP tunnel

Hi!!!
I want to know when tunnel is configured, which mode is more affective in terms of encryption and less overhead.
Thanks in Advance
Kiran

Kiran,
When talking encryption, neither a GRE or IPIP tunnel will encrypt the traffic on their own. This process needs to be done using a second mechanism such as IPSec.
In terms of less overhead, the GRE header is 24 bytes and an IP header is 20 bytes.
When a GRE tunnel is built, the original packet is encapsulated within a GRE (IP Protocol 47) packet and send to the configured tunnel destination. Similarly, when using IPIP tunnels, the original packet to be sent is encapsulated within a new IP packet and transmitted to the tunnel destination. When looking at an IPIP packet with a protocol analyzer, the packet will appear to have two IP headers within it.
Another thing to consider with the two tunnel types is that a GRE tunnel has the ability to acknowledge the receipt of packets similar to TCP communications. The IPIP tunnel method has no such mechanism as it inherits the stateless behavior of a raw IP packet, similar to UDP based communications.
Steve

Multipoint GRE and VRF

Similar Messages

Maybe you are looking for