Hi Peter,
looking at the ip/bridge dumps I don't see anything obviously broken so I
started by building a reproducer using two netns'en and a bridge on the
host to simulate your setup, leaving out the vlan stuff for now.
I setup two namespaces ns0/ns1 with a veth pair each connected to br0 on
the host. I assign MAC addresses statically to make looking at `bridge fdb`
easier (grep ^aa:). The script looks like this (trimmed, full version
attached):
ip netns add ns0
ip link add veth0 type veth \
peer name veth0 address aa:00:00:00:00:00 netns ns0
ip netns add ns1
ip link add veth1 type veth \
peer name veth1 address aa:00:00:00:00:01 netns ns1
ip link add br0 address aa:bb:bb:bb:bb:bb type bridge forward_delay 0
#^ forward_delay=0 to disable STP as this delays interfaces coming up
ip link set dev veth0 master br0
ip link set dev veth1 master br0
ip -n ns0 addr add 10.0.0.100/24 dev veth0
ip -n ns1 addr add 10.0.0.101/24 dev veth1
ip link set br0 up
ip link set dev veth0 up
ip -n ns0 link set dev veth0 up
ip link set dev veth1 up
ip -n ns1 link set dev veth1 up
ip -n ns0 link set dev lo up
ip -n ns1 link set dev lo up
ip netns exec ns0 ping -c4 10.0.0.101
Seems to work fine. So we can establish the basic functionality does work
and we need to go deeper.
Peter, can you confirm this script works on your system? If so the next
step is introducing vlans.
On Mon, Oct 30, 2023 at 07:25:38PM +0000, peter.gasparovic@orange.com wrote:
> 1) As was reported, foreign external world MAC@ does not pass into
> network namespace, just external border point "vlan199"
How did you check this?
> 2) now collecting data for you, honestly I don’t see external mac address
> on "inet-br" object, so my previous statement was incorrect.. {ossibly I
> might mixed this up with another "labinet-br" (working in its limited
> scope) which is IP-defined, while "inet-br" in question is not.
>
> 3) so question is, if the MACs learnt via vlan199 are supposed to be
> paired (displayed) with "inet-br" object and all way up into NS....
I want to make sure we're on the same page, how do you check if the MAC is
reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
this will tell you whether ARP is even reaching the NS or not.
Something simple like
$ tcpdump -enli $IFACE 'arp or icmp'
optionally you can filter by MAC (`ether host` in pcap-filter speak):
$ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
Oh and one last thing: please double and tripple check that a firewall
isn't interfering.
--Daniel
Attachment:
repro.sh
Description: Bourne shell script
Attachment:
signature.asc
Description: PGP signature