On 10/2/15 11:18 AM, Eric W. Biederman wrote:
What is the thinking here because it sure looks like you are busily
adding layer two functionality you swore you did not want.

Interfaces are enslaved to a VRF device, but neighbor entries are installed with a reference to the actual interface not the VRF device.

This patch (plus the iproute2 one) fills a gap for usability and debugging. I have one more patch to go and then I will send an update to the documentation, but here is a preview (documentation update has more detail via examples):

Using iproute2 for VRFs
1. Create a VRF
   ip link add dev NAME type vrf table ID

2. List VRFs
   ip [-d] link show type vrf
   --> -d is needed to show table id

3. Assign a Network Interface to a VRF
   ip link set dev NAME master VRF-NAME

4. Show Devices Assigned to a VRF
   ip [-br] link show master VRF-NAME

5. Show Neighbor Entries for a VRF
   ip [-6] neigh show master VRF-NAME

   (This patch is what makes this command work efficiently.)

6. Show Addresses Assigned to Interfaces in a VRF
   ip [-br][-6] addr show master VRF-NAME

7. Show Routes for a VRF
   ip [-6] route show table ID

8. Route Lookup for a VRF
   ip [-6] route get oif VRF-NAME ADDRESS

   (This one needs a kernel patch to display the correct entry.)

David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to