about configuration of vlans, I found this
http://comments.gmane.org/gmane.linux.network/260498
"
[PATCHv2 iproute2 2/3] bridge: Add vlan configuration support
Recent kernel patches added support for VLAN filtering on the bridge.
This functionality allows one to turn a basic bridge into a VLAN
Many thanks for the patch. But I am quite unsure if we should update
vzctl shortly after the 3.1 release.
I also checked the changelogs, and there are countless
ploop/migrate/snapshot/criu related changes and fixes.
As we do not use that functionality I think it is better to defer that update
u
>>The relevant commit says it's disabled by default. Strangely i don't see
>>how to enable and use this from the commits message.
yed, I see that too.
also found this:
"Bridge VLAN kernel/iproute2 incompatibility"
http://www.spinics.net/lists/linux-ethernet-bridging/msg04942.html
don't known
Am 29.08.2013 20:52, schrieb Alexandre DERUMIER:
Hi Stefan,
I don't have a look a vlan-bridge implementation in new kernel.
As far I known, bridge support now vlan tagging (by port?). Maybe it's tagging
by default ?
The relevant commit says it's disabled by default. Strangely i don't see
ho
Hi Stefan,
I don't have a look a vlan-bridge implementation in new kernel.
As far I known, bridge support now vlan tagging (by port?). Maybe it's tagging
by default ?
Mayve try to configure vlan1 to disable vlan filtering ?
Or maybe can we try to implement new vlan code ?
(don't tag anymore o
Hi,
as Linux Kernel 3.10 ist the newest long term kernel i'll start
migrating all my machines to it.
Everything works fine except for tap devices with VLANs on top of bridges.
I'm pretty sure that this i related to this commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git
>>Maybe that is related, because virtio uses TSO, but e1000 not.
Yes, I think that the problem.
>>But dhcp with our Windows server works without problems, so maybe it
>>is related to dnsmasq?
I really don't known ... (maybe this is also related to virtio driver version ?)
Note that I don't have
Yes, I'll do this as soon as I can. Sorry you had to make so much cleanups.
2013/8/29 Dietmar Maurer :
> Just committed you patches, and applied further cleanups:
>
> https://git.proxmox.com/?p=pve-manager.git;a=summary
>
> Many thanks for the patch!
>
> Do you also plan to provide an updated fr.p
OK, thanks for the links.
What I observed recently that dhcp with dmsmaq does not work with virtio,
but works perfectly with e1000.
Maybe that is related, because virtio uses TSO, but e1000 not.
But dhcp with our Windows server works without problems, so maybe it
is related to dnsmasq?
> I hav
>>I use dhcp with bridge about 10 years now, and never observed any problems?
I have also see users on proxmox forum having this problem, don't remember
exactly but it's related to offloading
(offloading of physical interface or offloading in virtio nic)
also on the wiki
http://pve.proxmox.com
> Note :to get dhcp working with bridge, I need this iptables rules
>
> "iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --
> checksum-fill"
>
> because of something bad with packets fragmentation..
I use dhcp with bridge about 10 years now, and never observed any problems?
_
Just committed you patches, and applied further cleanups:
https://git.proxmox.com/?p=pve-manager.git;a=summary
Many thanks for the patch!
Do you also plan to provide an updated fr.po file?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://
>>I think we should accept that dhcp is simply not usable for this kind of
>>setup.
Yes, I think it's ok for user.
(I think that is users with a small numbers of ip, so a small numbers of vms to
do static configuration)
>>I will next try to assemble a patch without that arp tricks, simply
>>u
> How is it possible ? I pulled the last version from git before resending the
> patch. Did I do something wrong when creating it?
I guess something went wrong at that stage, because your patch reverted those
changes.
Anyway, no big deal - just wanted to notify you about that.
_
> So for this kind of routed ip, dhcp is really not possible.
I think we should accept that dhcp is simply not usable for this kind of setup.
I will next try to assemble a patch without that arp tricks, simply
using the bridge setup (as you suggested before).
___
Hi,
I have asked to my network engineer friend,
about if it's possible to allow with dhcp a mask 255.255.255.255.
(for point to point ip routing).
He said me, that it was a trick (not rfc compliant), and was working some year
ago with old os. (old linux,winxp).
But not anymore with new os.(ubun
How is it possible ? I pulled the last version from git before
resending the patch. Did I do something wrong when creating it?
2013/8/29 Dietmar Maurer :
> Just to Note, this patch removes the whole GlusterFS functionaliy silently!
>
> Will try to apply anyways an re-add it.
>
17 matches
Mail list logo
