Hi Sowmini:
On 7/8/15 12:34 PM, Sowmini Varadhan wrote:
Perhaps I misunderstand the design proposal here, but a switch's VRF
is essentially just a separate routing table, whose input and output interfaces
are exclusively bound to the VRF.
yes, and this model follows that.
Can an application in the model above get visibiltiy into the (enslaved?)
interfaces in the vrf?
yes. e.g., 'ip link show' prints the vrf device it is enslaved to:
6: swp3: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc noop master vrf10
state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:35:03 brd ff:ff:ff:ff:ff:ff
7: swp4: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc noop master vrf10
state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:35:04 brd ff:ff:ff:ff:ff:ff
8: swp5: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc noop master vrf10
state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:35:05 brd ff:ff:ff:ff:ff:ff
9: swp6: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc noop master vrf10
state DOWN mode DEFAULT group default qlen 1000
Can an application use IP_PKTINFO to send a packet out of
a specific interface on a selected VRF? What about receiving
IP_PKTINFO about input interface?
On the to-do list to use cmsg to specify a VRF for outbound packets
using non-connected sockets. I do not believe it is going to work, but
need to look into it.
What about setting ipsec policy for interfaces in the vrf?
similarly, need to look at ipsec use cases with this vrf model.
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
