Am I to infer that this a result of a certain design decision of Linux bridging where the bridge intercepts all traffic from the member interfaces, rather than letting traffic directed to the host be delivered normally?
The "suck" part is all the major changes taking place in point releases, that from their perspective arent so major but cause a major headache to the rest of us.
This confused me too when I started trying to figure out where I got peth0. It's not explained as clearly as I'd have liked.
What happens in the default bridge scripts is that one of the Xen virtual devices is linked into a bridge (xenbr0 by default) with the real ethernet device, and then the real ethernet device is renamed peth0, and the virtual interface is renamed eth0. This allows the same startup scripts, etc, to be used before and after starting up the xen bridge, but to refer to the Xen virtual interface (and hence the bridge) when that's appropriate.
The shorewall guide to firewalling on Xen 3 is quite useful in understanding what's going on:
Comments 4
(The comment has been removed)
Reply
Reply
(The comment has been removed)
Reply
What happens in the default bridge scripts is that one of the Xen virtual devices is linked into a bridge (xenbr0 by default) with the real ethernet device, and then the real ethernet device is renamed peth0, and the virtual interface is renamed eth0. This allows the same startup scripts, etc, to be used before and after starting up the xen bridge, but to refer to the Xen virtual interface (and hence the bridge) when that's appropriate.
The shorewall guide to firewalling on Xen 3 is quite useful in understanding what's going on:
http://www.shorewall.net/Xen.html
and the Xen My Way document by the shorewall author was also useful for hints:
http://www.shorewall.net/XenMyWay.html
Ewen
Reply
Leave a comment