The “P-to-P router encryption” post has generated numerous comments. One of the readers suggested using dedicated Ethernet encryption devices, which is probably the best option if you’ve realized you need encryption in the network acquisition phase when there’s still some budget left (too bad the vendor recommended in the comments does not want to admit how expensive the boxes are).

However, assuming you have high-speed IPSec encryption modules and you have to implement P-to-P encryption in existing network, the only option left to you is GRE tunnel. Here’s why:

IP and MPLS are distinct protocols at the boundary between layer-2 and layer-3 (let’s forget the question whether MPLS is a layer-3 or layer-2.5 protocol at the moment). If you want to transport both of them across a shared connection, you have to include the layer-2 protocol ID (L2-PID) in the payload to ensure the receiving router is able to distinguish between incoming IP packets (which need FIB lookup) and MPLS packets (which need LFIB lookup).

As described in the previous post, IPSec encryption works only on IP packets. If you want to transport multiprotocol data (IP and non-IP traffic) across an IPSec-encrypted session, you need to encapsulate them into IP datagrams using an encapsulation method that includes L2-PID. The only such method supported in Cisco IOS is GRE.

One of the readers suggested using Virtual Tunnel Interface (VTI). The VTI is just another conceptual implementation of IPSec (using point-to-point links instead of crypto maps). It does not introduce non-IPSec encapsulation headers and thus cannot transport L2-PID and multiprotocol data. Although you can configure mpls ip on the VTI interface, it doesn’t work.

GET VPN is completely unusable for our task; it’s a scalable way of key distribution and crypto map creation. It offers no encapsulation mechanism and works only for IP traffic.

Last but not least, someone started walking down the Rube Goldberg path and proposed adding extra boxes between the P-routers and using MPSL-over-GE-over-L2TPv3-over-IPSec-over-GE-(over-VPLS). The extra devices (your Cisco AM would love this option) and different encapsulation method (L2TPv3 instead of GRE) add unnecessary complexity … unless, of course, you cannot implement hardware encryption on your P-router, in which case it’s comparable to the “dedicated Ethernet encryption devices” proposal.