Re: proper bridging technoque

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/11/13 23:03, Digimer wrote:
> On 20/11/13 20:49, aurfalien wrote:
>>
>> On Nov 20, 2013, at 4:47 PM, Digimer wrote:
>>
>>> On 20/11/13 19:47, aurfalien wrote:
>>>>
>>>> On Nov 20, 2013, at 4:44 PM, Digimer wrote:
>>>>
>>>>> On 20/11/13 19:25, aurfalien wrote:
>>>>>>
>>>>>> On Nov 20, 2013, at 4:13 PM, Digimer wrote:
>>>>>>
>>>>>>> On 20/11/13 19:04, aurfalien wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Wondering if this is the proper bridging technique to use for Centos6+KVM;
>>>>>>>>
>>>>>>>> http://wiki.centos.org/HowTos/KVM
>>>>>>>>
>>>>>>>> Before I embark on this again, I would like to do it by the book.
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>>
>>>>>>>> - aurf
>>>>>>>
>>>>>>> Personally, I do this:
>>>>>>>
>>>>>>> https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Configuring_The_Bridge
>>>>>>>
>>>>>>> It gives the VMs direct access to the outside network, as if they were
>>>>>>> normal servers. I've used this setup for years without issue under many
>>>>>>> different VMs with various OSes.
>>>>>>>
>>>>>>> cheers
>>>>>>
>>>>>> Many many thanks, will use it.
>>>>>>
>>>>>> Sounds like it will bode well concerning jumbo frames.
>>>>>>
>>>>>> - aurf
>>>>>
>>>>> Jumbo frames should be fine. I don't generally use it myself, but I have
>>>>> tested it with success. Just be sure to enable it on the bridge and
>>>>> slaved devices. Simply adding 'MTU="xxxx"' to each ifcfg-x file should
>>>>> be sufficient.
>>>>>
>>>>> -- 
>>>>> Digimer
>>
>> Man, really sorry to bug as this seems begnin as I've done this numerous time but on non bridged ints.
>>
>> When I add MTU=9000 to the bridged int, I get;
>>
>> RNETLINK answers invalid argument 
>>
>> My phys int is showing jumbo but the bridged int is showing standard.
> 
> No bother at all. It has been a bit since I tested it though, so I will
> have to experiment a bit myself....
> 
> Done!
> 
> I remember the trick now; The bridge will take the MTU of the _lowest_
> MTU device connected to it. So in my case here, I up'ed the MTU of the
> backing ethX and bondY devices, but the bridge stayed at 1500.
> 
> Trying to adjust it failed with 'SIOCSIFMTU: Invalid argument', which is
> the kernel's way of saying that the MTU is too large for the device
> (usually hit when surpassing the hardwares real MTU). Being a bridge
> though, this didn't make sense. When I up'ed the MTU of the vnetX
> devices though, the bridge jumped up on its own.
> 
> So I suspect that if you do 'brctl show' and then check the MTU of the
> connected devices, one of them will still have a low MTU. Push it up and
> then do a non-fragmenting ping 28 bytes smaller than your MTU size. If
> the ping works, you know the MTU is increased.
> 
> All this said, my experience with realtek NICs left me detesting them.
> I've seen cards advertised as supporting "jumbo frames" going up to
> silly sizes like 7200 only. Further, in benchmarks, the performance
> dropped over something like an MTU of 4000.
> 
> If you want to determine the actual maximum MTU of a given interface,
> this might help;
> 
> https://github.com/digimer/network_profiler/blob/master/network_profiler
> 
> It's a little script that uses passwordless SSH between two nodes and
> automatically determines the maximum MTU between the two machines and
> then benchmarks at 100 byte intervals. When it's done, it spits out a
> graph showing the full and half-duplex results so you can see which MTU
> was the best to use.
> 
> Once you've profiled the real devices, you can then work on the MTU of
> the higher-layer devices like bonds, bridges and virtual interfaces.
> 
> hth

Another update;

  To make sure the VMs' vnetX devices are created with a larger MTU, you
*sill* need to update udev[1].

  Append to /etc/udev/rules.d/70-persistent-net.rules;

====
# Make all VMs' vnetX devices come up with an MTU of 9000.
SUBSYSTEM=="net", ACTION=="add", KERNEL=="vnet*", ATTR{mtu}="9000"
====

  Assuming you find that you can use an MTU of '9000', of course. No
need to reboot or even restart networking. Just add that line and then
provision/boot your VMs. If the VMs are already running, you can adjust
the MTU of the existing 'vnetX' devices with:

ifconfig vnetX mtu 9000

Cheers!

PS - Credit for the udev rule:

http://linuxaleph.blogspot.ca/2013/01/how-to-network-jumbo-frames-to-kvm-guest.html

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
CentOS-virt mailing list
CentOS-virt@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-virt




[Index of Archives]     [CentOS Users]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Xfree86]     [Linux USB]

  Powered by Linux