How do you access nodes through over tap-bridge over Linux bridge?

32 views
Skip to first unread message

Nato Morichika

unread,
Feb 12, 2019, 6:17:26 PM2/12/19
to ns-3-users
I have a set up like this:

Layer 2 Topology:
                 [ linux ]        
                 +------------+
[ node 2 ]       | bridge     |
[ tap-bridge ]---|-[ tap ]    |   [ lxc container ]
                 | [ vm-tap ]-----[ eth0 ]
                 +------------+

IP addresses:
tap-bridge: 10.1.3.1/24
bridge
: 10.1.3.2/24
eth0
: 10.1.3.254/24

I am trying to access 10.1.3.1 (on a CSMA net device of Node 2) from inside of the LXC container, The Node seems to get the ICMP packet from LXC, but it did not send any ICMP reply. 

Here are some logs I gathered from ns3:

ping from 10.1.3.254, no respond: 
136.033 [node 2] Ipv4StaticRouting:RouteOutput(0x559ad5787be0, 0x559ad58961a0, tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 3 protocol 1 offset (bytes) 0 flags [none] length: 84 10.1.3.1 > 10.1.3.2, 0, 32707)
136.033 [node 2] Ipv4StaticRouting:LookupStatic(0x559ad5787be0, 10.1.3.2, " ", 0)
136.033 [node 2] Searching for route to 10.1.3.2, checking against route to 127.0.0.0/8
136.033 [node 2] Searching for route to 10.1.3.2, checking against route to 10.1.1.0/24
136.033 [node 2] Searching for route to 10.1.3.2, checking against route to 10.1.3.0/24
136.033 [node 2] Found global network route 0x559ad57a6880, mask length 24, metric 0
136.033 [node 2] Matching route via 0.0.0.0 at the end
ArpL3Protocol:Lookup(0x558f4cc40b20, 0x558f4cdd9cd0, 10.1.3.254, 0x558f4cc507d0, 0x558f4cd0ff80, 0x7ffdfcddd240)
node
=2, no entry for 10.1.3.254 -- send arp request
ArpL3Protocol:SendArpRequest(0x558f4cc40b20, 0x558f4cd0ff80, 10.1.3.254)
ARP
: sending request from node 2 || src: 02-06-00:00:00:00:00:0b / 10.1.3.1 || dst: 02-06-ff:ff:ff:ff:ff:ff / 10.1.3.254
ArpL3Protocol:Receive(0x558f4cc40b20, 0x558f4cc507d0, 46, 2054, 02-06-00:00:00:00:00:0c, 02-06-00:00:00:00:00:0b, 0)
ARP
: received packet of size 46
ArpL3Protocol:FindCache(0x558f4cc40b20, 0x558f4cc507d0)
ARP
: received reply node=2, got reply from 10.1.3.254 for address 10.1.3.1; we have addresses:
10.1.3.1,
node
=2, got reply from 10.1.3.254 for waiting entry -- flush
ArpL3Protocol:Lookup(0x558f4cc40b20, 0x558f4cdd9cd0, 10.1.3.254, 0x558f4cc507d0, 0x558f4cd0ff80, 0x7ffdfcdde170)
node
=2, alive entry for 10.1.3.254 valid -- send
It seems to be working, but nothing actually being sent.

ping from 10.1.3.2, got respond:
155.372 [node 2] Ipv4StaticRouting:RouteOutput(0x559ad5787be0, 0x559ad5954db0, tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 5 protocol 1 offset (bytes) 0 flags [none] length: 84 10.1.3.1 > 10.1.3.254, 0, 32707)
155.372 [node 2] Ipv4StaticRouting:LookupStatic(0x559ad5787be0, 10.1.3.254, " ", 0)
155.372 [node 2] Searching for route to 10.1.3.254, checking against route to 127.0.0.0/8
155.372 [node 2] Searching for route to 10.1.3.254, checking against route to 10.1.1.0/24
155.372 [node 2] Searching for route to 10.1.3.254, checking against route to 10.1.3.0/24
155.372 [node 2] Found global network route 0x559ad57a6880, mask length 24, metric 0
155.372 [node 2] Matching route via 0.0.0.0 at the end
ArpL3Protocol:Lookup(0x558f4cc40b20, 0x558f4cdfef20, 10.1.3.2, 0x558f4cc507d0, 0x558f4cd0ff80, 0x7ffdfcddd240)
node
=2, alive entry for 10.1.3.2 valid -- send

tcpdump output (run on bridge of linux):
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br
-inet_user, link-type EN10MB (Ethernet), capture size 262144 bytes
17:48:01.508447 IP 10.1.3.2 > 10.1.3.1: ICMP echo request, id 30320, seq 1, length 64
17:48:01.510326 IP 10.1.3.1 > 10.1.3.2: ICMP echo reply, id 30320, seq 1, length 64
17:49:17.582776 IP 10.1.3.254 > 10.1.3.1: ICMP echo request, id 297, seq 1, length 64
17:49:17.593359 ARP, Request who-has 10.1.3.254 (ff:ff:ff:ff:ff:ff) tell 10.1.3.1, length 46
17:49:17.593855 ARP, Reply 10.1.3.254 is-at da:4f:a6:e4:d2:a2, length 28
17:49:18.613339 IP 10.1.3.254 > 10.1.3.1: ICMP echo request, id 297, seq 2, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel




Reply all
Reply to author
Forward
0 new messages