TCP multipath - Any alternative to PBR ?


Userlevel 1
Hi,

I'm considering deploying Multi Path TCP for some of our public facing services.

If you're not familiar with the concept, the basic idea is that the initial connection is done on IP 'A', then several other connections are then negotiated and opened on IP 'B'/'C'/... and those should use alternative path.

The way I was thinking of doing it was to have the initial IP 'A' be a PI IP range that I advertise via two uplink providers. Then the alternative paths 'B' and 'C' would be PA IPs of each of my provider and obviously need to be routed to the correct one.

The server machine would be in 3 VLANs, the main dual advertised one, then one for each of the providers PA IPs.

Question is how I can tell the switch to route back the packets coming from the PAs to their respective providers. Policy Based routing isn't supported AFAICT. I could put each VLANs in a different VRF. But only the 'main' one would have the BGP sessions and inter-VRF route leaking isn't supported. Can I manually put a route in the other two VRF that use a gateway that's in the main VRF ? (it would be manual and not through BGP).

Any other way to accomplish this ?

Cheers,

Sylvain

5 replies

Userlevel 1
Just found http://www.netdevconf.org/1.1/proceedings/slides/ahern-vrf-tutorial.pdf that suggests it should be possible to manually insert a cross vrf route.

Hopefully that's supported on real HW switches. I'll need to check that tomorrow.

Userlevel 4
I think VRF route leaking via Quagga is presently targeted for CL v3.3 last I heard. Until then it is possible to do what you suggest manually. I have a pending ask to write a script next week to do just such a thing. I'll post here afterwards when I'm finished in case you can use it.
Userlevel 1
Good to know that this should work ! Manually setting the route in an interface 'post-up' would be enough for me actually so I'll probably do that. But I'm still curious to see what your script does precisely, if it's something I didn't think of but could use.

PS: Sorry for the late reply, I got swamped by other unrelated issues.

Userlevel 4
Sylvain Munaut wrote:

Good to know that this should work ! Manually setting the route in an interface 'post-up' would b...

Plans changed with that customer and they wanted to leak the routes elsewhere so that script was not written. I got as far as the psuedocode stage, the script would have been adding a little more intelligence by listening to netlink and only leaking the routes when they existed in the "source table" and similarly removing them if they no longer existed in the "source table."
Userlevel 1
Sylvain Munaut wrote:

Good to know that this should work ! Manually setting the route in an interface 'post-up' would b...

Ah yes, I see. This would indeed be much closer to "true" route leaking.

In my case, I can probably do without since it's only default routes and if they don't exist, that means that particular upstream provider is down and I have nowhere to route the packets anyway. multipath-tcp should handle one path getting broken and recover using the other.