Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 May 2011 09:49:43 +0200
From:      Frank Razenberg <frank@zzattack.org>
To:        freebsd-virtualization@freebsd.org
Subject:   Re: epair not reachable outside host
Message-ID:  <4DD4CB97.4090103@zzattack.org>
In-Reply-To: <D4F178E5-2261-4119-8A5B-8E7CA23ADFE5@lists.zabbadoz.net>
References:  <4DD3F6AF.6070503@zzattack.org> <E5981B2D-A4D3-4BED-BB27-F715DAC25B5B@lists.zabbadoz.net> <4DD40AD2.9000602@zzattack.org> <E843F7F9-3664-4B6E-B8C1-FC313E078901@lists.zabbadoz.net> <4DD418BA.7080707@zzattack.org> <D4F178E5-2261-4119-8A5B-8E7CA23ADFE5@lists.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
 > What happens if you'd directly bridge it to an em(4) without the lagg 
etc. in between
Thanks, you're right, taking the lagg0 out and adding em0 to the bridge 
instead works indeed. Can I assume that's a bug in if_lagg then? If so, 
where should I report it, the freebsd-bugs list?

Frank

On 5/18/2011 9:51 PM, Bjoern A. Zeeb wrote:
> On May 18, 2011, at 7:06 PM, Frank Razenberg wrote:
>>> Do you have the ifconfig epair0b, netstat -rn and arp -an from inside the VIMAGE as well?
>> [root@fileserve /root]# ifconfig epair0b
>> epair0b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>   metric 0 mtu 1500
>>         ether 02:37:74:00:0f:0b
>>         inet6 fe80::37:74ff:fe00:f0b%epair0b prefixlen 64 scopeid 0x2
>>         inet 10.31.45.12 netmask 0xffffff00 broadcast 10.31.45.255
>>         nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
>>
>> [root@fileserve /root]# arp -an
>> ? (10.31.45.255) at (incomplete) on epair0b expired [ethernet]
>> ? (10.31.45.12) at 02:37:74:00:0f:0b on epair0b permanent [ethernet]
>> ? (10.31.45.1) at (incomplete) on epair0b expired [ethernet]
>>
>> [root@fileserve /root]# netstat -rn
>> netstat: kvm not available: /dev/mem: No such file or directory
>> Routing tables
>> rt_tables: symbol not in namelist
> *sigh*
>
>
>>> Myabe try to ping your default gateway from within the jail first so that there might be actual traffic (or at least an attempt of).
>> Pinging the default gateway within the jail does not work. Pinging the ip of the lagg0 interface which is on the bridge with the epair0a interface /does/ work, as does pinging the aliases of the lagg0 interface (i.e. the other, non-vnet jails).
>> Hope this helps.
> So epair generally works;  What happens if you'd directly bridge it to an em(4) without the lagg etc. in between
> , would that work?  It sounds like some kind of lagg issue at the moment to me given
>
> epair0b<--->  epair0a<--->  bridge0<---->  lagg0
>
> all seems to still work.
>
> /bz
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DD4CB97.4090103>