> 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?


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 netmask 0xffffff00 broadcast
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

[root@fileserve /root]# arp -an
? ( at (incomplete) on epair0b expired [ethernet]
? ( at 02:37:74:00:0f:0b on epair0b permanent [ethernet]
? ( 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

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 

epair0b<--->  epair0a<--->  bridge0<---->  lagg0

all seems to still work.


freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to