Cisco has a nice IPSec Overhead calculator (CCO Login required, unfortunately).
From where we can draw, based on your IPSec settings and a few common optionals thrown in:
8 PPPoE (optional, but widespread)
20 outer IP header
8 NAT-T (optional, widespread, sometimes even default-on)
8 ESP Header (4 SPI ...
Encapsulation requires a protocol. Depending on the protocol, an encapsulating packet is uniquely identified by either EtherType (in layer 2), IP protocol number (in layer 3), transport-layer port number (in layer 4), enabling the gateway to handle the packet as required.
The gateway commonly uses additional information from the encapsulating or underlying ...
I found the solution to this eventually, with some help.
The issue was that on the ASR side, the tunnel was in its default configuration which uses GRE, which the ASA doesn't support.
The solution was to change the tunnel mode to ipsec ipv4 like so:
tunnel mode ipsec ipv4
With this done, bidirectional traffic was possible over the tunnel.
Two main reasons for using labels:
It makes the transport layer independent of the customer addressing scheme. Multiple customers can have overlapping addressing. The transport doesn't care
Protocol independence. What you've describe works fine for IP, but MPLS can handle non-IP protocols (L2, pseudowires) too.
Do you think you're referring to an IPSEC Child Security Association (SA)? It's described by the specifications as a child and even has some related notification types.
To expand, Child SAs are created for policy-based IPSEC VPNs as a result of how they are implemented by routers. If you have the following configuration for a tunnel, two Child SAs are ...
(from comment) The overhead is only visible (and countable) outside the tunnel. Roughly you should see (outer packet header + GRE header) * number of packets more traffic on the outside (physical) interface than on the tunnel interface.
Depending on where you're watching, a physical interface might also be counting L2 traffic (add the L2 header size * number ...
The QFX5100 doesn't support TRILL (yet):
NOTE: The hardware also supports FCoE and TRILL ether-types, but there
is no software support for these packets. The software support will be
available in a future release.
extended-vlan-bridge is something entirely different (...
I can't say that this applies to every tunnel imaginable, but this is a general idea how this could work.
A tunnel is set up between an entry point and an exit point. In this case the outer packet will have entry point as a source address and exit point as a destination address. The exit point will receive a packet with itself as a destination address. Thus ...
Site B is missing the route for 192.168.198.0/24 pointing into the tunnel. Without it, the packet leaks out to WAN.
You need to either set up a static route or configure OSPF between the firewalls (requires 'always-on' VPN).
do encapsulated packets get further encapsulated in Ethernet frames?
PPTP sits on top of a transport-layer connection, using TCP. As such, PPTP frames are encapsulated in TCP segments, those are encapsulated in IP packets, those in turn in frames for Ethernet, IEEE 802.11, ..., even PP(T)P.
ppp frames need to get encapsulated in a ethernet frame , thus ...
The SprintLink Peerless network is actually an IP-over-IP network, instead of a MPLS L3VPN network. Sprint engineers believed the IP routing technology to be mature and inexpensive, and viewed it as a better option than adopting new MPLS technology.
I mention this mainly to identify that there are different schools of thought on the available technology ...
You cannot increase the routing MTU because of the hardware limitation (the switch cannot fragment in hardware). The system mtu routing will only affect the router ports but at the same time would not affect the SVIs.
In brief, you cannot have routed ports and SVIs on the same box with different MTU sizes.
The only thing you can do on that hardware is:
In common you can think of NAT and tunneling as two different processes. Tunneling is something in kernel, but firewall/NAT is usually something tied to interface. NAT is dealing with real packets on interface, that is most common scenario. It can be BSD, Cisco or anything else - the packet processing will be almost the same:
Packet arrive into kernel and ...