MPLS over GRE

[adam-kulagowski]

• Did you check if this is a duplicate issue?
• Did you test it on the latest FRRouting/frr master branch?

Description

Is scenario when MPLS over GRE is used to set up l3VPN supported?
I'm trying to peer w/ Juniper VMX as described in
https://www.juniper.net/documentation/en_US/junos/topics/example/example-next-hop-based-dynamic-gre-tunnel-configuring.html

Expected behavior:
In lack of lldp peer, MPLS over GRE encapsulation should be used

Actual behavior:
MPLS is sent via physical interface

Components

[bgpd, ospfd, staticd, zebra]

Versions

• OS: alpine:edge (in docker)
• Kernel: 4.15.0-39-generic
• FRR: 6.1-dev_git1042702486119

[rwestphal]

Hi @adam-kulagowski,

I've managed to make L3VPN work over GRE using this test topology: https://gist.github.com/rwestphal/931f070240ffffebc2213f5d5fbefcb7

Here you can see the MPLS VPN label and the CE payload being carried in the GRE tunnel:

The solution I found was to enable LDP on the GRE interfaces (and MPLS forwarding as well) and create a static route in each PE pointing to the other one through the GRE tunnel. This way LDP will advertise implicit-null labels to the PE loopback routes, and zebra will have labeled routes to the BGP nexthop of the VPNv4 routes, making them eligible to be installed in the kernel.

One thing to keep in mind is that you need to specify a fixed TTL (e.g. 64) when creating the GRE interfaces, otherwise the GRE packets will inherit the TTL of the encapsulated packets. Since LDP sends multicast packets with a TTL of 1, the default TTL inheritance behavior prevents LDP from working over GRE tunnels.

The only problem I see in this solution is that all traffic between the PEs goes through the GRE tunnels, and not only the VPN traffic as one might desire. But this should be fixable using a few PBR commands.

Other possibility would be to change the FRR code as follows:

• Make zebra parse the attributes of GRE interfaces from the kernel to detect the tunnel endpoints;
• Change the nexthop resolution code to consider GRE/L2TPv3 tunnels as valid alternatives for VPN routes and pseudowires, without the need to create routes pointing to them.

This however might be a bit tricky to implement and I'm not sure if it would be the right thing to do. We need to do some research on this area.

[adam-kulagowski]

Many thanks :)

I think I failed to explain our situation. I'm aware that this can be done using LDP over GRE but I'm aiming to avoid LDP/RSVP at all:

Lets take a look at Cisco/Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/example/example-next-hop-based-dynamic-gre-tunnel-configuring.html

When a Juniper Networks routing platform receives a VPN route that resolves over a BGP next hop that does not have an MPLS path, a generic routing encapsulation (GRE) tunnel can be created dynamically, allowing the VPN traffic to be forwarded to that route.

On Juniper You need to add:

[edit routing-options]
user@PE1# set dynamic-tunnels gre next-hop-based-tunnel
user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 source-address 127.0.0.2
user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 gre
user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 destination-networks 55.66.77.0/24

On Cisco:
https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/layer-3-vpns-l3vpn/116725-configure-mgre-00.html

On Cisco relevant config:

l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0

route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE

router bgp 65534
 !
address-family vpnv4
neighbor 192.168.2.2 route-map MGRE-NEXT-HOP in

So basically there is standard (cannot pinpoint the RFC) to automatically encapsulate MPLS over GRE/UDP in case where is no LDP/RSVP running. So am I correct that this requires some changes in FRR source code?

If I missed something in Your example/explanation please let me know :)

Best regards,
Adam

[rwestphal]

@adam-kulagowski thanks for the detailed explanation.

So am I correct that this requires some changes in FRR source code?

Yes, FRR doesn't support resolving VPN routes through GRE tunnels as of now (without the implicit-null label hack), let alone create GRE tunnels automatically when necessary.

Since I can't commit to implement this right now, I've added MPLS over GRE to the Features Request wiki page.