I'm having trouble announcing a single /24 from an
ASN. ASN is multi-homed to ISP-A and ISP-B, prepending
on ISP-B side.
ASN in question has one and only one /24 which
originally was from ISP-B /17 block.
Some ISP only sees path from ISP-A and some from ISP-B
and very few sees both paths. Apparently, when we are
testing failover, it failed. (can't get to most of the
internet, can't VPN in from outside, can't send mails
etc.... BGP paht/route disappear from some of looking
glasses)
After the test, I registered /24 and ASN with RADB and
things get slightly better, meaning a few more ISP
sees both but majority of them still seeing single ISP
path.
I've contacted both ISPs and they both claimed they
are announcing our /24 to the rest of the world,
without manipulation.
What am I missing here?
Thanks,
- Kyaw
some providers (for whatever reason, not really relevant to this
conversation) do filter at boundaries NOT /24 
Some filter /20 or /22 or
other odd-ball boundaries.
-Chris
try a peek at route views
and, if you want help debugging, folk will want to know the
prefix and the asn
randy
routeviews is seeing both paths.
64.9.17.0/24
AS 33105
ISP-A = 701 
ISP-B = 19094
Thanks ...
You might talk to 701 about why for instance, all I see is your prepended path via 19094 through 3356, 6461, 4323, and 19962.
Maybe 701 is only propogating your route to customers?
I've heard and seen those filters a few years ago. In
this particular case, I've seen a bunch of other /24s
(from remote ASs) on the looking glasses.
Looks like filters are base on other criteria on top
of prefix length and I wonder which criterion this /24
falls into.
--- "Christopher L. Morrow"
shouldn't be the case, it's not looking like it's tagged anything
'special'. the other folks might see telecove as a better path
(assuming telecove/19094 is also multihomed to these other asn's you have
above)
There are a few ISP they are seeing path from 701. But
very few compare to prepended path via 19094.
e.g
route-server.colt.net (2914 701 33105)
route-views.bmcag.net (1239 701 33105)
Hmmm..
When /24 gets to those ISP (direct connected to
19094/telcove), shouldn't they prefer 701/mci path?
AS-PATH is longer through 19094 than through 701 ...
provided that those ISP are accepting/receiving path
from 701.
--- "Christopher L. Morrow"
Says .. I pick 7018/AT&T.
7018 is accepting 701/mci customer routes. But is 7018
accepting 701/mci customer /24 routes ???
7018 is definitely accepting 19094/telcove /24 routes
because I see 64.9.17.0/24 on ATT route-server
(route-server.ip.att.net)
So, why is 7018 receiving/accepting /24 from some
peers (19094) but not from others (701)???
That .. I can't figure out.
Hmmm..
When /24 gets to those ISP (direct connected to
19094/telcove), shouldn't they prefer 701/mci path?
depends on their relationship with 701 probably, and their internal
decision criteria... they might filter or pref or... who knows 
AS-PATH is longer through 19094 than through 701 ...
provided that those ISP are accepting/receiving path
from 701.
yup, looking at route-views.oregon-ix.net there seem to be plenty of paths
(47 total reported)
Did you open a support ticket with 701?
customer versus Settlement Free Peer perhaps? this is a 7018 question.
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. And at that time, I thought it was RADB
problem and agreed to close the tix.
Now that RADB is fixed, I'm back at square one with
more confusions
I will open case with both 701 and 19094 soon. I am
making sure that I'm not missing a smoking gun.
--- "Christopher L. Morrow"
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. And at that time, I thought it was RADB
yup, we're just passing it along as near as I can tell 
problem and agreed to close the tix.
Now that RADB is fixed, I'm back at square one with
more confusions
I will open case with both 701 and 19094 soon. I am
making sure that I'm not missing a smoking gun.
good luck. sorry it wasn't resolved 'now'
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.
Hi.
How long did you wait to see your block come back during
testing? I've seen it take > 60 seconds in some cases.
For redundancy with non PI IP space, It's generally only
important that the ISP you are getting the IP block from can
see both routes, and that it sees it at the same level of
localpref. (as path differences are okay, as long as they
are consistent.) Since the isp providing the ip space will
announce an aggregate larger than your block, you should be
reachable as long as they can see both routes to you.
-e
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]
On