In the meantime I did some more research. Now I am sure that after
commit r317887 pxeboot is not robust when ARP packets come in. Before
this commit pxe.c had a function readudp() which used PXENV_UDP_READ to
get data from the NFS server and so never an ARP packet was coming in.
Now pxe.c reads dat
After update from FreeBSD V10 Stable to FreeBSD 12 Stable (r360998) the
load of a kernel in pxeboot via NFS is very slow because my server sends
gratuitous ARP packets every 2 seconds.
pxeboot from 11.1 REL (r321354) is ok.
pxeboot from 11.2 REL (r335563) is very slow too.
For every ARP the
ans that if you are running IPv6 only, the switches won't recondigure
S> > theirselves due to lack of gratious ARP.
S> Not sure I follow you, gratuitous ARP is required for IPv4 to work, for
S> IPv6 you need an unsolicited neighbour announcement.
S> > Other protocols, where PPPoE is goo
On 22/09/2016 19:02, Slawa Olhovchenkov wrote:
On Thu, Sep 22, 2016 at 05:50:09PM +0100, Steven Hartland wrote:
Having tested with a number of vendor switches Cisco, Extreme and more
recently Arista only sending gratuitous ARP for IPv4 and unsolicited NA
for IPv6 reliably resulted in rapid
won't recondigure
S> > theirselves due to lack of gratious ARP.
S> Not sure I follow you, gratuitous ARP is required for IPv4 to work, for
S> IPv6 you need an unsolicited neighbour announcement.
S> > Other protocols, where PPPoE is good example simply doesn't have any
S&g
On Thu, Sep 22, 2016 at 05:50:09PM +0100, Steven Hartland wrote:
> Having tested with a number of vendor switches Cisco, Extreme and more
> recently Arista only sending gratuitous ARP for IPv4 and unsolicited NA
> for IPv6 reliably resulted in rapid failover between LAGG ports.
&
> needs to know? That would require lagg to be edited with all the special
S> cases instead of allowing the protocol to handle it they way it needs.
You just said that "without GARP devices can and do ignore", didn't you?
Let's take this as truth, although I doubt. So, if
On Thu, Sep 22, 2016 at 04:52:35PM +0100, Steven Hartland wrote:
S> > S> > S> > Does lagg(4) hardware address change when it failovers?
S> > S> > S> >
S> > S> > S> It moves the address between interfaces which typically moves it
between
S> > S> > S> switches too.
S> > S> >
S> > S> > So, the addres
ress to its own
S> > S> > R> > - set destination hardware to broadcast
S> > S> > R> > - put some payload in there, to make packet of valid size. Why
should it be
S> > S> > R> > gratuitous ARP? A machine can be running IPv6 only, or may
even use
S> >
in order to kick forwarding table on switches, lagg
S> > S> > R> > should:
S> > S> > R> >
S> > S> > R> > - allocate an mbuf itself
S> > S> > R> > - set its source hardware address to its own
S> > S> > R> > - set d
f
S> > R> > - set its source hardware address to its own
S> > R> > - set destination hardware to broadcast
S> > R> > - put some payload in there, to make packet of valid size. Why should
it be
S> > R> > gratuitous ARP? A machine can be running IPv6
On 22/09/2016 15:58, Ryan Stone wrote:
On Thu, Sep 22, 2016 at 4:04 AM, Steven Hartland
mailto:kill...@multiplay.co.uk>> wrote:
The disappointing thing about this is we had a solution, all be it
one not everyone liked, nearly a year ago now and yet here we are
still stuck with a bro
ware address to its own
S> > R> > - set destination hardware to broadcast
S> > R> > - put some payload in there, to make packet of valid size. Why should
it be
S> > R> > gratuitous ARP? A machine can be running IPv6 only, or may even use
S> > R> > wh
On Thu, Sep 22, 2016 at 4:04 AM, Steven Hartland
wrote:
> The disappointing thing about this is we had a solution, all be it one not
> everyone liked, nearly a year ago now and yet here we are still stuck with
> a broken lagg implementation in the tree.
>
I would point out this 4-year-old thread
at in order to kick forwarding table on switches, lagg
should:
- allocate an mbuf itself
- set its source hardware address to its own
- set destination hardware to broadcast
- put some payload in there, to make packet of valid size. Why should it be
gratuitous ARP? A machine can be running IPv6 onl
r to kick forwarding table on switches, lagg
should:
- allocate an mbuf itself
- set its source hardware address to its own
- set destination hardware to broadcast
- put some payload in there, to make packet of valid size. Why
should it be
gratuitous ARP? A machine can be run
kick forwarding table on switches, lagg
R> > should:
R> >
R> > - allocate an mbuf itself
R> > - set its source hardware address to its own
R> > - set destination hardware to broadcast
R> > - put some payload in there, to make packet of valid size. Why should it be
R>
hould:
R> >
R> > - allocate an mbuf itself
R> > - set its source hardware address to its own
R> > - set destination hardware to broadcast
R> > - put some payload in there, to make packet of valid size. Why should it be
R> > gratuitous ARP? A machine can be ru
uf itself
> - set its source hardware address to its own
> - set destination hardware to broadcast
> - put some payload in there, to make packet of valid size. Why should it be
> gratuitous ARP? A machine can be running IPv6 only, or may even use
> whatever
> higher level protoc
on switches, lagg
should:
- allocate an mbuf itself
- set its source hardware address to its own
- set destination hardware to broadcast
- put some payload in there, to make packet of valid size. Why should it be
gratuitous ARP? A machine can be running IPv6 only, or may even use whatever
hi
On 7/09/2016 6:50 PM, Karl Pielorz wrote:
>
>
> --On 06 September 2016 09:42 +0100 Steven Hartland
> wrote:
>
>> Yes known issue I'm afraid.
>>
>> I created a patch set to address this but there where objections so
>> it was removed, see the attached which is based on 10.2-RELEASE.
>
> Hi,
>
--On 06 September 2016 09:42 +0100 Steven Hartland
wrote:
Yes known issue I'm afraid.
I created a patch set to address this but there where objections so it
was removed, see the attached which is based on 10.2-RELEASE.
Hi,
Thanks for the reply, and the comprehensive patch. If I get a ch
--On 06 September 2016 09:13 +0100 Karl Pielorz
wrote:
We've just changed the network config on a box - going from a single
'em1' adapter to a lagg failover of em0, em1.
Sorry - not enough coffee yet, I should have said this is on FreeBSD
10.3-RELEASE-p7 amd64...
-Karl
_
d for the NIC's (and lagg) was now
the MAC for em0 (which I believe is correct behaviour).
Should the act of lagg / IP's coming up not send a gratuitous ARP for
them or something to avoid this?
As it was we had to log into a number of key boxes and 'arp -d' the
IP's -
an ARP entry for the
changed hosts old em1's MAC.
On the lagg machine - the MAC used for the NIC's (and lagg) was now the MAC
for em0 (which I believe is correct behaviour).
Should the act of lagg / IP's coming up not send a gratuitous ARP for them
or something to avoid this?
As
Hi,
I am running a system on FreeBSD 9.1-RELEASE.
I have a device on the network which is sending gratuitous ARP messages
(used by a wireless mesh network for a "bridge-loop avoidance" protocol)
every 10 seconds. This causes the mbuf clusters to slowly increase on
FreeBSD, until t
# ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24
K> >K>
K> >K> 3) master host sends gratuitous ARP.
K> >K>
K> >K> 4) at backup host, I run the following command:
K> >K># ifconfig carp2 create
K> >K># ifconfig carp2 vhid 22
re connected to the same layer 3
K>switch.
K>
K> 2) at master host, I run the following command:
K># ifconfig carp2 create
K># ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24
K>
K> 3) master host sends gratuitous ARP.
K>
K> 4) at backup host, I ru
same layer 3
K>switch.
K>
K> 2) at master host, I run the following command:
K># ifconfig carp2 create
K># ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24
K>
K> 3) master host sends gratuitous ARP.
K>
K> 4) at backup host, I run the followin
create
# ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24
3) master host sends gratuitous ARP.
4) at backup host, I run the following command:
# ifconfig carp2 create
# ifconfig carp2 vhid 22 advskew 100 pass 192.168.1.7/24
5) backup host sends gratuitous ARP.
And so
[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2003 4:54 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: gratuitous ARP with em interface.
>
>
> Thanks all
active interface.
> > >>
> > >>Now when I try running the code with em (gigabit Ethernet
> > over copper)
> > >>NICs, I simply do not see the gratuitous arps come out of the new
> > >>interface.
> > >>
> > >>I am
PROTECTED]
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: gratuitous ARP with em interface.
>
>
> em_ioctl() has a call to ether_ioctl() which in turn calls
> arp_ifinit().
>
> Sreekanth
>
> > -Original Message-
&
#x27;;
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: gratuitous ARP with em interface.
>
>
>
>
>
>
>
> hi,
> I had checked the kernel code of the freeBsd. In case of fxp
> port " fxp_ether_ioctl" fucntional will be
lenius'" <[EMAIL PROTECTED]>, "'Ruslan Ermilov'"
<[EMAIL PROTECTED]>
cc:[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject:RE: gratuitous ARP with em interface.
Could be attributed to the spanning tree in the switch.I h
In article <[EMAIL PROTECTED]>, Petri Helenius
<[EMAIL PROTECTED]> wrote:
> I haven't looked that deep into why, but em is quite slow on coming
> up compared to fxp for example. Probably something to do with
> hardware re-initialization.
I haven't tried this, but I think the problem would go away
Helenius
> Sent: Thursday, May 29, 2003 4:39 AM
> To: Ruslan Ermilov
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: gratuitous ARP with em interface.
>
>
>
> I haven't looked that deep into why, but em is quite slow on
>
this too, no gratuitous ARP is sent.
Cheers,
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
am at a loss to understand what has changed. Could it be that the line
> DOWN -> UP time of the em interface is longer thereby causing a loss of
> ARPs ? Any suggestions ?
>
Yes, I can reproduce this too, no gratuitous ARP is sent.
Cheers,
--
Ruslan Ermilov Sysadmin a
Hi all,
Is there a known issue with alias IPs on em interfaces not sending out
gratuitous arps ?
The situation is as follows:
I am running a custom redundancy daemon that migrates the IP address of a
server from one interface to another in case the active network path fails.
Till now I was exp
On Sun, 2 Sep 2001, I wrote:
> I think, ultimately, the only guaranteed way is to construct your own ARP
> packet and write it at the link layer. arping uses libnet for this.
... and just for a lark, I rolled a tool using libnet to fulfill my own
requirements. sharball attached. Requires the li
On Sat, 1 Sep 2001, Paul Chvostek wrote:
> FWIW, on aliased IPs, I seem to be unable to generate the who-has arps
> unless I specify the netmask. Just doing "ifconfig if0 a.b.c.d alias"
> does not seem to be sufficient. But the actual value of the netmask
> should not affect ARP, since ARP doe
local arp table rather than just relying on routing.
> a) in the case where the address is an alias, re-issuing the
>ifconfig ... alias results in a gratuitous ARP for the alias address
>without losing the subnet route & ARP cache entries. However I use a
>netmask of 255.2
s, re-issuing the
ifconfig ... alias results in a gratuitous ARP for the alias address
without losing the subnet route & ARP cache entries. However I use a
netmask of 255.255.255.255 for all aliases in the same subnet as the
primary, in line with the ifconfig(8) manual.
b) in the case wher
[EMAIL PROTECTED] (Joshua Goodall) writes:
> Easy question time, but I can't find it documented. How can I reliably
> (and non-destructively) trigger the sending of a single gratuitous ARP
> reply for some local IP/MAC address?
arping (from ports) and ping the broadcast addres
nd it documented. How can I reliably
> > (and non-destructively) trigger the sending of a single gratuitous ARP
> > reply for some local IP/MAC address?
> >
> Under "local", do you mean the IP assigned to one of the local host's
> interfaces? If so, that
On Tue, Aug 28, 2001 at 01:47:20PM +0100, Joshua Goodall wrote:
>
> Easy question time, but I can't find it documented. How can I reliably
> (and non-destructively) trigger the sending of a single gratuitous ARP
> reply for some local IP/MAC address?
>
Under "local"
Easy question time, but I can't find it documented. How can I reliably
(and non-destructively) trigger the sending of a single gratuitous ARP
reply for some local IP/MAC address?
Joshua
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
48 matches
Mail list logo
