<-> VM
> \ lagg0lagg0.103 bridge1 tap22vtnet2
> \-> Host ^
> em0 <--/
>
> So in other words, plugging the external port into the switch, creating a new
> "external" VLAN, adding both em0 and re0 in
new LAGG and creating
> VLAN child interfaces off of that.
>
> ...
>
> So in the LAGG setup, why aren't the ARP replies going across bridge2 to the
> VM?
For the archives: this turned out to be operator error in the form of a MAC
address conflict between the lagg0 inte
xternal" VLAN, adding both em0 and re0 into a new LAGG and creating VLAN
child interfaces off of that.
I tried the new setup today and it worked except that the VM no longer received
ARP replies from the external network. Using tcpdump on the host's lagg0.99, I
saw the ARP request from
On Tue, Sep 04, 2012 at 09:18:43AM -0400, Brad Plank wrote:
B> VLAN interfaces that have a parent interface configured with an IP
B> address do not show up in the arp table. If the VLAN's parent interface
B> does not have an IP address, it will show up in the arp table.
B> [
VLAN interfaces that have a parent interface configured with an IP
address do not show up in the arp table. If the VLAN's parent interface
does not have an IP address, it will show up in the arp table.
[Notice the output from ifconfig below, to duplicate this issue.]
#ifconfig
em0: flags
Hi.
On 01.09.2012 1:04, Brad Plank wrote:
VLAN interfaces no longer show up in "arp -an", in FreeBSD 9.x, however,
the VLAN appears to be fully functional. Any ideas?
They do.
arp -an
? (86.109.196.1) at 00:21:1b:d1:14:1b on vlan818 expires in 1192 seconds
[vlan]
? (89.250.213.
VLAN interfaces no longer show up in "arp -an", in FreeBSD 9.x, however,
the VLAN appears to be fully functional. Any ideas?
# ifconfig
em0: flags=8843 metric 0 mtu 1500
options=9b
ether 08:00:27:b7:11:3b
inet 10.20.13.104 netmask 0x broadcast 10.
W dniu 13.05.2011 20:10, Jeremy Chadwick pisze:
On Fri, May 13, 2011 at 02:48:01PM +0200, Bartosz Woronicz wrote:
Since I moved from 7.3-stable to 8.2-stable I go strange long
responses of arp, with arping.
I.e.
root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92
79.110.194.140
In the last episode (May 13), Bartosz Woronicz said:
> Since I moved from 7.3-stable to 8.2-stable I go strange long responses
> of arp, with arping.
> I.e.
> root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92
> 79.110.194.140
> ARPING 79.110.194.140
> 60 byte
On Fri, May 13, 2011 at 02:48:01PM +0200, Bartosz Woronicz wrote:
> Since I moved from 7.3-stable to 8.2-stable I go strange long
> responses of arp, with arping.
> I.e.
> root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92
> 79.110.194.140
> ARPING 79.110.194.140
Since I moved from 7.3-stable to 8.2-stable I go strange long responses
of arp, with arping.
I.e.
root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92
79.110.194.140
ARPING 79.110.194.140
60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec
60 bytes from 00:15
Since I moved from 7.3-stable to 8.2-stable I go strange long responses
of arp, with arping.
I.e.
root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92
79.110.194.140
ARPING 79.110.194.140
60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec
60 bytes from 00:15
On 03/15/11 14:26, Jeremy Chadwick wrote:
On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote:
Is anyone aware of some sort of facility in either FreeBSD
8.1-RELEASE or the em(4) driver which would cause it to cache MAC
addresses / ARP entries for hosts on a per-protocol basis
On 03/15/11 14:26, Jeremy Chadwick wrote:
On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote:
Is anyone aware of some sort of facility in either FreeBSD
8.1-RELEASE or the em(4) driver which would cause it to cache MAC
addresses / ARP entries for hosts on a per-protocol basis
On Tue, Mar 15, 2011 at 09:30:39AM -0400, Steve Polyack wrote:
> Is anyone aware of some sort of facility in either FreeBSD
> 8.1-RELEASE or the em(4) driver which would cause it to cache MAC
> addresses / ARP entries for hosts on a per-protocol basis?
>
> [snipping remaining detai
Is anyone aware of some sort of facility in either FreeBSD 8.1-RELEASE
or the em(4) driver which would cause it to cache MAC addresses / ARP
entries for hosts on a per-protocol basis? We've been doing some
testing with new routers, and almost every time we switch them in or out
our Fr
On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers wrote:
>
>
> On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote:
>>
>>
>> I agree with Jeremy. I think that the problem that you've
>> discovered is the fact that it's using stdio-based buffered output
>> instead of buffering more of the contents
On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote:
>
>
> I agree with Jeremy. I think that the problem that you've
> discovered is the fact that it's using stdio-based buffered output
> instead of buffering more of the contents in a string and punting it
> out in larger chunks.
> HTH,
> -G
On Sat, Jun 5, 2010 at 8:16 PM, Jeremy Chadwick
wrote:
> On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote:
>> On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote:
>>
>> >
>> > [root@ ~]# time arp -na > /dev/null
>> >
>> > real 0m1
On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote:
> On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote:
>
> >
> > [root@ ~]# time arp -na > /dev/null
> >
> > real 0m12.761s
> > user 0m2.959s
> > sys 0m9.753s
> > [root@ ~]#
> >
On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote:
>
> [root@ ~]# time arp -na > /dev/null
>
> real 0m12.761s
> user 0m2.959s
> sys 0m9.753s
> [root@ ~]#
>
>
> Notice that "arp -na" takes about 13s to execute even though there is no
> other loa
I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having
a network interface (em(4)) configured with 4000 aliases. The "arp -na"
command takes what I consider to be an extremely long time to finish (up to
30s on an otherwise unloaded system). I am able to
Am 26.04.2010 18:02, schrieb Julian Elischer:
> On 4/26/10 1:11 AM, Stefan Esser wrote:
>> I debugged this problem and prepared a patch for discussion, which
>> later was committed by Max Laier (if memory serves me right). The
>> message was added in order to identify further situations, where
>> n
On 4/26/10 1:11 AM, Stefan Esser wrote:
Am 22.04.2010 20:43, schrieb Marin Atanasov:
Hello,
Thanks a lot for the patch, Qing!
It works fine. However I've noticed one thing, after I start mpd5 and
connect to my home network:
kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize
Am 22.04.2010 20:43, schrieb Marin Atanasov:
> Hello,
>
> Thanks a lot for the patch, Qing!
>
> It works fine. However I've noticed one thing, after I start mpd5 and
> connect to my home network:
>
> kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize()
>
> Not very sure if th
Hello,
Thanks a lot for the patch, Qing!
It works fine. However I've noticed one thing, after I start mpd5 and
connect to my home network:
kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize()
Not very sure if this is something to worry about or not?
Regards,
Marin
On Tue, A
>
> I was using csup to track RELEN_8_0 branch. Currently I'm syncing to
> RELENG_8.
>
> If I understood you right, after getting the sources for RELENG_8, I need to
> apply the patch and then rebuild world?
>
You only need to rebuild the kernel.
-- Qing
__
de before applying the patch.
>
> -- Qing
>
>
>
> On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov wrote:
> > Hi,
> >
> > I was setting up mpd5 from ports, but this proxy-arp issue still exists
> in
> > 8.0.
> >
> >> uname -r
> > 8.0-RE
wrote:
> Hi,
>
> I was setting up mpd5 from ports, but this proxy-arp issue still exists in
> 8.0.
>
>> uname -r
> 8.0-RELEASE-p2
>
> I've attached the output from the mpd5 daemon, where you can still see that
> the issue is relevant.
>
> I've also tri
Hi,
I was setting up mpd5 from ports, but this proxy-arp issue still exists in
8.0.
> uname -r
8.0-RELEASE-p2
I've attached the output from the mpd5 daemon, where you can still see that
the issue is relevant.
I've also tried to apply the patch, but it's no longer on that l
Thank you !
The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with
mpd5).
Please, somebody fix the bug kern/141285...
Li, Qing wrote:
Hi,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read
Hi,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:
1. Unable to add proxy-arp entries for the remote ppp clients.
2. Log showing "ifa_add_loopback_
The patch is now available at
http://people.freebsd.org/~qingli/PPP-Patch-2.diff
You need to rebuild the kernel as well as the userland
"arp" utility.
I have performed various but limited unit testing, including
simulating the reported PPP issue. The patch appears to be
doi
Hi,
I think I managed to reproduce this issue. The root cause appears
to be the SIN_PROXY usage, which is no longer part of any routing
entry after the L2/L3 rewrite. As such, the RTM_GET command
should be issued once in the ARP utility, not twice.
In addition, since ARP does not apply to PPP
@freebsd.org; freebsd-curr...@freebsd.org
Subject: proxy arp and MPD in RELENG_8
Hi,
some time ago I noticed that there's a problem with the new arp implementation
- proxy arp was somehow not working when mpd is involved. I decided to try this
out again assuming it was fixed for the re
Hi,
some time ago I noticed that there's a problem with the new arp implementation
- proxy arp was somehow not working when mpd is involved. I decided to try this
out again assuming it was fixed for the release...unfortunately the problem is
still there...
Here are the last few lines o
On Thu, Aug 14, 2008 at 10:29:09AM -0400, Mike Tancsa wrote:
> At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote:
>> Same thing.
>>
>> http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html
>>
>
> Well, that narrows it down a bit since you are not running with Intel
> nics. It see
At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote:
Same thing.
http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html
Well, that narrows it down a bit since you are not running with Intel
nics. It seems to be in the commits below between
date=2008.07.30.18.00.00
and
date=200
On Tuesday 01 April 2008, Abdullah Ibn Hamad Al-Marri wrote:
> Hello,
>
> Did you see these weird msgs before? I didn't see any of them when I was
> using i386 and 6.x over 2 years.
>
I see these all the time. I'm on a really large network, so I always assumed
they originated from some misbehaving
-0xb on isa0
Timecounters tick every 1.000 msec
ad0: 238475MB at ata0-master SATA150
ad4: 238475MB at ata2-master SATA150
ad6: 381554MB at ata3-master SATA150
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/ad0s1a
em0: link state changed to UP
pid 14686 (httpd), uid 80: exit
The Address Resolution Protocol (ARP) contains an address format
identifiers as part of the frame format. This is so it could be used
as generalized solution to discover different types of addresses on a
broadcast network. For IP, the address format in the frame ought to
be (as I recall
Hi
I`ve got the same messages on FreeBSD 6-STABLE (tracked every second
week). I think that somebody is using default MAC address on network.
Best regards
> Hi!
>
> This morning, I found this in the daily periodic mail from a RELENG_7
> machine:
>
> +arp: unknown hardware addr
Hi!
This morning, I found this in the daily periodic mail from a RELENG_7
machine:
+arp: unknown hardware address format (0x)
+arp: unknown hardware address format (0x)
+arp: unknown hardware address format (0x)
+arp: unknown hardware address format (0x)
+arp: unknown hardware
On Tue, Mar 06, 2007 at 10:24:46AM +, Chris Rees wrote:
>
> If your NIC is knackered, where are you from? I can post you one I'm
> not using, instead of you buying one. It's a Realtek PCI 8139 10/100
> Mb/s. Let me know if you're interested.
Thank you very much for the offer! However, I have
ss=0x02 card=0x15d9 chip=0x10968086
rev=0x01 hdr=0x00
> [EMAIL PROTECTED]:0:1: class=0x02 card=0x15d9 chip=0x10968086
rev=0x01 hdr=0x00
>> I plugged in a USB ethernet adapter (realtek), and it works straight away.
>> "tcpdump -n arp" sees the same noise
st group isnt set up to test. I will send a patch to
> >> try sometime before end of day.
>
> OK, here is the patch, this should fix it...
Hi Jack, the patch didn't seem to have any effect. When I run "tcpdump -n arp"
after rebooting with this patch, I still see 2-3
patch, this should fix it...
Cheers,
Jack
--- dist/if_em.c Sun Jan 21 04:13:37 2007
+++ ./if_em.c Tue Mar 6 05:13:07 2007
@@ -245,6 +245,8 @@
static voidem_set_promisc(struct adapter *);
static voidem_disable_promisc(struct adapter *);
static voidem_se
On Mon, Mar 05, 2007 at 10:02:26AM -0800, Jack Vogel wrote:
> On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> >On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> >> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >> > >
> >> > >Maybe more of your dmesg might help as it could show
On 3/5/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> > >
> > >Maybe more of your dmesg might help as it could show interrrupt issues
> > >that perhaps others could help diagnose
> >
> >
On 3/5/07, Mark Costlow <[EMAIL PROTECTED]> wrote:
On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
>
> Yes, agreed, this might be revealing.
Here's the full dmesg.
On Mon, Mar 05, 2007 at 08:41:01AM -0800, Jack Vogel wrote:
> >
> >Maybe more of your dmesg might help as it could show interrrupt issues
> >that perhaps others could help diagnose
>
> Yes, agreed, this might be revealing.
Here's the full dmesg. Thanks for looking at this.
-
On Sun, Mar 04, 2007 at 11:37:01PM -0800, Jack Vogel wrote:
>
> These are one of our latest NICs, I have had no trouble with these
> but I'm used to using them on an Intel design, not SuperMicro.
>
> First question, do you get the same behavior on both ports?
> My first guess is that this is a BI
ss=0x02 card=0x15d9 chip=0x10968086
rev=0x01 hdr=0x00
> [EMAIL PROTECTED]:0:1: class=0x02 card=0x15d9 chip=0x10968086
rev=0x01 hdr=0x00
>
>
> The symptom:
>
> The machine boots OK, but can only intermittently make netork connections.
> Eventually determined
086
> rev=0x01 hdr=0x00
> [EMAIL PROTECTED]:0:1: class=0x02 card=0x15d9 chip=0x10968086
> rev=0x01 hdr=0x00
>
>
> The symptom:
>
> The machine boots OK, but can only intermittently make netork connections.
> Eventually determined that it seems to only see a f
968086
rev=0x01 hdr=0x00
The symptom:
The machine boots OK, but can only intermittently make netork connections.
Eventually determined that it seems to only see a few ARP packets, so
it's falling out of other machines' ARP tables, and is often unable to
see the replies to its own A
OK, but can only intermittently make netork connections.
Eventually determined that it seems to only see a few ARP packets, so
it's falling out of other machines' ARP tables, and is often unable to
see the replies to its own ARP requests. It does see SOME ARPs
though. When it
On 24/01/07, Ilia Gorstkin <[EMAIL PROTECTED]> wrote:
Hi all!
FreeBSD 6.2-release.
I'm having trouble with arp:
arp: unknown hardware address format (0x4500)
and
arp: unknown hardware address format (0x4242)
these messages fall on the console in a plenty.
What kind of device is th
On Jan 24, 2007, at 4:32 AM, Ilia Gorstkin wrote:
I'm having trouble with arp:
arp: unknown hardware address format (0x4500)
and
arp: unknown hardware address format (0x4242)
these messages fall on the console in a plenty.
I do tcpdump -exn "arp[0]=0x45 and arp[1]=0":
tcpdump:
Hi all!
FreeBSD 6.2-release.
I'm having trouble with arp:
arp: unknown hardware address format (0x4500)
and
arp: unknown hardware address format (0x4242)
these messages fall on the console in a plenty.
I do tcpdump -exn "arp[0]=0x45 and arp[1]=0":
tcpdump: verbose output suppre
> Sex, 2006-02-17 às 15:43 +0100, Thomas Franck escreveu:
> > > Unless you take special measures (ng_fec?), one does not
> > > normally connect two NICs on one machine to the same collision
> > > domain.
> >
> > Hmm.. don't really see a problem with that.. two NICs with
> > diffent IP on the same s
Sex, 2006-02-17 às 15:43 +0100, Thomas Franck escreveu:
> > Unless you take special measures (ng_fec?), one does not
> > normally connect two NICs on one machine to the same collision
> > domain.
>
> Hmm.. don't really see a problem with that.. two NICs with
> diffent IP on the same subnet..
On 17 Feb 2006 at 9:00, Chuck Swiger wrote:
> [...]
> ARPOP_REQUESTs are made to the all-ones broadcast MAC address,
> and ARPOP_REPLYs go back addressed to the sender's MAC.
Yes, that's what I was saying... good - so I haven't suddenly
forgotten networking... :)
Thomas Franck wrote:
> On 17 Feb 2006 at 8:07, Chuck Swiger wrote:
[ ... ]
> Isn't the request broadcast and the reply MAC addressed?
ARPOP_REQUESTs are made to the all-ones broadcast MAC address, and ARPOP_REPLYs
go back addressed to the sender's MAC.
FreeBSD notes when ARP
On 17 Feb 2006 at 8:07, Chuck Swiger wrote:
> Thomas Franck wrote:
> [ ... ]
> > It doesn't seem to affect the function of the server, but it's
> > mighty irritating and blows up the logs a lot... plus, I don't
> > think it's supposed to show this behaviour.. :)
> >
> > I've going through the arc
Thomas Franck wrote:
[ ... ]
> It doesn't seem to affect the function of the server, but it's
> mighty irritating and blows up the logs a lot... plus, I don't
> think it's supposed to show this behaviour.. :)
>
> I've going through the archives & web but the threads I found
> didn't fit my case
Sounds like u have two netcards plugged into the same network or
some other sort of network loop.
Steve
- Original Message -
From: "Thomas Franck" <[EMAIL PROTECTED]>
How can an arp reply be received by the wrong interface, though?
Isn't the request broadc
wrong_iface = 0
and it works like expected.. no more messages of that kind...
Thank you... :)
Say.. this this flag is probably aware of run-time changes, too,
hmm? so a "sysctl net.link.ether.inet.log_arp_wrong_iface=0"
would have turned it off without reboot as well, right?
How can an
46 scorpio kernel: arp: 192.168.1.103 is on fxp0
but got reply from 00:10:dc:7b:91:12 on re0
Feb 17 12:40:40 scorpio kernel: arp: 192.168.1.254 is on fxp0
but got reply from 00:a0:c5:44:a0:30 on re0
Feb 17 12:41:50 scorpio kernel: arp: 192.168.1.103 is on fxp0
but got reply from 00:10:dc:7b:91:12
m, and they are added as if_bridge(4) members.
> When i issue arp -na command on the machine i get this:
>
> ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0
> ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0
> ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0
This has been fixed up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Niki Denev wrote:
> Hello,
>
> I have a small machine setup to act as simple network gateway.
> I have one wireless and one wired interfaces without IP configuration
> on them, and they are added as if_bridge(4) members.
> Wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have a small machine setup to act as simple network gateway.
I have one wireless and one wired interfaces without IP configuration
on them, and they are added as if_bridge(4) members.
When i issue arp -na command on the machine i get this
proper arp packet isn't being
sent upstream, so the router isn't getting the change ...
Does anyone have a 'work around' for this?
arp -s 10.0.2.3 00:00:10:20:30:45 pub
On the "old" owner of the ip address, publish the MAC of the new owner
(10.0.2.3 being the
I forgot to add this isn't specific to the em driver, as I use the lnc.
Also, it's not a problem all the time, only sometimes the boxes fail to
send out Gratuitous ARP packets. I have verified by capturing packets and
trying to readd an alias a short period after the failu
I have this same problem on some production servers running
4.10-RELEASE-p16. My work around is to set the arp cache timeout on our
2811 router to 10 seconds.
Colin
David Kirchner
On 11/14/05, David Kirchner <[EMAIL PROTECTED]> wrote:
> We've had this problem too. Some have suggested turning on "portfast"
> on the Cisco switches, but that doesn't resolve it. It causes severely
> long delays when doing net installs (sysinstall has a very long retry
> time for DNS lookups, mea
On 11/14/05, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
> There is a problem with the latest 4-STABLE where when you move an IP from
> one server on the network to a new one, a proper arp packet isn't being
> sent upstream, so the router isn't getting the change ...
&
On 11/14/05, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
>
> There is a problem with the latest 4-STABLE where when you move an IP from
> one server on the network to a new one, a proper arp packet isn't being
> sent upstream, so the router isn't getting the chang
There is a problem with the latest 4-STABLE where when you move an IP from
one server on the network to a new one, a proper arp packet isn't being
sent upstream, so the router isn't getting the change ...
It only appears to affect the new em driver, as I have other servers on
t
Colin Farley wrote:
Hi Matt,
Thanks for your reply. =he model of the Cisco router is 2811. Do
you think that lowering the=imeout to 5 seconds would be ok? I have
seen that Cisco does not recommen= a timeout below 30 seconds but
after reading your reply and seeing as the=e are
seeing as the re are only a couple
dozen
hosts on this subnet I would think that thi s would be fine.
Please
confirm. Thanks again.
Remember that the router is going to have to re-ARP for these hosts
whenever something external sends traffic to them, unless the router
already has
te: 09/19= /2005 01:54PM
cc: Colin Farley <[EMAIL PROTECTED]>
= Subject: Re: Gratuitous ARP
On Monday 19 September 2005 19:31, Colin = Farley wrote:
>1.&nbs=p; Set the arp cache timeou= t of the cisco router
very low so
>that outages a=re = mi
On Monday 19 September 2005 19:31, Colin Farley wrote:
>1.&nbs=p; Set the arp cache timeout of the cisco router very low so
>that outages a=re minimal. I would rather not do this as it will
>problably stress th=e router too much. Unfortunately I know little
>abo
s down to
an arp issue. When a UCARP IP becomes unavailable. = ; I normally
start a constant ping to it from my machine which lives on a d ifferent
subnet, all requests timeout. I log into the cisco router
th= at has an interfaces living on the webserver's subnet. I then
view t
netmask 0xfff0 broadcast XX.XX.XX.95
inet 192.168.12.254 netmask 0xff00 broadcast 192.168.12.255
ether 00:80:c8:ca:50:d2
media: Ethernet autoselect (100baseTX )
status: active
# arp -s 192.168.12.240 auto pub
using interface dc1 for proxy with address 00:80:c8
On Tue, Aug 07, 2001 at 12:41:02AM -0400, diesel wrote:
> You can see this often on misconfigured Bridge. I am not sure if you
> can do this on FreeBSD but in solaris you can just ifconfig the
> interface and assign it another MAC address. This is a feature set of
> solaris starting at 2.5. I a
the default route to the router set to always go
> out through fxp0. When both fxp0 and fxp1 are enabled, I get
> complaints from arp about inquiries going out from fxp0 having answers
> received on fxp1. Everything else 'seems' to be ok. The box is
> running as a web server
t Poy" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Monday, February 12, 2001 5:25 AM
> Subject: Re: BRIDGE breaks ARP?
>
>
> > > > whether or not you have &quo
- Original Message -
From: "Luigi Rizzo" <[EMAIL PROTECTED]>
To: "Vincent Poy" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, February 12, 2001 5:25 AM
Subject: Re: BRID
ed:
> I do not have MROUTING.
And neither do I.
I noticed something else this morning that might be significant. My
main desktop machine (the one which can't talk directly to my bridge
via its "rl0" interface unless I use an "arp -s" command to hardwire
it with knowle
> > can you repeat exactly what the problem was (bridge machine not
> > responding to ARP requests ?) and what is your exact setup (i
...
> The problem is that the bridge machine can not communicate any
> other machines unless net.link.ether.bridge=0. That is no response
&
perfectly for me in all respects other
than ARP.
The "rl0" card in my bridge is identified as an "Accton MPX 5030/5038",
and I'm running it in 100baseTX full-duplex mode (connected to another
machine via a crossover cable).
Rich Wales [EMAIL PROTECTED] http://www.w
On Sat, Feb 03, 2001 at 02:26:10PM -0800, Rich Wales wrote:
> I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the
> BRIDGE option, bridging between two PCI NICs (rl0 and xl0).
>
> I'm having ARP problems. Machines on the "rl0" card are unabl
I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the
BRIDGE option, bridging between two PCI NICs (rl0 and xl0).
I'm having ARP problems. Machines on the "rl0" card are unable to
get a hardware address for the bridge. (For whatever reason, I have
no prob
gt; > > >
> > > > > On Sat, Sep 23, 2000 at 05:42:02PM -0400, Ted Sikora wrote:
> > > > > > I did a buildworld on several servers last week (STABLE)
> > > > > > and they all get this error message.
> > > > > > /kernel: arp:
ines.
> >
> > Who knows? Anyway, odds are that the ethernet ID's will be printed on the
> > bottom, accompanied by a bar code. If not, well, you'd probably have to
> > log into them to find out, or use SNMP (often the default read community
> > is '
Bob K wrote:
>
> On Sun, 24 Sep 2000, Ted Sikora wrote:
>
> > > Ok, here's a question: Is the MAC address of the ethernet card in your
> > > main server/gateway 00:10:b5:6c:33:83 ? (look at the output of ifconfig
> > > -a, or ipconfig /all if it's NT) If it is, then that would point to
> > >
Bob K wrote:
>
> Ok, here's a question: Is the MAC address of the ethernet card in your
> main server/gateway 00:10:b5:6c:33:83 ? (look at the output of ifconfig
> -a, or ipconfig /all if it's NT) If it is, then that would point to
> something very screwy happening with FreeBSD. If it isn't,
On Tue, Sep 12, 2000 at 11:22:00AM -0500, [EMAIL PROTECTED] wrote:
>
> Greetings,
>
> I am running 4.1-Stable. The most recent is as of August 14th. I have
> noticed that when adding an alias to an interface, an equivalent arp entry
> is not included. The alias is still re
> On Mon, 26 Jul 1999 [EMAIL PROTECTED] wrote:
>
> > I've managed to track down the proxy arp problem in 3.2-stable. It was due to
> > misalignment which led to wrong/corrupted destination address and netmask.
>
> Thank you :) If you have a second, could you go
On Mon, 26 Jul 1999 [EMAIL PROTECTED] wrote:
> I've managed to track down the proxy arp problem in 3.2-stable. It was due to
> misalignment which led to wrong/corrupted destination address and netmask.
>
> To fix the proxy arp problem, type:
>
> fetch -o - http:
1 - 100 of 105 matches
Mail list logo
