Re: l3mdev (VRFv3) issues...
Grant Taylor <[email protected]> Sun, 18 Nov 2018 00:02:51 +0000
| Newsgroups | org.kernel.vger.lartc |
|---|---|
| Message-ID | <[email protected]> |
I'm replying to myself in case someone needs the answer and searches the archive. I am /not/ pulling a DenverCoder9 (xkcd #979). On 11/16/2018 02:07 PM, Grant Taylor wrote: > Does anybody have any experience with l3mdev, the 3rd major take at > Virtual Routing and Forwarding in Linux? I guess now that I've figured things out, I am a subset / member of anybody. > I'm running into problems while testing some early / small / simple unit > tests before getting deeper into a project. I got my unit tests to pass. I also got my larger Proof of Concept to work. :-) > I don't know enough about l3mdev's (VRF's) operation to know if this is > how it's supposed to be have (as if it's supposed to do some other > $magic that I don't know about) or if this is a symptom of a bug. It turned out to be a misconfiguration on my part. The IP address(es) belong on the enslaved interface, not the l3mdev master interface. > Or, perhaps it's a problem with veth interfaces. I've not had an > opportunity to test with more proper (less virtual) interfaces. The veth interfaces work perfectly fine. At least once things are configured properly. > Can anyone comment? Here's the unit test that I was doing: # ip link set $NAME up # ip addr add $IP/$NM dev $NAME # ip link add $NAME-vrf type vrf table $NAME # ip link set $NAME-vrf up Note: $NAME should be defined in /etc/iproute2/rt_tables or use a number when adding the $NAME-vrf l3mdev interface. This successfully creates a new l3mdev (VRF) named $NAME-vrf, and enslaves the $NAME interface to it. The act of doing so removes the information for the IP address(es) bound to $NAME from the local & main routing tables to the $NAME routing table. -- Grant. . . . unix || die