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?
I just stumbled across this old one showing up as related, and wanted to answer, for having been in that situation more than once.
No need for trust configuration on cisco routers like ISR G1 (18xx/28xx/38xx), G2 (19xx/29xx/39xx) or ISR 4000 series - and probably older ones, too.
As long as there is no inbound QoS policies that would classifiy and (re)mark the packets, they will leave the ToS byte alone.
Usually, the to-be-encapsulated packet's ToS Byte (including DSCP) is copied out to the encapsulating headers.
Also see https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/IPSecQoS.pdf
Chapter "ToS Byte preservation" (Page 6-12):
To overcome this predicament, the IPSec protocol standards inherently have provisioned the capability
to preserve the ToS byte information of the original IP header by copying it to the IP headers added by
the tunneling and encryption process.
QoS Preclassification is also explained right there. In a nutshell: with QoS preclassify, every to-be-encrypted data packet gets a companion data structure in router memory that holds information from the original packet. Egress QoS policies then queue/schedule the encrypted packet properly, based on the data from the companion data instead of the encapsulated/encrypted (and therefore inaccessible) original packet.
If I understand your case correctly, default-active ToS byte preservation and an egress policy on the tunnel interface should work pretty nicely, making sure that the packets leave the router in the order you intend them to.
However, it may be that the metro ethernet or the WAN service provider might not trust the dscp markings in the outermost IP headers and might nullify them. That may be of minor concern for two reasons:
- the packets left the router after queuing/scheduling, in the order you
wanted them to. If your egress policy includes proper shaping to just-under-the-SP's thresholds, the SP's devices won't need to queue/reschedule.
- the remote tunnel endpoint will start do decapsulate the incoming packet. First step will be to discard the outermost IP header with the possibly nullified ToS byte. No harm done, the next IP Header will still have the original ToS byte with the DSCP field.
Best Answer
Running multicast or multicast based routing protocols does not necessarily require GRE-over-IPsec. "Tunnel based" or "route based" VPN (
tunnel mode ipsec ipv4a.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 employer's, we used to run MPLS-over-GRE-over-IPSec extensively, mostly with EIGRP on GRE as the GRT routing protocol, and with certificate based IKEv1 and IKEv2 beneath it.
This enabled us to have a multi-VRF CPE as small/cheap as a Cisco 890 series at the customer site, while allowing for path isolation or "zoning": one VRF or "zone" for the ATM, one for video surveillance, one for internal data, one for guest WiFi, one for facility management, etc.
At the same time, these IPSec tunnels were used over almost any flavour of underlying transport (dark fibre, lit fibre, point-to-point L2VPN, multipoint L2VPN, L3-VPN, cable or xDSL internet, etc.
Of course, we would have preferred to run MPLS atop IPSec directly (
tunnel mode ipsec ipv4, see above), but IPsec has no support for MPLS-over-IPSec (I believe there is - or was - an RFC draft for that, but it never made it).Addon 2018-12-13:
Yes, MTU across the WAN is cut short to 1400 or less (minus 8 if the local loop at the customer's end is based on PPPoE!) with MPLS-o-GRE-o-IPSEC. PMTUd is further made difficult because the tunnel interface is not actually an IP interface anymore, but an MPLS interface. Therefore
ip tcp adjust-mssis without effect on the tunnel interface, and TCP MSS clamping has to be done on the CE facing interface.Fragmentation of IKEv1 messages was also a difficult topic when RSA keys grew larger, eventually properly solved with IKEv2 and it's support for explicitely defining payload size (
crypto ikev2 fragmentation mtu <size>)