Hi Peter,
> So now we move to VLAN level?
Yeah, but I'm still waiting for the answers to my questions from two emails
ago:
> I'd be happy to still track this bug down but I need you to investigate
> the behaviour in your environment. If you've torn down the lab already we
> can also just call it quits.
>
> If you do want to continue some questions are still pending, see quoted below.
>
> > 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:
signature.asc
Description: PGP signature