man, 15 11 2010 kl. 10:29 +, skrev Tomas Daniska:
it's not only ARP reply that takes into account when talking
operability of such solutions.
At one particular case, we had been hit hard with this clustering
method. Over the time, everything worked as the old switches were
slightly lax
Neiberger
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Are multicast MAC addresses allowed in the source
field?
John Neiberger jneiber...@gmail.com writes:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies
-Original Message-
From: Benny Amorsen [mailto:benny+use...@amorsen.dk]
Microsoft were by far not the first to do this, and I still believe that
it is a brilliant solution to a difficult problem, even though we do not
use it.
Maybe, still changes nothing on the fact that if they
-Original Message-
From: Benny Amorsen [mailto:benny+use...@amorsen.dk]
Sent: Monday, November 15, 2010 1:30 PM
If you have the switches do the duplication, you save having to buy a
dedicated duplication appliance (load balancer) which itself can be a
correct me if I'm wrong - but
On Fri, 2010-10-15 at 14:42 -0600, John Neiberger wrote:
On Fri, Oct 15, 2010 at 2:17 PM, christopher.mar...@usc-bt.com wrote:
The I/G bit must be cleared in the source address of an Ethernet frame.
Ref: IEEE 802.3-2002, Section 3.2.3(b)
I'm finding out more about what this firewall
John Neiberger jneiber...@gmail.com writes:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
requests with a multicast MAC address. The idea, ultimately, is that
both firewalls in the cluster will receive
On Fri, Oct 15, 2010 at 2:43 PM, John Neiberger jneiber...@gmail.comwrote:
RFC 1812 section 3.3.2 says it shouldn't work:
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.
Yep, this
The I/G bit must be cleared in the source address of an Ethernet frame.
Ref: IEEE 802.3-2002, Section 3.2.3(b)
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
On Fri, Oct 15, 2010 at 2:17 PM, christopher.mar...@usc-bt.com wrote:
The I/G bit must be cleared in the source address of an Ethernet frame.
Ref: IEEE 802.3-2002, Section 3.2.3(b)
I'm finding out more about what this firewall vendor is actually
trying to do. From what I can gather, it's
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
requests with a multicast MAC address. The idea, ultimately, is that
both firewalls in the cluster
On Fri, Oct 15, 2010 at 2:47 PM, Lee ler...@gmail.com wrote:
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
requests with a multicast MAC address.
jneiber...@gmail.com wrote:
On Fri, Oct 15, 2010 at 2:47 PM, Lee ler...@gmail.com wrote:
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
Sent: Friday, October 15, 2010 3:42 PM
To: christopher.mar...@usc-bt.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Are multicast MAC addresses allowed in the source
field?
On Fri, Oct 15, 2010 at 2:17 PM
RFC 1812 section 3.3.2 says it shouldn't work:
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.
Yep, this is a Checkpoint cluster connected to Cisco switches. Once I
discovered the right
14 matches
Mail list logo
