Re: TFTP over anycast

[Saku Ytti]

On Sat, 6 Apr 2024 at 12:00, Bill Woodcock  wrote:

> That’s been the normal way of doing it for some 35 years now.  iBGP 
> advertise, or don’t advertise, the service address, which is attached to the 
> loopback, depending whether you’re ready to service traffic.

If we are talking about eBGP, then pulling routes makes sense. If we
are talking about iBGP and controlled environment, you should never
pull anycast routes, because eventually you will have failure mode,
where the check mechanism itself is broken, and you'll pull all
routes.
If instead of pulling the routes, you make them inferior, you are
covered for the failure mode of check itself being broken.


-- 
  ++ytti

Re: 2600:: No longer pings

[Gaurav Kansal via NANOG]

2409:: is replying the ICMPv6 request, in case anyone interested 


> On 6 Apr 2024, at 15:31, nanog@nanog.org wrote:
> 
> It appears that 2600:: no longer responds to ICMP.
> 
> $ mtr -rwc 1 2600::
> Start: 2024-04-06T10:53:41+0100
> HOST: metropolis  Loss%
>  1.|-- lcy02.flat.b621.net  0.0%
> [...]
>  6.|-- ldn-b4-link.ip.twelve99.net  0.0%
>  7.|-- ldn-bb1-v6.ip.twelve99.net   0.0%
>  8.|-- nyk-bb2-v6.ip.twelve99.net   0.0%
>  9.|-- ??? 100.0
> 10.|-- sprint-ic301620-nyk-b5.ip.twelve99-cust.net  0.0%
> 11.|-- ??? 100.0
> 
> This seems to have happened around Friday 5th 13:40 UTC.
> 
> 2600::, a IP address owned by the Sprint network (Now since acquired
> by Cogent Communications) is a common (at least in my circles) IPv6
> testing address, in a similar way that 8.8.8.8 or 1.1.1.1 is for a
> quick address to remember that always pings, when such a address is so
> easy to remember, you sometimes cannot help it becoming a "core
> project" :) ( https://xkcd.com/1361/ )
> 
> 2600:: is also used to be the address of sprint.net, now sprint.net has no v6.
> 
> This is sad, and I would either propose that Cogent/Sprint (I assume
> 2600:: is under the ownership of Cogent now) revive this address as
> it's a very helpful testing address that is burned into the minds of
> many. Or at the very least, I'm more than willing to tank the effort
> of responding to ICMP!

Re: Netskrt - ISP-colo CDN

[Tim Burke]

I have been trying to get _away_ from caching appliances on our network — other 
than Google, we are able to pick up most of the stuff that otherwise would be 
cacheable via private peering; so it doesn’t make a whole lot of sense for us 
to have appliances in the datacenter taking up space, power, and 100G ports, 
and increasing potential attack surface by having devices that we cannot 
control directly connected to edge routers.

> On Apr 4, 2024, at 2:57 PM, Aaron Gould  wrote:
> 
> Anyone out there using Netskrt CDN?  I mean, installed in your network for 
> content delivery to your customers.  I understand Netskrt provides caching 
> for some well known online video streaming services... just wondering if 
> there are any network operators that have worked with Netskrt and deployed 
> their caching servers in your networks and what have you thought about it?  
> What Internet uplink savings are you seeing?
> 
> Netskrt - https://www.netskrt.io/
> 
> 
> -- 
> -Aaron
> 

Re: 2600:: No longer pings

[Stephane Bortzmeyer]

On Sat, Apr 06, 2024 at 06:19:57PM +0800,
 Soha Jin  wrote 
 a message of 50 lines which said:

> I don't know what happed to 2600::, but 2a09:: and 2a11:: can be
> used as alternatives. These are addresses of https://dns.sb/ running
> by xTom.

Very good DNS service, buy the way. But, although I undertsand the
point of having test IPv6 addresses which are easy to remember, this
is an opportunity to remind everybody that the pingability of these
addresses is not guaranteed.

Better to use machines which are intended for testing such as the RIPE
Atlas anchors .

RE: 2600:: No longer pings

[Soha Jin]

I don't know what happed to 2600::, but 2a09:: and 2a11:: can be used as
alternatives. These are addresses of https://dns.sb/ running by xTom.

