Host to Host Traffic Routing from Host Container to Radio Container to OTA Interface #117
Comments
|
For our emane with olsrd with application-host containers hanging off of radio LXC lans, we use olsr HNAs (Host Network Advertisement). This is what is done in letce2-tutorial/exp-03. I believe this would address your needs. |
|
Thanks Steve, for the quick response. I was able to gain some insight from the referenced example, and now have HNA enabled for olsrd and the routing tables for all radio nodes correctly identify the host network attached to the radios (135.1.x.2 for the host, 135.1.x.1 for the radio data). However, I am still unable to PING host to host. What I observe is the ARP initiation from say host 1 on eth0 to eth0 on radio1, which as a broadcast message would presumably need to be routed to each OTA radio on the OTA network. The ARPs do not seem to do so. This may be question that is broadly associated with how EMANE can be configured to handle host broadcast types of traffic. What does EMANE require for broadcasting inbound ARP traffic from the host to the OTA network in an environment which includes olsrd with the Basic Multicast Forwarding plug-in. Is it require to simply populate the ARP entries in the host container as an interim solution? The following are some terminal snippets where I am using the 10.100 network for the EMANE transport, 10.98 for the isolation OTA interface, the 135.1 network as the host interface, and 10.99 for the isolated control network. 4 Node Demo Radio-001 ROUTING TABLE [rrpucsuser@radio-001 ~]$ route -n [rrpucsuser@radio-001 ~]$ ping -R radiohost2data [rrpucsuser@radio-002 ~]$ arp [rrpucsuser@radio-002 ~]$ ping radiohost1data -R -c 1 --- radiohost1data ping statistics --- [rrpucsuser@radiohost-001 ~]$ route -n |
|
If you have not already done so, it would be beneficial to run letce2-tutorial/exp-03 and interact with the running experiment. Host-to-host communication works fine. For your setup, verify ip forwarding is enabled in the radio containers: |
|
Hi Steve, in case you have any other insights, here is an update. IP forwarding is set correctly and verified within each container. Using an olsrd.conf file that is nearly identical to the examples, and an IP convention that now matches the demo so that we can communicate using the same IP "currency", I am not able to PING host to host (which is host1data to host2data using the attached hosts file). I am able to PING from radio node to the host data interface of the other radio (e.g. from radio2 container to host1data across the EMANE OTA network, or radio1 container to host2data). [rrpucsuser@radio-002 ~]$ ping -R radio1data [rrpucsuser@radio-002 ~]$ ping -R host1data The routing tables look correct for the hops in the radio nodes showing the HNA elements defining the upstream host IPs. For example, for the radio 2 container for a 2 node configuration: [rrpucsuser@radio-002 ~]$ route -n What I observe in the radio container itself is ARPs coming in from the host container (e.g. host1ctl, or host2ctl), but these ARPs are not be forwarded to the emane0 emulation boundary from what I can tell. I do see OLSRD traffic on the emane0 interface (as well as the OTA interface as multicast) that is occurring at my defined HELLO intervals from the olsrd.conf file. When running the olsrd command manually in the radio container, the two plugins seem to load without any event or error. When I use tshark on the Broadcast Multicast Forwarding (BMF) olsrd plugin, it shows no activity on that particular interface. Attached are some terminal dumps to accompany this description. [rrpucsuser@radio-002 ~]$ ps -ax sudo /usr/local/sbin/olsrd -f /home/rrpucsuser/emane/rrpucs/tests/baseline/config/rrpucs/node-002/olsrd.conf -d 2 *** olsr.org - pre-0.9.8-git_0000000-hash_dce3d5473b0637a358df3777b5012b75 *** Parsing file: "/home/rrpucsuser/emane/rrpucs/tests/baseline/config/rrpucs/node-002/olsrd.conf" ---- Interface configuration ---- Checking emane0: ---------- LOADING LIBRARY olsrd_txtinfo.so.1.1 ---------- -- ALL PLUGINS LOADED! -- Main address: 10.100.0.2 Scheduler started - polling every 50 ms --- 16:29:34.216762 ---------------------------------------------------- LINKS IP address hyst LQ ETX --- 16:29:34.216774 ------------------------------------------------ NEIGHBORS --- 16:29:34.216778 ----------------------- TWO-HOP NEIGHBORS IP addr (2-hop) IP addr (1-hop) Total cost --- 16:29:35.671249 ---------------------------------------------------- LINKS IP address hyst LQ ETX --- 16:29:35.671281 ------------------------------------------------ NEIGHBORS --- 16:29:35.671290 ----------------------- TWO-HOP NEIGHBORS IP addr (2-hop) IP addr (1-hop) Total cost --- 16:29:36.223700 ---------------------------------------------------- LINKS IP address hyst LQ ETX --- 16:29:36.223725 ------------------------------------------------ NEIGHBORS --- 16:29:36.223765 ----------------------- TWO-HOP NEIGHBORS IP addr (2-hop) IP addr (1-hop) Total cost <<<< olsr.org - pre-0.9.8-git_0000000-hash_dce3d5473b0637a358df3777b5012b75 - terminating >>>> *** olsr.org - pre-0.9.8-git_0000000-hash_dce3d5473b0637a358df3777b5012b75 *** Parsing file: "/home/rrpucsuser/emane/rrpucs/tests/baseline/config/rrpucs/node-002/olsrd.conf" [rrpucsuser@radio-002 ~]$ route -n [rrpucsuser@radio-002 ~]$ ping -R radio1ota 64 bytes from radio1ota (10.101.0.1): icmp_seq=2 ttl=64 time=0.050 ms (same route) 64 bytes from radio1emane (10.100.0.1): icmp_seq=2 ttl=64 time=0.896 ms (same route) 64 bytes from radio1data (10.98.1.1): icmp_seq=2 ttl=64 time=0.875 ms (same route) Host System IFCONFIG [rrpucsuser@localhost baseline]$ ifconfig emane.ota: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 host1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 host2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 veth.ctl.001: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.ctl.002: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.ctl.003: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.ctl.004: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.host.001: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.host.002: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.host.003: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.host.004: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.ota.001: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 veth.ota.002: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 RADIO2 CONTAINER IFCONFIG [rrpucsuser@radio-002 ~]$ ifconfig emane0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 ETC/HOSTS Node Control10.99.0.200 radiocontrol Jammer Control Interfaces10.99.0.131 jammer1ctl Radio Data Interfaces10.98.1.1 radio1data CAM Interfaces10.97.0.1 cam1 Radio EMANE Transport Interfaces10.100.0.200 radioemane Radio EMANE OTA Interfaces10.101.0.1 radio1ota |
|
Did you run letce2-tutorial/exp-03 and verify host-to-host communication? Do you have a default route on each host pointing to its respective radio? |
|
Yes, I was able to get the letce2 tutorial to work. There is a default route in each host container, and what I have observed is the ARP broadcast message which precedes any traffic from host to host, is observed on the eth0 (host lan) interface to the radio container, but is not getting routed to the emane0 emulation/transport boundary. It was my assumption, perhaps incorrectly, that the Broadcast Multicast Flooding plugin to the OLSRD application might be responsible for this activity. Perhaps you have some thoughts on how initial broadcast traffic, such as ARPs, would nominally be routed to the EMANE interface for transmission over the air. |
|
The host containers are arping for the MAC address of the IP next hop for a respective destination based on the routing table. In this case, the attached radio is the default route out, so it is the target of the host container's arp. If you are not using default routes, you would need specific host network routes on each host container - but those would still point to the host container's attached radio and work the same way. The only arps going over-the-air are the ones generated by the radio container looking for the the MAC address of the IP next hop for self-generated or IP forwarded traffic. ARPs are not forwarded. |
|
Thanks for the input. I was working with the assumption that the models with paired radio and host containers acted somewhat as a Layer 2 Ethernet switch or device, and as such host to host ARP requests (using broadcast destination) and ARP responses (using unicast destination) would actually traverse the entire OTA network intact to the actual host containers destinations. That would be similar to the Layer 2 radios we design. |
|
We have done custom transports for customers using OVS for that purpose. You might want to start there. |
|
Thanks Steve for focusing my attention into the right direction. I was making some false assumptions about OTA ARPs host to host. I now have it working properly based on your input. Closing this baby and long thread out. |
This is likely a Linux network routing issue, not EMANE issue proper, but I wanted to obtain the best practices guidance when using EMANE in a network configuration consisting of two containers for a logical "node":
I want to send host traffic from say host #1 (135.1.1.2) to host #2 (135.1.2.2), but it is not currently doing so across the EMANE OTA network using some default routes in the radio container.
Olsrd routing is running in each of the radio containers, and they are able to find the other radio interfaces of a peer (i.e. IP addresses in the OTA 10.100.0.0/24 network), and a dump of the IP routing table on the radio container running EMANE indicates OTA connectivity between the radio container's EMANE instances.
What may be missing is the routing necessary in the radio container to forward traffic from the host container (received on interface eth0) to the EMANE virtual transport (on interface emane0). The host traffic uses the IP convention of 135.1.x.2, and I would want this host traffic to be carried across the network intact (perhaps without any form of NATing) to the destination host.
In the radio container, I have the default route set to the emane0 with the Gateway set to the IP assigned to the radio (e.g. 10.100.0.1).
I would like the solution to be somewhat generic and not specify specify host IPs as part of static routing if possible, so that it is host IP agnostic.
I have attempted simply forwarding the traffic from the host interface as eth0 to and from the emane0 interface using the following commands.
Using tshark on the three interfaces in a radio container, as eth0 (host interface), emane0 (EMANE application/emulation boundary), and eth2 (isolated OTA bridge), I can view the host traffic (originally just ARPs) entering eth0, but none of this traffic on either emane0 or eth2.
Since the host traffic needs to be delivery between hosts intact, I am avoiding any NAT type of operations such as MASQUERADE in the IPTable commands.
Any thoughts on what is probably a common test modality?
Should ARPs flow across the EMANE network, or do they need to be explicitly assigned in the host container?
Does the host traffic need to map to the EMANE 10.100.0.1 net to be sent OTA, or is the EMANE tap interface promiscuous?
What is the recommended solution for what is probably a very common test modality?
The text was updated successfully, but these errors were encountered: