Hi Lee,
Le 02/04/2019 13:53, Lee Nelson a écrit :
I'm running a snapshot from March 31. It did fix a problem with
split-horizon, but the arp/broadcast problem still exists.
OK, then it's definitely something different.
I'm not being flippant when I say you should log a bug. The guys who
work
Hi Henry,
Le 02/04/2019 13:39, Henry Bonath a écrit :
It looks like a patch may have been produced, but I do not know how to test
it. I'm not sure if I can pull down just a small part of the
OpenBSD source, or if the entire OS should be built. (Although I'd love to
learn how to do this)
Yup, the
Hi guys,
Le 02/04/2019 13:18, Lee Nelson a écrit :
This sounds very similar to the problem I mentioned over the last couple of
days in an email with the subject "Trouble forwarding between mpw's in
bridge (6.4)".
Sorry, I posted a follow-up to my message in tech@ but not misc@. I
ended up fina
t;ldpd" on the PE host, ARP
works fine as expected every time.
I guess I could fix this with static ARP entries, but that doesn't seem
like quite the right thing. My test setup is running in Virtualbox
VMs. I also replicated the issue under VMWare ESX using 'vic' interfaces.
Does anyone have any clues on this?
Thanks in advance,
Adrian Close
nce had a GSX setup where guest hardware clocks typically ran at 1/3 -
1/10th of realtime, and sped up when the guest OS was eating lots of CPU,
but that doesn't sound like what you have...
Adrian Closeemail: [EMAIL PROTECTED]
107 Essex St, Pascoe Vale web:ht
On Tue, 3 Jan 2006, Joel Knight wrote:
Check the usual suspects?
net.inet.ip.forwarding=1?
Appropriate "pass" rules on the internal interface?
Verify the return path doesn't have a problem?
Also, make sure you're not blocking the ipencap packets.
Check various places with tcpdump - see what's
6 matches
Mail list logo
