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
