On Mon, 8 Feb 2021, Justin Wilson (Lists) wrote:
Folks,
Have a gremlin we have been chasing around for several months now and it’s becoming a major issue as we are getting tighter on IPV4 and needing to give some provider assigned space back.
In June we received a /22 from ARIN. As is my workflow I started announcing it but waited a month while I checked out the geolocation databases for correct info, did testing ,etc. All this time our test accounts could browse web-sites, etc.
We put one of the pools into production and things ran good for awhile. Then we started getting the occasional web-site was not working. After several of these we started assigning the customer an IP out of one of our other ARIN blocks and the web-site would be fine and reachable. The issue seems to reside just on this /22. We have other blocks from ARIN and they are just fine. We can assign an IP out of this new block and can’t reach certain web-sites. We turn around and assign out of another block and web-site works just fine.
Been there, and done that back in 2003. https://web.archive.org/web/20030722022858/http://69box.atlantic.net/ https://web.archive.org/web/20060214055930/http://not69box.atlantic.net/ Unfortunately, I've moved on from that job and don't have any of the code that I developed for not69box/69box (and AFAIK, the box itself is long gone), but you can get an idea from the above page what I did. i.e. The two names resolved to an IP in 69.28.64/19 or an IP in 209.208/17. One of the cooler (at least at the time) features was a dual-frame traceroute that visitors could run and watch the box traceroute to a destination from a each of it's IP's, thus showing where in the path their traceroute broke, if it did, from the "69 space". ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________