Your SlideShare is downloading. ×
0
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Endsystem_v3.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Endsystem_v3.ppt

369

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
369
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Endsystem Support for Network Virtualization Fred Kuhns
  • 2. Overview <ul><li>Network Diversification: </li></ul><ul><ul><li>Virtual network ( vNet ): distinct vNets coexist within a common physical network </li></ul></ul><ul><ul><li>Diversification layer : common substrate to share physical resources and provide isolation </li></ul></ul><ul><ul><li>vNet is composed of one or more virtual routers ( VR ) interconnected by virtual links . Virtual routers and links are direct corollaries to their physical counterparts … Network resources are virtualized. </li></ul></ul><ul><ul><li>An end-system implements vNet protocols and provides connectivity services within a virtualized network protocol environment ( virtual end-system ). The virtual end-system provides mechanisms for protocol implementation , resource control and isolation . </li></ul></ul><ul><li>Diversification layer provides two levels of abstraction (i.e. two core services): </li></ul><ul><ul><li>Substrate : encapsulate existing layer 1 and layer 2 technologies and provide a single, consistent framework for implementing virtualized links and routers. </li></ul></ul><ul><ul><li>substrate link : abstraction to provide similar behavior as a point-to-point connection between communicating end points. Provides isolation services to different virtual networks using a common substrate link. </li></ul></ul><ul><ul><li>substrate router : A physical device which forwards network traffic based on its vNet membership. Provides sharing and isolation services to disparate vNets and hosts virtual routers. </li></ul></ul><ul><ul><li>Virtual : framework providing a simple model and set of interfaces for implementing virtual networks. The model defines virtual routers, end-systems and links. The goal is for virtual inks to and routers to behave similar to their physical counterparts. </li></ul></ul><ul><ul><li>virtual link : simulates the behavior of a dedicted point-to-point link interconnecting virtual end points (virtual routers and/or virtual end systems). A virtual link is implemented by one or more substrate links. </li></ul></ul><ul><ul><li>virtual router : implements a particular vNet’s routing logic. The underlying substrate router provides the necessary isolation and resource management functions. </li></ul></ul>
  • 3. vNet Discussion <ul><li>Develop examples/scenarios </li></ul><ul><ul><li>intranet ( no routing ) use existing model </li></ul></ul><ul><ul><li>internet ( routing ) use diversified networking model </li></ul></ul><ul><ul><li>use Ethernet and virtualized IP as running example </li></ul></ul><ul><li>Model: Simple </li></ul><ul><ul><li>network devices interconnected through simplex, point-to-point links. </li></ul></ul><ul><ul><li>common link layer protocol used for delivering packetized data to neighbor (not end-to-end but hop to hop) </li></ul></ul><ul><li>Achieving this model </li></ul><ul><ul><li>context : shared heterogeneous physical network, links and packet switches (aka packet routers) </li></ul></ul><ul><ul><li>objectives : </li></ul></ul><ul><ul><ul><li>partition physical resources into virtual links and routers </li></ul></ul></ul><ul><ul><ul><li>isolation mechanisms for virtualized resources </li></ul></ul></ul><ul><ul><ul><li>bind virtualized resources to network instances </li></ul></ul></ul>
  • 4. Context: Network Diversification ( vNets ) substrate router virtual router substrate link virtual link virtual end-system
  • 5. Simulates Star Topology for Substrate Links … VLAN X1 <ul><li>Internetworking over a diversified network </li></ul><ul><li>Substrate function with Ethernet: </li></ul><ul><li>Substrate links : use VLANs to provide the equivalent of a virtualized “wire” connecting an endsystem to a specific substrate router. </li></ul><ul><li>Sharing and Isolation : </li></ul><ul><ul><li>All vNet traffic use assigned VLANs </li></ul></ul><ul><ul><li>Use priority queuing (802.1P/Q) </li></ul></ul><ul><ul><li>All intranet traffic uses lower priority queues. </li></ul></ul><ul><li>Resource management : </li></ul><ul><ul><li>LAN: Use admission control (static or dynamic) to provide bandwidth guarantees to vNet traffic. </li></ul></ul><ul><ul><li>End system: Substrate layer on end-system enforce per VLAN and per vNet bandwidth constraints </li></ul></ul><ul><li>Virtual links : In this simple example there is exactly one virtual link for each substrate link. </li></ul><ul><li>Each host to substrate router connection is assigned a distinct VLAN. So N hosts implies N VLANs on Ethernet. </li></ul><ul><li>Alternative is to define one VLAN tree for each protocol suite (i.e. vnet ). </li></ul>VLAN X2 VLAN XN vNet X VR 1 switched LAN
  • 6. Traffic isolation with priority aware substrate vNet X VR 1 Ethernet Hub with High and Low Priority TX queues vNet traffic to High otherwise Low … vNet traffic (internet) Local traffic (intranet) Local control/management; Legacy internet traffic all vNet traffic High Low High Low High Low High Low
  • 7. Substrate Link as a VLAN Tree … VLAN X <ul><li>Internetworking over a diversified network </li></ul><ul><li>Substrate function with Ethernet: </li></ul><ul><li>Substrate links : The VLAN creates a tree interconnecting all end-systems to the substrate router. Substrate end-point then uses the VLAN tag and source/destination address to realize the logical point-to-point substrate link. </li></ul><ul><li>Sharing and Isolation : </li></ul><ul><ul><li>no change from substrate star topology. The only difference is the shared VLAN domain. Scheme provides traffic isolation. </li></ul></ul><ul><li>Resource management : </li></ul><ul><ul><li>Same </li></ul></ul><ul><li>Virtual links : Same. </li></ul>ethernet switched LAN
  • 8. Multiple Substrate Links VLAN dgram VLAN med VLAN high … <ul><li>Internetworking over a diversified network </li></ul><ul><li>Substrate function with Ethernet: </li></ul><ul><li>Substrate links : Three VLAN trees are used for all virtual net traffic to/from a substrate router: </li></ul><ul><ul><li>Low priority: default for best-effort traffic </li></ul></ul><ul><ul><li>Medium priority for virtual nets with soft performance requirements (average bandwidth) </li></ul></ul><ul><ul><li>High priority for isochronous or low-delay, interactive applications </li></ul></ul><ul><li>Sharing and Isolation : See above. </li></ul><ul><li>Resource management : See above </li></ul><ul><li>Virtual links : Same. </li></ul>ethernet switched LAN
  • 9. Multiple vNets per Host … VLAN 1 VLAN 2 VLAN 3 <ul><li>The full model: </li></ul><ul><li>Substrate link : connects end-system to substrate router. Virtualization of a physical cable or wire. A packet enters one end, exists the other and is opaque within. </li></ul><ul><ul><li>Simplex or Duplex? </li></ul></ul><ul><li>Substrate interface : end-system abstraction </li></ul><ul><ul><li>Ethernet: &lt;interface, VLAN, dst_addr&gt; </li></ul></ul><ul><ul><li>tunnel: MPLS, IP, IPsec, L2TPv3, GRE, AToM </li></ul></ul><ul><ul><li>Layer 2: ATM, others? </li></ul></ul><ul><li>Virtual link : Logical interconnection ( virtual wire ) of adjacent vNet nodes. </li></ul><ul><ul><li>Point-to-point, Simplex or Duplex? </li></ul></ul><ul><li>Virtual interface : end-system abstraction representing one end of a virtual link. Substrate defines mechanism for multiplexing onto common substrate link. For example a virtual link identifier (VLI) in a substrate header </li></ul><ul><ul><li>Simplex or Duplex? </li></ul></ul>VLAN tag and dst addr identify substrate router. VLI tag used to router pkt ether addr/vlan ether addr/vlan ether addr/vlan ethernet LAN substrate interface virtual interface substrate interfaces virtual interface VLI VLI VLI VR 1 VLI VLI VR 1
  • 10. Multiple next hop VRs VLAN A1 vNet X VR 1 vNet X VR 2 vNet X VR 3 VLAN A2 VLAN A3 Host A member of vNet X and vNet Y ethernet switched LAN <ul><li>Multiple Next Hop Virtual Routers: </li></ul><ul><li>Substrate link : per end-system, substrate router pair. </li></ul><ul><li>Substrate interface : three substrate interfaces: </li></ul><ul><li>SI 1 = &lt;eth0, VLAN XA1 , enetAddr SR1 &gt; </li></ul><ul><li>S I 2 = &lt;eth0, VLAN XA2 , enetAddr SR2 &gt; </li></ul><ul><li>SI 3 = &lt;eth0, VLAN XA3 , enetAddr SR3 &gt; </li></ul><ul><li>Virtual link : Logical point-to-point connection between virtual end-system and access virtual router. Since we model a point-to-point link there is no need for link addresses. </li></ul><ul><li>Virtual interface : Representation of virtual link on the end-system. The substrate assigns a per substrate link, virtual link identifier (VLI) for each virtual link. </li></ul><ul><li>VI 1 = &lt;SI 1 , VLI 1 &gt; </li></ul><ul><li>VI 2 = &lt;SI 1 , VLI 2 &gt; </li></ul><ul><li>VI 3 = &lt;SI 2 , VLI 1 &gt; </li></ul><ul><li>VI 4 = &lt;SI 3 , VLI 1 &gt; </li></ul>enetAddr SR1 enetAddr SR2 enetAddr SR3 enetAddr A substrate router 1 substrate router 2 substrate router 3 vNet Y VR 1 VLI 1 VLI 2 VLI 1 VLI 1
  • 11. TCP/IP as an Example Protocol Substrate Interface: Directly connected: destination IP address + ARP = enet addr Gateway: (Gateway’s IP + ARP = enet addr) + VLAN Virtual Interface: Directly connected: Not used, model only for internetworking Gateway: VLI assigned by substrate. How is this integrated into the current ARP/route interface? IP … vNet Protocl = IP eth0 standard ethernet Interface ethernet device VLAN X direct connect ethernet LAN Substrate Router SR 1 ethernet dest. addr vint 0 VLAN X eth 0 vNet framework VLI VLI virtual interface VLI vint0 (eth0,VLAN,ethDst) 192.168.12.254 * ( default ) ARP eth0 0.0.0.0 192.168.12.0/24 ll_info substrate interface gateway ( router address ) destination prefix VLAN VLI
  • 12. Using Tunnels for the substrate layer <ul><li>Need to look into the various tunneling approaches/protocols. How can we leverage these? </li></ul><ul><ul><li>MPLS and MPLS VPNs </li></ul></ul><ul><ul><li>Generic Routing Encapsulation (GRE): RFC 2784 </li></ul></ul><ul><ul><li>Point-to-point tunneling protocol (PPTP) </li></ul></ul><ul><ul><li>Secure VPN </li></ul></ul><ul><ul><li>Any transport over MPLS (AToM) </li></ul></ul><ul><ul><li>IP tunnel </li></ul></ul><ul><ul><li>IPsec VPNs </li></ul></ul><ul><ul><li>Layer 2 Tunneling Protocol version 3 (L2TPv3) </li></ul></ul><ul><ul><ul><li>version3 is a draft standard </li></ul></ul></ul><ul><ul><ul><li>RFC 2661: Layer 2 tunneling protocol </li></ul></ul></ul><ul><ul><li>802.1Q Tunneling: Cisco 802.1Q-in-Q VLAN Extension Services </li></ul></ul><ul><li>What about MPLS over IP tunnels: what was done there? </li></ul>
  • 13. OS Kernel Block Diagram configuration: registers, MMU (TLB, cache, VM) bus and peripherals System Exception handlers ethernet Socket Interface IP routes clock handler process accounting scheduling time management uart eth0 timer hardware dependent layer HW interrupt/Exception hardware independent layer scheduler SW int (AST) callout Q TCP poll task management ops Device independent I/O Interrupt Processing AST Processing User Space (Applications) Hardware TC/ AST qdisc OS ISR demux callback util UDP RAW IP TCP n TCP 2 TCP 1 … TCP module tasks open files FS management buffer cache ops File Interface Basic I/O Interface txqueue rxqueue device driver
  • 14. User or kernel Space protocols? <ul><li>Each has pros and cons </li></ul><ul><li>User space protocols: </li></ul><ul><ul><li>easier to implement and debug </li></ul></ul><ul><ul><li>easier to introduce new protocols (not tightly dependent on socket layer knowing about the new protocol) </li></ul></ul><ul><ul><li>easier to isolate and protect protocols and apps from each other (leverage process model) </li></ul></ul><ul><li>kernel level protocols </li></ul><ul><ul><li>easier to integrate into existing framework (simplifies support for system interface functions like select/poll) </li></ul></ul><ul><ul><li>simplifies intra-protocol security and protection (since protocol runs within trusted kernel) </li></ul></ul><ul><ul><li>simplifies (well, more direct) kernel demultiplexing to correct protocol context (endpoint) </li></ul></ul><ul><ul><li>increased efficiency </li></ul></ul>
  • 15. User Space Protocol Implementation <ul><li>Uncommon outside of high-performance community, they want zero-copy and specialized demux keys. </li></ul><ul><li>Problems: asynchronous processing, life cycle, authentication and demultiplexing to endpoints </li></ul><ul><ul><li>latency in delivering packets (i.e. acks) to user space </li></ul></ul><ul><ul><li>increased overhead in per packet processing before a drop/keep decision is made </li></ul></ul><ul><ul><li>processing received acks </li></ul></ul><ul><ul><li>timeouts and retransmissions </li></ul></ul><ul><ul><li>establishing connections and security: snooping, masquerading </li></ul></ul><ul><ul><li>supporting select and poll </li></ul></ul><ul><ul><li>protocols where connection may outlive process (TCP’s TIMED_WAIT) </li></ul></ul><ul><ul><li>global routing and address resolution tables </li></ul></ul><ul><ul><li>global connection tables </li></ul></ul><ul><ul><ul><li>need to know what other ports are being used (locally) </li></ul></ul></ul><ul><ul><ul><li>accepting/rejecting new connections </li></ul></ul></ul>
  • 16. Assumptions <ul><li>Assumptions: </li></ul><ul><ul><li>Applications using different VNs (or no VN) will need to communicate using the various IPC mechanisms </li></ul></ul><ul><ul><li>We want to manage all aspects of Network I/O but not the use of other traditional resources (memory, files etc) </li></ul></ul><ul><ul><li>CPU, memory and interface bandwidth controlled at the virtual net granularity </li></ul></ul><ul><ul><li>intra- VN, implementers should have the mechanisms to support QoS and Security </li></ul></ul><ul><ul><li>simple mechanism for adding new protocols/VNs </li></ul></ul>
  • 17. User Space Protocols <ul><li>Chandramohan A. Thekkath , Thu D. Nguyen , Evelyn Moy , Edward D. Lazowska, Implementing network protocols at user level , IEEE/ACM Transactions on Networking (TON), v.1 n.5, p.554-565, Oct. 1993 </li></ul><ul><li>Chris Maeda, Brian Bershad, Protocol Service Decomposition for High-Performance Networking , Proceedings of the 14th ACM Symposium on Operating Systems Principles . December 1993, pp. 244-255. </li></ul><ul><li>Aled Edwards , Steve Muir, Experiences implementing a high performance TCP in user-space , Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication, p.196-205, 1995 </li></ul><ul><li>Kieran Mansley, Engineering a User-Level TCP for the CLAN Network , Proceedings of the ACM SIGCOMM workshop on Network-I/O convergence: experience, lessons, implications , Pages: 228 – 236, 2003 </li></ul>
  • 18. user-space protocols: Global Issues <ul><li>Routing : Direct packets to/from correct endpoint/interface </li></ul><ul><ul><li>How is traffic demultiplexed and sent to the correct endpoint/process? </li></ul></ul><ul><ul><ul><li>In-kernel filters </li></ul></ul></ul><ul><ul><li>Where are the routing tables and how are they maintained? </li></ul></ul><ul><ul><ul><li>route fixed when connection established or located in shared memory </li></ul></ul></ul><ul><li>Control : I use IPv4 as an example </li></ul><ul><ul><li>Address resolution protocols/tables? </li></ul></ul><ul><ul><li>Other control protocols. For example ICMP, IGRP, others? </li></ul></ul><ul><ul><li>Where are the routing protocols implemented? </li></ul></ul><ul><li>Management : </li></ul><ul><ul><li>Must manage a protocols namespace (for example, port numbers in IPv4). </li></ul></ul><ul><ul><li>Common programming technique, allow protocol instance to select local address part </li></ul></ul><ul><ul><ul><li>specify port = 0 and addr = 0 then implementation will assign correct values </li></ul></ul></ul><ul><ul><li>Passive connect model? </li></ul></ul><ul><ul><ul><li>In IPv4 a server listens on a port (host:port:proto) for a connection request. To establish a connection a unique (to the endsystem) port number is assigned and new socket allocated. </li></ul></ul></ul><ul><ul><li>socket-oriented system calls must be supported. On UNIX must support non-blocking I/O with select and poll. </li></ul></ul><ul><ul><li>Connection lifetime may outlast process. </li></ul></ul><ul><ul><ul><li>For example TCP TIME_WAIT or simply waiting for a final ack or resending if no ack received. </li></ul></ul></ul><ul><li>Security : we must provide sufficient mechanisms for protocol developers </li></ul><ul><ul><li>implementations must be able to guard against masquerading and eavesdropping </li></ul></ul>
  • 19. User Space: Configurations <ul><li>Given these global issues there are two likely configurations: </li></ul><ul><ul><li>all traffic passes through common protocol daemon in user space </li></ul></ul><ul><ul><li>control daemon implements basic set of control functions while user library implements majority of data path functions </li></ul></ul><ul><ul><li>prior work has shown the latter approach to be superior. </li></ul></ul><ul><li>Having all traffic pass through a common protocol daemon =&gt; at least one extra copy operation (kernel -&gt; daemon -&gt; user process) </li></ul><ul><li>A better solution is for a daemon to insert relatively simple packet filters in kernel for established connections which directs packets to/filters packets from endpoints. </li></ul>
  • 20. User-Space: Passive Open socket layer connection filters vnetX control daemon: (namespace, lifecycle, connections) ethernet vnet demux 3. insert incoming and outgoing filters for vnetX connection 1. connection request (in) 4. new connection 0. listen/accept (passive open) 5. data, established connections compare against connection specific outgoing filter use VLI to access incoming filters and use to demux to filter set and/or socket. data copy 2. ack (out) vnetX : protocol library application
  • 21. User-Space: Active Open socket layer connection filters vnetX control daemon: (namespace, lifecycle, connections) ethernet vnet demux 3. insert incoming and outgoing filters for vnetX connection 4. new connection 0. connect 5. data, established connections compare against connection specific outgoing filter data copy 1. connection request (out) 2. ack (in) use VLI to access incoming filters and use to demux to filter set and/or socket. vnetX : protocol library application
  • 22. User-Space: Datagram (Connectionless) socket layer connection filters ethernet vnet demux 1. insert incoming and outgoing filters for vnetX connection 2. new connection (local address) 0. open(any) 3. data established connections compare against “connection” specific outgoing filter use VLI to access incoming filters and use to demux to socket. In this case only the local part is used. data copy daemon fills in local address and binds to socket. No restrictions on destination vnetX control daemon: (namespace, lifecycle, connections) vnetX : protocol library application
  • 23. User-Space: Datagram (Connectionless) socket layer connection filters ethernet vnet demux 1. insert incoming and outgoing filters for vnetX connection 2. new connection(local and remote) 0. open(local and remote addr) 3. data established connections compare against “connection” specific outgoing filter use VLI to access incoming filters and use to demux to socket. data copy daemon fills in both local and destination addresses. Destination restricted vnetX control daemon: (namespace, lifecycle, connections) vnetX : protocol library application
  • 24. User-Space: App exits socket layer connection filters vnetX control daemon: (namespace, lifecycle, connections) ethernet vnet demux 3. remove filters 1. connection close ( out ) drop 2. ack ( in/out ) TCP enters TIME_WAIT after close vnetX : protocol library application
  • 25. Extensible protocol frameworks in the kernel <ul><li>Herbert Bos, Bart Samwel, Safe Kernel Programming in the OKE , Proceedings of the fifth IEEE Conference on Open Architectures and Network Programming , June 2002 </li></ul>
  • 26. OKE <ul><li>Context : For performance reasons it is useful to permit third parties to load optimized modules into the kernel </li></ul><ul><li>Problem : Third party code is untrusted so loading into kernel will compromise system security and reliability. Could use safe execution environment like java but incurs expensive runtime checks. </li></ul><ul><li>Solution : create set of mechanisms and policies to permit non-root users to safely load untrusted application modules into kernel space with minimal impact on runtime performance. </li></ul><ul><ul><li>Safety : use a trusted compile to enforce policies (constraints). The constraints are designed to ensure the untrusted module will not adversely affect the kernel (core and loadable modules) or unrelated processes. </li></ul></ul><ul><ul><li>User privileges : Vary enforced constraints based on user privileges (customizable language) </li></ul></ul><ul><ul><li>Termination : well defined termination boundaries to protect system state </li></ul></ul><ul><ul><li>Enforcement : Static and dynamic checks; language extensions </li></ul></ul><ul><ul><li>Ease of use : Familiar development environment using Cyclone (type safe, C extension) and kernel module. </li></ul></ul><ul><li>Contribution : definition of safe kernel programming environment that meets competing needs: </li></ul><ul><ul><li>performance </li></ul></ul><ul><ul><li>safety </li></ul></ul><ul><ul><li>ease of use </li></ul></ul><ul><ul><li>hosted in a commodity OS </li></ul></ul>
  • 27. Considerations <ul><li>Identified areas where modules may impact system behavior </li></ul><ul><ul><li>program correctness : language restrictions for safety and enforce coding conventions </li></ul></ul><ul><ul><li>Memory access : static and dynamic enforcement of memory access rules </li></ul></ul><ul><ul><li>Kernel module access : static and dynamic enforcement of kernel module (interface) access restrictions </li></ul></ul><ul><ul><li>Resource usage : Bounded (deterministic or limited) </li></ul></ul>
  • 28. Pushing protocols into the Kernel <ul><li>Positives: </li></ul><ul><ul><li>All the issues associated with user-space protocol simply go away. Global tables and lifetime of the kernel </li></ul></ul><ul><ul><li>Performance, efficiency, existing code base </li></ul></ul><ul><ul><li>Enhances intra-Protocol security </li></ul></ul><ul><ul><li>Simplifies integration with existing network I/O subsystems and interfaces </li></ul></ul><ul><li>Negatives: </li></ul><ul><ul><li>Isolation: More difficult to isolate system from protocol instances. Inter-protocol isolation difficult. </li></ul></ul><ul><ul><li>Security: Proving trust/security more difficult </li></ul></ul><ul><ul><li>Implementation and debugging more difficult in kernel </li></ul></ul>
  • 29. Kernel-Space Protocols … TCP n TCP 2 TCP 1 … UDP RAW IP IP routes TCP HW interrupt/Exception HW Interrupt SW Interrupt User Space (Applications) Hardware Application(s) vnet /dev/protoX /dev/vnet udp:port tcp:port rawIP … vnet:ep vnet:ep route to interface TCP/IP … Rework! ethetnet eth device driver open files FS management buffer cache ops File Interface I/O Interface vnet Demux VLAN Socket I/O Interface vnet ops vnet Proto state tables Socket Interface PF_VNET PF_INET eth0 vnet Proto state tables

×