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