ASN question

RouterOS Forwarding Protocols
1

We have a /22 address space announced via a single peer with our ASN with three /24 subnets currently visible to 100% of peers.

Six months later we are now announcing the last /24 subnet through a second peer and BGP peering is established - but RIPE stats show that our AS is only visible to 55% of peers globally through this second peer and this final subnet is not widely reachable.

I’m confident that our router config is good so my question is could there be a problem with our route objects in the RIPE database? We originally created a route object for the entire /22 route when we started peering, then announced the final /24 subnet with our new peer and created a separate route object for it in RIPE

Might this prevent other peers from seeing this network/ASN?

I can post router configs if necessary.

2

If your /22 route object specifies the ASN of your first peer, but not the additional peers, then anyone who’s strictly checking this would probably drop your prefix.

I’m not sure how you have your RR entries set up, but in general, I would think it’d be good to publish a policy that tells the broadest thing (i.e. all prefixes to all providers) but then if you choose to be more limited in your announcements, just filter them down to the level you need.

For my company, I basically published that my AS will accept ANY from each ISP, and that my AS will announce itself (the same ASN) to each ISP.

With this, plus my CIDR block being published with my AS as the origin, this should be good for pretty much any scenario I can come up with for advertising my address space.

3

I have already set import and export attributes in our RIPE AS entry to accept any routes from both peers and announce our AS by both peers.

I can’t see a way to specify peers in the /22 route object itself though.

4

You don’t - you list things as originating from your AS, and specify which ASes you export to.

Your routes can be “disappearing” because of the various carriers’ routing policies. (this is normal so long as you’re announcing this prefix to multiple peers)

Suppose you announce a prefix into AS100 and AS200. Suppose AS100 and AS200 are peering with each other as well. Other customers of AS200 won’t see routes for 200 → 100 → you, because AS200 will only show its favorite route to its eBGP peers. Suppose AS300 is connected to both AS100 and AS200, and for whatever reason, they prefer AS200. Customers of AS300 will only see 300 → 200 → You. They won’t see 300 → 100 → you. So any customers of 300 won’t see any routes you announce into 100, and that’s how the visibility can be less than 100%.

Now, if you’re only announcing prefix A to AS100 and prefix B to AS200 - then customers of 300 should see:
a/24 = 300 → 200 → 100 → you (remember that 300 prefers 200 over 100)
b/24 = 300 → 200 → you

See here that prefix a doesn’t disappear in as300 because 100 is the only way to reach prefix A.

Basically - are you announcing your final prefix only over the second peer, or are you sending it to both of your peers? If you’re sending to both, then this 55% is only an indication of how much of your traffic will go through that peer, and not how reachable it is. If you’re only sending this new prefix to that one peer, then you have something that needs more looking into.

5

Thanks. I’m actually annnouncing different networks through different peers, so router A is announcing 10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24 to Peer A, and router B is announcing 10.0.3.0/24 to Peer B.

Each network is created as a route object in the RIPE database.

It is this last network that is only being seen by 55% of peers globally. Does this look like a problem at Peer B?

6

I’ve seen this behavior in RIPE Stats when announcing new prefixes regardless of the route objects defined (which of course should be correctly defined anyway).

It turns out that my upstream’s upstream providers do some heavy filtering so I have to inform my upstream to inform them to update their filters or wait 2-3 days for the prefix to be 100% visible.
I guess their upstreams periodically check the route objects on RIPE and update their filters accordingly? (hence the 2-3 days delay).

Maybe you should contact your upstream to verify that your prefix is advertised on their upstreams.

Also you can make sure that your filters are correct (and you are advertising the prefixes you want over the peers you want) by checking Routing > BGP > Advertisements.