> -Original Message-
> From: NANOG  On Behalf Of Ben
> Cartwright-Cox via NANOG
> Sent: Saturday, April 6, 2024 6:01 PM
> To: North American Network Operators' Group 
> Subject: 2600:: No longer pings
> 
> It appears that 2600:: no longer responds to ICMP.
> 
> $ mtr -rwc 1 2600::
> Start: 2024-04-06T10:53:41+0100
> HOST: metropolis  Loss%
>   1.|-- lcy02.flat.b621.net  0.0%
> [...]
>   6.|-- ldn-b4-link.ip.twelve99.net  0.0%
>   7.|-- ldn-bb1-v6.ip.twelve99.net   0.0%
>   8.|-- nyk-bb2-v6.ip.twelve99.net   0.0%
>   9.|-- ??? 100.0
>  10.|-- sprint-ic301620-nyk-b5.ip.twelve99-cust.net  0.0%
>  11.|-- ??? 100.0
> 
> This seems to have happened around Friday 5th 13:40 UTC.
> 
> 2600::, a IP address owned by the Sprint network (Now since acquired by Cogent
> Communications) is a common (at least in my circles) IPv6 testing address, in 
> a
> similar way that 8.8.8.8 or 1.1.1.1 is for a quick address to remember that 
> always
> pings, when such a address is so easy to remember, you sometimes cannot help 
> it
> becoming a "core project" :) ( https://xkcd.com/1361/ )
> 
> 2600:: is also used to be the address of sprint.net, now sprint.net has no v6.
> 
> This is sad, and I would either propose that Cogent/Sprint (I assume
> 2600:: is under the ownership of Cogent now) revive this address as it's a 
> very
> helpful testing address that is burned into the minds of many. Or at the very 
> least,
> I'm more than willing to tank the effort of responding to ICMP!

2600:: No longer pings

[Ben Cartwright-Cox via NANOG]

It appears that 2600:: no longer responds to ICMP.

$ mtr -rwc 1 2600::
Start: 2024-04-06T10:53:41+0100
HOST: metropolis  Loss%
  1.|-- lcy02.flat.b621.net  0.0%
[...]
  6.|-- ldn-b4-link.ip.twelve99.net  0.0%
  7.|-- ldn-bb1-v6.ip.twelve99.net   0.0%
  8.|-- nyk-bb2-v6.ip.twelve99.net   0.0%
  9.|-- ??? 100.0
 10.|-- sprint-ic301620-nyk-b5.ip.twelve99-cust.net  0.0%
 11.|-- ??? 100.0

This seems to have happened around Friday 5th 13:40 UTC.

2600::, a IP address owned by the Sprint network (Now since acquired
by Cogent Communications) is a common (at least in my circles) IPv6
testing address, in a similar way that 8.8.8.8 or 1.1.1.1 is for a
quick address to remember that always pings, when such a address is so
easy to remember, you sometimes cannot help it becoming a "core
project" :) ( https://xkcd.com/1361/ )

2600:: is also used to be the address of sprint.net, now sprint.net has no v6.

This is sad, and I would either propose that Cogent/Sprint (I assume
2600:: is under the ownership of Cogent now) revive this address as
it's a very helpful testing address that is burned into the minds of
many. Or at the very least, I'm more than willing to tank the effort
of responding to ICMP!

Re: TFTP over anycast

[Bill Woodcock]

> On Apr 6, 2024, at 10:30, Ray Bellis  wrote:
> On 27/02/2024 18:47, William Herrin wrote:
>> Then I'd write a script to monitor the local tftp server and stop frr if it 
>> detects any problems with the tftp server.
> There are other ways to achieve this without actually stopping the routing 
> daemon.
> We have DNS servers where the anycast service address is added to a loopback 
> interface (lo1) and only advertised when present.

That’s been the normal way of doing it for some 35 years now.  iBGP advertise, 
or don’t advertise, the service address, which is attached to the loopback, 
depending whether you’re ready to service traffic.

-Bill

Re: TFTP over anycast

[Ray Bellis]

On 27/02/2024 18:47, William Herrin wrote:


Then I'd write a script to monitor the local tftp server and stop frr
if it detects any problems with the tftp server.
There are other ways to achieve this without actually stopping the 
routing daemon.


We have DNS servers where the anycast service address is added to a 
loopback interface (lo1) and only advertised when present.


The monitoring script drops and adds the service address to the 
loopback, without otherwise touching the routing daemon.  We use Bird 
rather than FRR, though.


Ray