Jeremiah, Hey there.. What you're describing is basically anycast, (rfc 1546) which is useful for single packet, connectionless UDP type things (dns lookups), but can make connection oriented / statefull protocols break. If you are advertising what appears to be two ways to get to the same prefix, you're relying on having stable paths through the internet to always deliver a packet via the same path the one before it took. If something outside of your control breaks / changes, you may end up changing paths and could start sending packets towards your 'other' (same destination) site mid session. Another thing to be careful of is inconsistent-as. If you plan to have multiple sites advertising the same prefix, they either need to be all part of the same asn, or you need to advertise a separate anycast asn padded w/ unique per-site asns. (Also a good way to withdraw routes is necessary, using gated or something..) I think the anycast rfc mentioned setting aside a block of space for this purpose. ..Dylan | -----Original Message----- | From: Jeremiah Kristal [mailto:jkristal@on2.com] | Sent: Wednesday, July 05, 2000 11:17 AM | To: nanog@merit.edu | Subject: bad idea? | | | | Given a small, globally routable netblock to be used for front-end web | servers, and a strong aversion for using DNS for any type of load | balancing, would it be reasonable to build two identical servers farms | with the same public IP addresses and rely on the BGP | sessions with the | hosing providers to remove one advertisement in the event of | a problem? | I've been looking at ways to ensure that the webservers are always | available, short of building a network connecting hosting facilities. | | Jeremiah | being a customer stinks |
On Wed, Jul 05, 2000, Greene, Dylan wrote:
Jeremiah,
Hey there.. What you're describing is basically anycast, (rfc 1546) which is useful for single packet, connectionless UDP type things (dns lookups), but can make connection oriented / statefull protocols break.
If you are advertising what appears to be two ways to get to the same prefix, you're relying on having stable paths through the internet to always deliver a packet via the same path the one before it took. If something outside of your control breaks / changes, you may end up changing paths and could start sending packets towards your 'other' (same destination) site mid session.
Another thing to be careful of is inconsistent-as. If you plan to have multiple sites advertising the same prefix, they either need to be all part of the same asn, or you need to advertise a separate anycast asn padded w/ unique per-site asns. (Also a good way to withdraw routes is necessary, using gated or something..)
I think the anycast rfc mentioned setting aside a block of space for this purpose.
If you originate it from the same AS then yes, it works just fine. I've run it for web servers before, without a complaint, and a few people here have run it for streaming media and can give you feedback. I haven't tested it for long-held streaming media connections so I can't comment. Adrian
participants (2)
-
Adrian Chadd
-
Greene, Dylan