Re: mcx(4) and bridge(4)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> A netbsd-10 xen Dom0 hangs off a mcx(4) interface, with three vlans
> (2,3,5) hooked onto three bridge(4)s.  The vlans are for the sake of
> the DomUs, the Dom0 itself has an ip on vlan2.

> The Dom0 has full network access without any issues.

> The DomU can reach the Dom0 and vice versa (ssh login). But nothing
> it sends will leave the Dom0; a tcpdump on vlan2 logs its arp
> requests for external addresses (default gateway, subnet-local
> nameserver), but never a reply.

Does tcpdump on mcx0 show the request leaving?

bouyer@ suggested that it's something wrong with mcx leading to it not
receiving packets for the domU.  Snooping on the mcx could help tell;
if this is the problem, you'll see the arp request go out and then,
depending on whether you specified -p to tcpdump, either having tcpdump
running will fix it or you won't see anything coming back.

It occurs to me that it could also be that net.inet{,6}.ip.forwarding
is turned off, but your test with the bge led to something turning it
on (handwave: some script might notice you're bringing up multiple
interfaces?).

Another possibility is that you've got packet filtering turned on on
mcx but not on bge, such that it's dropping relevant traffic.

I definitely would start by snooping traffic to see where ARP is
failing.  Is the dom0 not receiving the request?  Is it not sending it
on?  Is the other host not receiving it?  Is the other host not
replying?  Is the dom0 not receiving the reply?  Is the dom0 not
passing the reply to the domU?  Is the domU not receiving it?  Is the
domU receiving but not processing it?  There's plenty of opportunity
for something to get lost.

At least with ARP you don't have to worry about MTU issues!

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B