A few questions that might help narrow down the problem you were seeing: How exactly did you test the fail over? How much time did you wait for things to stabilize before deciding the fail-over did not work and turning the second connection back on? How is your outbound routing setup? Default routes or full tables? If defaults, it would be helpful to see any static routes that might be present. Assuming that 19094 is still announcing the aggregate, the problem of filtering should be a non-issue (assuming they don't filter the 701 path from their upstreams). In any case, things seem to look ok from an outside perspective to most everyone who has commented. John :) -----Ursprüngliche Nachricht----- Von: Elmar K. Bins [mailto:elmi@4ever.de] Gesendet: Thursday, October 20, 2005 1:43 AM An: Kyaw Khine Cc: nanog@merit.edu Betreff: Re: /24 multihoming issue joekhine@yahoo.com (Kyaw Khine) wrote:

I opened ticket with both 701 and 19094 when we did failover 2 weeks ago. Both 701 and 19094 insist that they just take the route and send it out to the rest of the world.

I do see the prefix via both 701 and 19094 (heavily prepended) here in Frankfurt, Germany: 5539 3549 701 33105 12312 3257 7911 19094 33105 33105 33105 33105 5669 286 209 701 33105, (received & used) 8220 2914 701 33105 (and some dupes) Neither one seems to filter wildly; I would believe that you hit aggregate-based (what's an allocation in ARIN terms?) ingress filters somewhere. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---