> On Sun, 7 Oct 2007 [EMAIL PROTECTED] wrote:
>
>>
>> The diagram looks like:
>>
>> Ax Bx
>> | |
>> Xa---Xb
>> | |
>> LBa--LBb
>> \ /
>> B{1..n} (backend) servers 1 through N
>>
>> On Xa, the preferred path for S is -> LBa.
>> On Xb, the preferred path for S is -> LBb.
>
>
>> The load balancers do not have unique IP addresses. They have the same
>> IP address, call it S1. No other IP addresses from S are in use.
>
> The load balancers in this picture are not Anycast. I think you
> misunderstand both Anycast and HSRP/VRRP. The second one takes over IP
> address S1 when the primary fails.
The diagram above was created by me. I said both LBa and LBb have the
same IP address, and that the two LB's are independent.
This means that they operate *without knowledge* of each other's state,
and only inter-operate at the routing level - both announce S into their
IGP (e.g. OSPF). BGP announces the prefix, once only, and only from the
ASN in question (X).
If you want to change the diagram, and *then* say the diagram is wrong,
that's classic "straw man" crap. *Your* diagram is wrong, but that's
irrelevant - it has no relationship to my diagram.
Whatever you have to say about any diagram where the LB's are aware of
each other, and are configured in primary/standby, is totally irrelevant.
If you want to say anything about the actual scenario as described,
then the following are part and parcel of what is described:
>> All packets from A sent to the single IP address S1, get sent to LBa.
>>
>> All packets from B sent to the single IP address S1, get sent to LBb.
It's my scenario, my diagram. You might not believe that it is possible
for two devices to be configured independently, and still function.
It doesn't mean that, *given* the configuration described, that the
rest follows from that.
If you want to discuss the above, you must first do so within the context
of presuming the preconditions (the diagram as described) are true.
Doing so does not necessarily require you to believe it is true, or that
it is possible - but the two things (the precondition and its consequences)
are independent, and should only be discussed independently.
The purpose of creating a particular scenario is to discuss the merits
and behavior of the system as described.
Changing the scenario invalidates everything you say about the scenario.
> Sorry, this isn't what happens. LBa (the primary) acts and exchanges
> HSRP or VRRP with LBb (the failover). If LBa fails, LBb takes over.
> There is no Anycast. There is no 'effective' Anycast. You just
> misunderstand the concepts.
While it is true that *one* possible way to configure LB's is HSRP/VRRP.
It isn't the *only* way, and it isn't how they are configured in the
scenario above.
> In _every_ non-anycast case, _all_ packets are delivered to _unique_ IP
> addresses, which identify individual, _unique_hosts. There is not
> requirement that all packets take the same path.
IP addresses do not always identify unique hosts.
Counter-examples include hosts whose IP address is assigned in a non-static
method, e.g. DHCP, or via ephemeral services such as NAT. IPv4 to IPv6
gateways, where there is 1:1 NAT, allow an IPv6 host to be reached, but
do not, as such, identify the IPv6 host per se.
RFC 1546 is informational only, experimental, and 14 years old.
It describes hypothetical methods of handling the state requirements
of TCP.
In the intervening time, vendors have provided state capturing mechanisms
to provide this support, and the Load Balancers in question are in fact
both doing anycast, *and* preserving state so TCP flows go to the same
servers behind the Load Balancers.
That a second, third-party-ISP-centric load balancer, doing PPLB across
BGP paths, breaks the TCP access to such a BGP-unicast prefix, is
the only consideration of relevance, and is under the control of the ISP.
Caveat emptor.
Brian
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
