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