Re: VMAC problems

Judging by my experiments thus far, my posts and similar post to this
list this strikes me as a kernel issue. Either there is a missing config
option needed, a committed patch that has broken macvlan support or an
incompatibility between the kernel and keepalived (which I doubt).

I think this because I was able to use "ip link add" on my workstation,
which is running a Debian kernel v3.2.0, to setup a virtual adapter.
Altering the ARP parameters as prescribed in the vmac doc I get the
expected results. An ARP response with the correct MAC address and the
virtual interface is fully functional. I did have to enable promiscuous
mode on the physical adapter to get it to work.

When I try the same thing on the Gentoo server running kernel 3.10.17,
custom configured, it doesn't work, even when I manually setup the
virtual adapter as opposed to allowing Keepalived to do it. Keepalived
is always running on this machine so it could be a keepalived problem if
having keepalived running can interfere with the kernel some how.

I'm not sure doing the additional tcpdump will tell me anything more
than what I already know. The packets are not getting through kernel
space or are being ignored. Either way its in the kernel where I have
the trouble and no matter what combination of ARP parameters and config
settings on the adapters I've tried nothing gets it to speak, except
when I ping it from the local machine.

I'm going to double check our kernel config settings and look at the
patch history to see if anything is enlightening.

THX - Jon

Ranjith Rajaram wrote:
> Hello,
>
> On 07/04/2014 12:57 AM, Jon Foster wrote:
>> tcpdump showed ARP requests being received. Enabling martian logging
>> didn't produce any log output. The rp_filter parameter provided no
>> change. setting arp_ignore to '0' on the parent interface (eth1, in
>> this case) produces responses to arping, but with the MAC of the
>> parent interface not the vmac. Setting net.ipv4.conf.all.arp_ignore
>> to '1' or on eth1 directly cause the new IP address to fail to respond.
>>
>
> If you attach tcpdump on vrrp.XX interface(Ex. tcpdump -s0 -i vrrp.51
> arp), do you see the packets (trying to check if the packet has
> progressed so far)
>
> I used a similar configuration on RHEL 7
> http://fpaste.org/115570/ [configuration]
>
> Everything seems to work fine. I did not notice any problem with it so
> far. Ran a small script to remove the arp cache entry and perform the
> ping in a loop. I received the vrrp mac everytime
>
> Hope someone else has a better suggestion
>
>> I should also mention that pinging from the machine itself does
>> produce results but of course nothing shows up in the arp table.
>>
>> THX - Jon
>>
>> Ranjith Rajaram wrote:
>>> Jon
>>>
>>> can you check using tcpdump whether you are receiving the packet at the 
>>> interface ?(arp request)
>>>
>>> Can you enable sysctl -w net.ipv4.conf.all.log_martians = 1 and check 
>>> syslogs/dmesg to see if these packets are being logged as martians
>>>
>>> If they are logged as martians, Disable the rp_filter and check
>>>
>>> sysctl -w net.ipv4.conf.vrrp/XXX.rp_filter=0 [replace XX appropriately]
>>>
>>>
>>> On 06/25/2014 05:11 PM, Ranjith Rajaram wrote:
>>>   
>>>> Jon
>>>> On 06/25/2014 03:50 PM, Ranjith Rajaram wrote:
>>>>     
>>>>> Jon
>>>>>
>>>>> On 06/25/2014 05:35 AM, Jon Foster wrote:
>>>>>       
>>>>>> I've been trying to use the vmac support without much success. First the
>>>>>> system details:
>>>>>>
>>>>>> Distro: Gentoo Linux x86_64 Linux current.
>>>>>> Kernel: Linux 3.10.17 x86_64
>>>>>> Keepalived: 1.2.12
>>>>>>
>>>>>> I've followed the "NOTE_vrrp_vmac.txt" file. And have a config like this:
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> vrrp_instance vrrp-eth1-1 {
>>>>>>        state MASTER
>>>>>>        interface eth1
>>>>>>        virtual_router_id 19
>>>>>>        priority 100
>>>>>>        advert_int 2
>>>>>>        use_vmac
>>>>>>        vmac_xmit_base
>>>>>>        notify_master "/etc/keepalived/config_vmac vrrp/19"
>>>>>>        virtual_ipaddress {
>>>>>>            10.10.10.19
>>>>>>        }
>>>>>>        authentication {
>>>>>>            auth_type AH
>>>>>>            auth_pass SECret
>>>>>>        }
>>>>>>        smtp_alert
>>>>>> }
>>>>>> -----
>>>>>>
>>>>>> My notify script looks like this:
>>>>>>
>>>>>> -----
>>>>>> #!/bin/sh
>>>>>> # Tweak global ARP handling. All of these default to 0
>>>>>> sysctl -qw net.ipv4.conf.all.arp_ignore=1
>>>>>>         
>>>>> Can you try setting sysctl to 0 instead of 1 and check
>>>>> sysctl -w net.ipv4.conf.all.arp_ignore=0
>>>>>
>>>>> 1 - reply only if the target IP address is local address
>>>>> 	configured on the incoming interface
>>>>>
>>>>>       
>>>> ignore this
>>>>
>>>>     
>>>>>> sysctl -qw net.ipv4.conf.all.arp_announce=1
>>>>>> sysctl -qw net.ipv4.conf.all.arp_filter=0
>>>>>>
>>>>>> # Alter eth1 behavior
>>>>>> sysctl -qw net.ipv4.conf.eth1.arp_filter=1
>>>>>>
>>>>>> # Finally configure the virtual network adapter
>>>>>> sysctl -qw "net.ipv4.conf.$1.arp_filter=0"
>>>>>> sysctl -qw "net.ipv4.conf.$1.accept_local=1"
>>>>>> -----
>>>>>>
>>>>>>
>>>>>> The global ARP settings are setup as described in the notify script, so
>>>>>> the notify script is redundant for that purpose. Just making sure it
>>>>>> doesn't get changed by someone else.
>>>>>>
>>>>>> My problem is simple. No response from the virtual IP address. Except
>>>>>> for the notify script, use_vmac and vmax_xmit_base the configuration
>>>>>> works. When I add these lines I see the virtual adapter created but
>>>>>> can't ping it or get a response from it. It does however switch between
>>>>>> MASTER and BACKUP with its BACKUP server as expected.
>>>>>>
>>>>>> I've manually setup macvlan adapters with a Linux 3.2.0 i386 system and
>>>>>> configured the ARP settings the same and the virtual adapter works for
>>>>>> me. The only difference that I see from my test setup and the vmac setup
>>>>>> by keepalived is that I was using "bridge" mode and keepalived uses
>>>>>> "private".
>>>>>>
>>>>>> I should also mention that with my test macvlan adapters I had to
>>>>>> manually enable "promiscuous" mode on the real NIC for it to work. I had
>>>>>> modified my notify script to do that also... but to no avail.
>>>>>>
>>>>>> Anyone know what I'm doing wrong?
>>>>>>
>>>>>> THX - Jon
>>>>>>
>>>>>>         
>>>   
>>
>> -- 
>> Sent from my Debian Linux laptop -- http://www.debian.org/intro/about
>>
>> Jon Foster
>> JF Possibilities, Inc.
>> [email protected]
>> 541-410-2760
>> Making computers work for you!
>>     
>

-- 
Sent from my Debian Linux laptop -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
[email protected]
541-410-2760
Making computers work for you!

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel