Either method will work. I personally prefer GRE, but there should be no practical difference between the two for your use case. (GRE can transport other layer3 protocols than just IP, though.)
The only thing to really keep in mind is that GRE incurs a tiny bit of extra overhead as opposed to IPinIP.
@3iron's answer gave me the hint that I needed. The notation is denoting that there are multiple NIC interfaces on the router in the diagram and it's making reference to this.
F0/0 - interface #1
F0/1 - interface #2
NOTE: The F indicates that the NIC/port is most likely a Fast Ethernet type of connection.
This diagram from the Cisco website shows them as ...
It is also worth considering how tunneling impacts the path MTU. It would be ideal for the infrastructure between tunnel endpoints to support a larger MTU. This will avoid issues with fragmentation and broken pmtud.
L2tp and GRE are totally diffrent protocols
GRE is a simple IP packet encapsulation protocol. a GRE tunnel is used when packets need to be sent from one network to another, without being parsed or treated like IP packets by any intervening routers. a GRE tunnel interface comes up as soon as it is configured and it stays up as long as there is a valid ...
F0/0 and F0/1 look to be router interface notations to highlight a physical connection into the router from the two respective hosts.
Typically they could be:
Ten: Ten GigabitEthernet
Running a tunnel over GRE has the added benefit of being pretty much protocol-agnostic, so you can of course use it for IPv6 later on.
With that said however, there's equally nothing stopping you running 6in4 or ip6ip6 alongside ipip, so the question really comes down to whether there's any tangible gain for you by choosing GRE and using it for ...
You need a router.
The HP 2520G is a Layer 2 managed switch, and has no Layer 3 capabilities.
This is highlighted in the features tab on hp.com and in the 2520G feature support matrix
If you're not able to get funding for a router, maybe you could power up a Vyatta VM at the ProCurve site?
Your tunnel source and destination addresses are wrong. They should be 188.8.131.52 and 184.108.40.206 on RA and the opposite on RB.
There are many different ways to explain this, but essentially, the route to the tunnel endpoint cannot be through the tunnel. In your case, in order to send a packet (from RA) to 192.168.1.2, RA has to encapsulate it ...
Running multicast or multicast based routing protocols does not necessarily require GRE-over-IPsec. "Tunnel based" or "route based" VPN (tunnel mode ipsec ipv4 a.k.a. IPsec Virtual Tunnel Interfaces in cisco lingo) will transport multicast and EIGRP or OSPF happily.
However, GRE is needed when you need to run non-IP protocols across IPSec:
At my former ...
So what's the difference between GRE+IPsec and IPsec only?
In GRE+IPsec the original IP packet is encapsulated in a GRE tunnel packet. The GRE packet is then encapsulated in the IPSec packet.
The most common reason for doing this is to allow broadcast and multicast across the tunnel. Neither is supported by IPSec alone. GRE can also encapsulate non-IP ...
GRE is just a tunneling protocol - its main reason for existence is toplogy hiding/bypass.
Some examples include:
Tunneling MPLS across a network that may otherwise not support it - MPLS shims are not IP-based, therefore wrapping them in a GRE tunnel allows two routers to appear adjacent when there could be a number of intermediate IP-only devices.
Dynamic protocols only really make sense if your sites have more than one exit point, or you have many routes per site that can't be nicely aggregated into a single static route.
I would stick with OSPF, simply to be able to use other vendors. I know EIGRP has been 'released' but its going to be years until you see other vendors using it and you dont want ...
You could solve this by running VXLAN on the hypervisor using software like FRR. That would imply that you run a full mesh BGP setup between your hypervisors, or use route reflectors. Then, you can create as many VNI's between your hypervisors which can be used as VPC's between virtual machines.
We've done this in a test setup and it seems to work, so we're ...
I think Cisco was referring to the interesting traffic is automatically put into a GRE formed tunnel. Which is different than we normally think of when making a GRE tunnel. Usually it has to do with routing and you need a virtual interface to have an IP address so you have something from R1 to push routes to R2.
Correct, in WCCP you don't have to specify an ...
AFAIK GRE support is limited to VPN services or as an access-pseudowire. At least according to ALU there is no way to use GRE as a logical tunnel on the 'network' side. This would require a service blade. However, I haven't tested this but it seems to be the official story.
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.
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 ...
You have to at least create static host routes pointing to the endpoint IPs of your tunnel to make sure they remain established. Front door vrf is handy if your endpoint is using a dynamic IP address, forcing you to have a default route pointing out the internet circuit. Splitting it into different vrfs allows you create a second default route pointing ...
Possible? Generally, yes. However, you need to consider the tunnel outside as well. How effective QoS works depends on a large number of parameters only some of which you have control over.
QoS inside a tunnel makes only sense when the tunnel traffic can't be congested from the outside - you'll need to reserve bandwidth for the tunnel itself as well. The ...
No, it should not be GRE.
In both cases as shown (IPSec tunnel mode and transport mode), it's always IPsec encrypting GRE (and whatever it may contain).
Therefore, the outermost header has to be IPSec.
Since you are using all ASA-X firewalls, I suggest you go with EIGRP and drop the GRE part - configure IPSEC VPN on ASA.
I had about 80+ branch offices connecting to main site with IPSEC VPN (Although tunnels were on routers not on firewalls) EIGRP played really well. EIGRP is much lighter with computations and has better performance than OSPF. Plus EIGRP ...
It is possible to run OSPF over an IPsec VPN between two ASAs, without the use of GRE (which as mentioned before, is not supported on the ASA). You just need to use static neighbors since multicast won't go through, and define the OSPF interface as point-to-point.
Here is an example of running OSPF over IPSec
The tunnels IP addresses need to be on their own subnet. The tunnel source and destination identify the points on the network where routers should encapsulate or de-encapsulate the traffic that is sent thru the tunnels. Having a route to your tunnel destination is a requirement for a tunnel interface to show "UP/UP" so really the 192.168.1.0/30 subnet ...
You can certainly run OSPF on GRE interfaces and routers will exchange routes quite happily via the GRE tunnel. A GRE interface should be just like any other interface to OSPF, so normal rules would apply for area assignments just the same as they would apply to other interface types.
You can't have a destination to a GRE tunnel that hasn't been established yet.
Tunnel0 is up, line protocol is up (connected)
Hardware is Tunnel
Internet address is 192.168.1.1/30
! Can't have the same IP on the GRE tunnel on both ends
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
I think you're looking for the OSPF "Sham-Link" feature. This feature builds virtual OSPF links over an MPLS infrastructure to connect OSPF networks. The feature is available on Cisco and Juniper gear at least.
First, if the three sites connect to the data center over WAN circuits with any appreciable latency, layer-2 connections are not a very good idea. Layer-2 must send all the broadcasts across the layer-2 links, and this can degrade performance and eat up expensive WAN bandwidth.
Sending the VoIP over the layer-2 link will force it to compete with the ...
Although GRE is developed by Cisco, it doesn't mean that other vendors don't support it. It's became kinda standard in the industry and I have not seen any single vendor who doesn't support it, whether Juniper, Check Point, Fortinet, etc.... And it's also pretty simple to implement on any Linux distribution.
I'd rather getting in contact with the Sales/...
Often, you may want to use a loopback, since it will never go down, as the source because you may have a backup path to the other end. It is not always the right thing to do to use the exit interface since it could go down, but there is another interface which could also get you to the other router. Putting it on a loopback will allow the tunnel to continue ...