-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wip] passthru-interface support #1176
Comments
First attempt turned out to be easier than expected: Running lwaftr on-a-stick over 10GE loopback physical link to packetblaster (enhanced with passthru as well), while running iperf between both tap interfaces works. Configured tap xe0 interface in the network namespace lwaftr, where snabb lwaftr will be run is configured with an IP address. Its MAC address is configured in the passthru-interface section.
The relevant snabb lwaftr configuration section:
Pinging thru the interface while serving 3MPPS IMIX traffic:
Script to create the network namespace and Tap interfaces:
The last command replaces the variable $MACLW in the lwaftr config template with the actual MAC address of the xe0 interface within the namespace. To run lwaftr:
To run packetblaster:
Once lwaftr and packetblaster are launched, one can ping xe0 behind lwaftr from the host:
|
Changed from tap to RawSocket, allowing access to veth link endpoints (and linux network interfaces): vMX is attached to veth link endpoints to LwAftr passthru, allowing not only the vMX to ping the lwaftr endpoints, it also passes BFD and BGP sessions thru snabb between L2L3 switch on the left and the vMX.
The relevant interface config for lwaftr:
You can see the vMX learning the provisioned IPv4 and IPv6 LwAftr interfaces. ICMP pings travel from vMX thru Snabb and via the L2L3 switch back into Snabb. |
I'm sharing this brain dump to collect feedback while working on a prototype.
Snabbvmx offered a unique way to pass control traffic to an attached VM (e.g. Juniper vMX) to handle all network control traffic, from ARP, IPv6 NDP, BFD, LLDP and routing protocols like ISIS, OSPF and BGP. Snabbvmx also offered next-hop resolution for processed packets by periodically sending a copy of the packet to the VM via the VhostUser interface. vmx-docker-lwaftr uses snabbvmx.
lwAFTR evolved dramatically since snabbvmx was introduced. A YANG file is now configuring more than one instances serving network interfaces and more and more basic network functions like ARP and ICMP have been implemented. This allows for alternate deployment options, where multiple interfaces can be served as slaves "on a stick" from a master snabb instance. Availability and routing of traffic towards each snabb instance can be handled via an "out-of-band" BGP session between the connecting L2/L3 switch and a route server, e.g. ExaBGP or Junos RR. (See Video of crr-snabb-lwaftr prototype).
But this design requires an additional interface for the BGP session between switch and the BGP process and something must monitor the health of each lwAFTR instance and update the routing table. Snabbvmx solved this by "fate sharing" of date and control plane thru each interface.
This brings me to the main idea: Pass control traffic (like BGP) thru one or more interfaces of lwAFTR to an auxiliary TAP interface. LwAFTR runs in hairpinning mode.
These auxiliary interfaces are passing thru traffic between the L2/L3 switch and an attached route reflector. The L2/L3 switch, lwAFTR and the route reflector all have unique IPv4 and IPv6 addresses and MAC addresses per link. IMHO LwAFTR doesn't need to know the route reflectors IP address.
Discussion: It is probably sufficient to know its MAC address. Though it is tempting to ignore the MAC address by simply passing BUM (Broadcast & Unknown Multicast) traffic thru, together with packets on the same subnet. But that would make it impossible to use loopback IP addresses. I'll most likely stick to telling lwAFTR the MAC address of the connected route reflector via configuration.
Configuration
The YANG software-config has already containers for internal-interface and external-interface. This shall be extended with a passthru-interface container. The following example illustrates the idea:
There is no need to specify an IP address for the passhtru-interface; forwarding decisions are made at L2 based on the MAC address and optional VLAN towards the TAP interface. The optional leaf's promiscuous and sample-rate are an idea to use the same tap interface for monitoring purposes and merits further investigation.
Next-hop resolution: snabbvmx uses the nh_fwd app to periodically pass a copy of an egress packet to the connected vMX VM. IMHO it is sufficient to specify the IPv4 and IPv6 next-hop address in the lwAFTR config and have the route reflector interact with Snabb config to learn about the active binding table entries and combine them with the internal- and external-interface IP addresses to create routing entries. By having multiple instances, each connected to a separate interface of the L2/L3 switch offers redundancy.
The text was updated successfully, but these errors were encountered: