New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
RELIABLESITE ANNOUNCE OUR /24 RANGE WITHOUT OUR AUTHORIZATION
This discussion has been closed.
Comments
The range is announced by our AS63025
But that has nothing todo with reliablesite.
As BGP tools shows very clearly, the route is currently not in the DFZ.
Nobody is really advertising the prefix right now. Not a single tier 1 provider knows this prefix exist in the first place.
If you want to use it, you need to sort this out with your new upstream in your new location.
The range began to be announced by berohost with SYNLINQ. The problem was that at that time the AS of reliablesite appeared, which was published and I want to know why its AS has to appear. They clearly announced the range without any authorization from us.
Your range is not announced by anybody:
If it's not currently propagating in your new location, it has nothing to do with ReliableSite....
.
They're clearly not advertising the range, see my message above. The /24 is not in the global routing table. You're publicly flaming ReliableSite for Berohost's issue.
JFCI why does providers here do deals/suport in LET PMs?
Aren't you guys even scared that one day someone will exploit Vanilla (uhmmm one day
) and gain access to all your PMs, deals, access data and [for example] post them online?
ReliableSite announced the network. Thanks to RPKI
I can't tell you why this route showed up at some point.
But it looks like reliablesite is currently not advertising this prefix to anyone. AS4230 is the only network that knows about this. It really just looks like a stuck route, which just happens from time to time. Feel free to send their noc a mail. But don't expect a answer within 10 minutes.
If you are more interested in the topic I would recommend giving this a read:
https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window
This is your prefix, as you can see bgp.tools sees ONLY 7 ROUTES. Which practically means, its dead/offline.
For comparison a prefix of mine, bgp.tools sees 2279 routes.
If you recently added the prefix to BeoHost, it’s possible that they or their upstream providers just need some time to update their filters before your prefix comes through.
You can either reach out to them to confirm everything is in order or simply wait for the filters to be updated.
This is just two ISPs in that list not implementing RPKI filtering. Most ISPs including T1's are not accepting the RS route.
OVH don’t do RPKI filtering?
Maybe, frankly I'm not sure. it's possible they do and forgot some sessions... but there's a list of some popular ones you can shame here: https://isbgpsafeyet.com/
We have been announcing the subnet for a short time and are currently waiting for the filters of our upstreams to be updated. We have already communicated this to @nohavps.
We have also pointed out to @nohavps that the network is still announced by AS23470, even if this should have no impact with RPKI.
However, I think this discussion is going nowhere and should be continued via DM.
doubt it kinda. I've seen this exact thing with OVH many times in the past (alongside netactuate every time, per the ping.pe screenshot.)
@ReliableSiteHosting @nohavps
I see it on both. bgp.he.net and bgp.tools as
IMO this, as well as the unreasonable "open an account and send a ticket" response by RS make them look bad.
If you are made aware of a problem you caused or are involved in, you don't play formal games but rather solve it.
It would be an alias of the Drama category.
The "AS name" column of mtr (including ping.pe) is the result of WHOIS lookup.
It does not prove the identified ASN is announcing the target prefix.
Given you see a response from the target prefix, it means the target prefix must be announced by someone.
It could be either ReliableSite or BeroHost, or even someone else.
I love yasuni
I don't think RS saying "open a ticket" is unreasonable... but he could've also emailed the NOC address and I'm guessing that would've opened a ticket to their NOC automatically which their network engineers would've seen and handled.
"Host Battles"
We would just like @ReliableSiteHosting to at least respond to us because @MrRadic is only in sales and so far he hasn't responded to us on the ticket.
First, we sent a ticket to @MrRadic , which is supposedly sales-only.
Then we sent a message to @ReliableSiteHosting and received no response.
Then we went to their website via chat and received no response. They'll just review it. A ticket was sent, and so far, we haven't received any response.
That's why we opened a post here LET.
WE ALSO SEND AN EMAIL
15:26: Ticket opened.
...
15:44: System Admin response saying they'd investigate it.
I'd say that's good response time frankly. You're making the assumption that it's a one-click for them.
I'm not saying RS is doing great at communicating, but frankly you're not doing fantastic here yourself. Your new upstream won't have the prefix filter refreshed at least on DP until anytime tomorrow in CEST, Cogent is midnight GMT... you have time.
The schedule is not correct, it is the schedule where it is configured as the mail server, and the ticket server
That's the response we received via message on LET.
You can check the messages that were sent, first in LET, you have to see the assigned time, then the email, then the ticket.
@MrRadic can confirm if we have received a response to the ticket. So far, we have not received any.
you should start another work order
which doesn't necessarily mean a lot.
That doesn't change the fact that that range is @nohavps'.
Utterly irrelevant and their problem.
nohavps tried multiple ways of communication. And how long updates need to propagate/refresh is of secondary importance. RS made a mistake; that's human, not too uncommon, and forgivable. What's not forgivable at all though is reacting in between ignorantly and slowly.