Re: Confussion over multi-homing
On Thu, 14 September 2000, Brantley Jones wrote:
The problem is GETTING a /20 from anybody. We recently tried and could only get a /23 (being a small start-up). BUT, that /23 is (apparently) globally routable because of peering agreements with L3 and UUNET. Our /23 prefix has yet to be filtered by anybody.
It could be filtered now. You just won't find out about it until you try to reach a particular site, or they try to reach you. There is no practical way to test if an address is being "globally routed." You could try testing every address in your route table, but there is no assurance your route table is complete.
On 14 Sep 2000, Sean Donelan wrote:
On Thu, 14 September 2000, Brantley Jones wrote:
The problem is GETTING a /20 from anybody. We recently tried and could only get a /23 (being a small start-up). BUT, that /23 is (apparently) globally routable because of peering agreements with L3 and UUNET. Our /23 prefix has yet to be filtered by anybody.
It could be filtered now. You just won't find out about it until you try to reach a particular site, or they try to reach you.
There is no practical way to test if an address is being "globally routed." You could try testing every address in your route table, but there is no assurance your route table is complete.
Sean, They won't see it even if their /20 announcement is being filtered as long as their upstream is listening to it. (Upstream being the carrier they obtained the /20 from.) This is because even though some ISP/NSPs may not listen to the specific /20 announcement, I haven't found any who will ignore a /19 or /17 announcement for the master block. As long as they know how to get to that block, and teh "upstream" knows how to get to the /20, the route filtering isn't going to be apparent at all... Until the time that the "upstream" has connectivity issues. --- John Fraizer EnterZone, Inc -- Support your government, give Echelon / Carnivore something to parse -- classfield top-secret government restricted data information project CIA KGB GRU DISA DoD defense systems military systems spy steal terrorist Allah Natasha Gregori destroy destruct attack democracy will send Russia bank system compromise international own rule the world ATSC RTEM warmod ATMD force power enforce sensitive directorate TSP NSTD ORD DD2-N AMTAS STRAP warrior-T presidental elections policital foreign embassy takeover --------------------------------------------------------------------------
On Thu, 14 Sep 2000, John Fraizer wrote:
They won't see it even if their /20 announcement is being filtered as long as their upstream is listening to it. (Upstream being the carrier they obtained the /20 from.) This is because even though some ISP/NSPs may not listen to the specific /20 announcement, I haven't found any who will ignore a /19 or /17 announcement for the master block. As long as they know how to get to that block, and teh "upstream" knows how to get to the /20, the route filtering isn't going to be apparent at all... Until the time that the "upstream" has connectivity issues.
So the general picture is... I advertise a /22 to ISPs A and B, my upstream providers, using space allocated from provider A's assignment. ISP A's connection to the world (okay, ISP A might not exactly be UUNet) goes tits up at which point the world ceases to see any announcements because the aggregate with the shorter prefix has vanished, and they're filtering the longer prefix announced via ISP B. The whole thing seems to be dependent on ISP A not having problems connecting to external ASes. Or am I missing something big? If multi-homing still leaves me dependent on one of my upstreams being alive, there would appear to be something very wrong... -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
On Fri, 15 Sep 2000, Patrick Evans wrote:
On Thu, 14 Sep 2000, John Fraizer wrote:
They won't see it even if their /20 announcement is being filtered as long as their upstream is listening to it. (Upstream being the carrier they obtained the /20 from.) This is because even though some ISP/NSPs may not listen to the specific /20 announcement, I haven't found any who will ignore a /19 or /17 announcement for the master block. As long as they know how to get to that block, and teh "upstream" knows how to get to the /20, the route filtering isn't going to be apparent at all... Until the time that the "upstream" has connectivity issues.
So the general picture is...
I advertise a /22 to ISPs A and B, my upstream providers, using space allocated from provider A's assignment.
ISP A's connection to the world (okay, ISP A might not exactly be UUNet) goes tits up at which point the world ceases to see any announcements because the aggregate with the shorter prefix has vanished, and they're filtering the longer prefix announced via ISP B.
The whole thing seems to be dependent on ISP A not having problems connecting to external ASes.
Or am I missing something big? If multi-homing still leaves me dependent on one of my upstreams being alive, there would appear to be something very wrong...
-- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
That's where you stand if people are filtering your /22 announcement. You're dependent on less specific announcement making it through. Keep in mind that you are only dependent on ISP A for traffic to providers who are filtering on the /20 boundry. There are LOTS of folks out there that filter on the /24 boundry that your announcement will make it through to via ISP B. --- John Fraizer EnterZone, Inc -- Support your government, give Echelon / Carnivore something to parse -- classfield top-secret government restricted data information project CIA KGB GRU DISA DoD defense systems military systems spy steal terrorist Allah Natasha Gregori destroy destruct attack democracy will send Russia bank system compromise international own rule the world ATSC RTEM warmod ATMD force power enforce sensitive directorate TSP NSTD ORD DD2-N AMTAS STRAP warrior-T presidental elections policital foreign embassy takeover --------------------------------------------------------------------------
participants (3)
-
John Fraizer -
Patrick Evans -
Sean Donelan