Re: Vint Cerf & Interplanetary Internet

[C. A. Fillekes]

the subgroup for networks on aspherical planetoids would be EGGNOG -- we
only meet during the holiays

On Wed, Oct 21, 2020 at 11:59 PM Mark Andrews  wrote:

> It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.
>
> > On 22 Oct 2020, at 14:07, scott weeks  wrote:
> >
> >
> > *From:* NANOG  on behalf
> of Rod Beck 
> >>
> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
> > 
> >
> > On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
> >
> > Right. This means we are going to catch a spaceship for a future nanog /
> have
> > interplanetary governance federation debates with space aliens from
> Andromeda,
> > and we will finally run out of v6 and ipv9 will rule the roost while
> there’s a
> > substantial aftermarket + hijack scene going on for the last remaining
> v6 blocks.
> > 
> >
> >
> > More like IP to Nokia's new cell network on the moon:
> >
> >
> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
> > (Everyone on the moon will want to have access to LOL cats!)
> >
> > Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach
> Mars and other
> > planets by being relayed through communications relay satellites similar
> to the
> > Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
> > Reconnaissance Orbiter spacecraft.
> >
> > Or... IP to robots visiting other non-planet objects in the solar system
> like
> > comets/asteroids:
> > https://spacenews.com/osiris-rex-touches-down-on-asteroid
> > https://www.bbc.com/news/science-environment-47293317
> >
> > Or... 
> >
> > The IPI idea has been around for a long time now:
> > https://en.wikipedia.org/wiki/Interplanetary_Internet
> >
> > The main question is will NANOG On The Road meet on the moon?  I missed
> > the only Hawaii one, so maybe I could make the moon one!
> >
> > scott
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>

Re: Ingress filtering on transits, peers, and IX ports

[Brian Knight via NANOG]

Randy, thank you for the reminder to look also at what services (L4 
ports) should be generally blocked.


As I was implementing a similar rule for logging purposes, I discovered 
an oddity with $VENDOR_C_XR ACLs.  I created the following:


object-group port TCPUDP-BLOCKED
  eq 0
  eq sunrpc
  eq 445
  range 137 139
exit

ipv4 access-list IPV4-INET-IN
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log
[snip]

ipv4 access-list IPV4-INET-OUT
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log
[snip]

After I did this, logs on our syslog server started growing like crazy.  
It was full of entries like:


2020-10-21T01:47:17-05:00,info,RP/0/RSP1/CPU0:Oct 21 01:47:17.972 CDT: 
ipv4_acl_mgr[305]: %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list 
IPV4-INET-OUT (210) permit udp on.net.ip.adr(0) -> off.net.ip.adr(0), 5 
packets
2020-10-21T02:01:08-05:00,info,RP/0/RSP0/CPU0:Oct 21 02:01:08.490 CDT: 
ipv4_acl_mgr[263]: %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list 
IPV4-INET-IN (210) permit udp off.net.ip.adr(0) -> on.net.ip.adr(0), 58 
packets


After wondering why in the world my customers were sending so much data 
on port 0, I found a few different sources saying that port 0 is 
commonly used in place of valid information when dealing with fragments. 
 Turns out that $VENDOR_C_XR does this too.


It wasn't clear why fragments would be matching that rule until I found 
the right vendor doc.  The router will pass IP fragments with a "permit" 
ACL line as long as that fragment's layer 3 info matches the layer 3 
information in the ACL.  The router logs the packet similar the above: 
L4 protocol with source and dest port = 0.  From the doc:


-

For an access-list entry containing Layer 3 and Layer 4 information:
• The entry is applied to non-fragmented packets and initial fragments.
• If the entry matches and is a permit statement, the packet or
fragment is permitted.
• If the entry matches and is a deny statement, the packet or fragment
is denied.

The entry is also applied to non-initial fragments in the following
manner. Because non-initial fragments contain only Layer 3 information,
only the Layer 3 portion of an access-list entry can be applied. If the
Layer 3 portion of the access-list entry matches, and
• If the entry is a permit statement, the non-initial fragment is
permitted.
• If the entry is a deny statement, the next access-list entry is
processed.
The deny statements are handled differently for non-initial
fragments versus non-fragmented or initial fragments.

-

Since my rule's L3 info was permit any source to any destination, any IP 
fragment would match the rule, be passed, and be logged.  The solution 
was to add rules explicitly permitting fragments above the layer 4 
rules:


ipv4 access-list IPV4-INET-IN
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols PERMIT FOR NOW ***
  203 permit ipv4 net-group IPV4-CUST any fragments
  204 permit ipv4 net-group IPV4-BACKDOOR-HOSTS any fragments
  205 permit ipv4 any net-group IPV4-BGP-AGG fragments
  206 permit ipv4 any net-group IPV4-CUST fragments
  210 permit udp any port-group TCPUDP-BLOCKED any log
  211 permit udp any any port-group TCPUDP-BLOCKED log
  212 permit tcp any port-group TCPUDP-BLOCKED any log
  213 permit tcp any any port-group TCPUDP-BLOCKED log

Logs are a lot calmer now in terms of new lines per minute, and far more 
relevant.  When we switch those rules to deny statements, we can 
eliminate the rules specifically permitting fragments.


Looks like $VENDOR_J makes things so much simpler for this task.

Thanks,


-Brian


On 2020-10-20 00:18, Randy Bush wrote:

term blocked-ports {
from {
protocol [ tcp udp ];
first-fragment;
destination-port
	[ 0 sunrpc 135 netbios-ns netbios-dgm netbios-ssn 111 445 syslog 
11211];

}
then {
sample;
discard;
}
}

and i block all external access to weak devices such as switches, pdus,
ipmi, ...

randy

Re: Vint Cerf & Interplanetary Internet

[Rod Beck]

SPACOG. C'mon guys. Think Big!


From: NANOG  on behalf 
of Mark Andrews 
Sent: Thursday, October 22, 2020 5:56 AM
To: scott weeks 
Cc: nanog@nanog.org 
Subject: Re: Vint Cerf & Interplanetary Internet

It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.

> On 22 Oct 2020, at 14:07, scott weeks  wrote:
>
>
> *From:* NANOG  on behalf of Rod 
> Beck 
>> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
> 
>
> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
>
> Right. This means we are going to catch a spaceship for a future nanog / have
> interplanetary governance federation debates with space aliens from Andromeda,
> and we will finally run out of v6 and ipv9 will rule the roost while there’s a
> substantial aftermarket + hijack scene going on for the last remaining v6 
> blocks.
> 
>
>
> More like IP to Nokia's new cell network on the moon:
>
> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
> (Everyone on the moon will want to have access to LOL cats!)
>
> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars and 
> other
> planets by being relayed through communications relay satellites similar to 
> the
> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
> Reconnaissance Orbiter spacecraft.
>
> Or... IP to robots visiting other non-planet objects in the solar system like
> comets/asteroids:
> https://spacenews.com/osiris-rex-touches-down-on-asteroid
> https://www.bbc.com/news/science-environment-47293317
>
> Or... 
>
> The IPI idea has been around for a long time now:
> https://en.wikipedia.org/wiki/Interplanetary_Internet
>
> The main question is will NANOG On The Road meet on the moon?  I missed
> the only Hawaii one, so maybe I could make the moon one!
>
> scott

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Vint Cerf & Interplanetary Internet

[Suresh Ramasubramanian]

Perfect. Where do I sign up?

--srs

From: NANOG  on behalf of C. A. 
Fillekes 
Sent: Thursday, October 22, 2020 12:53 PM
To: Mark Andrews
Cc: NANOG mailing list
Subject: Re: Vint Cerf & Interplanetary Internet


the subgroup for networks on aspherical planetoids would be EGGNOG -- we only 
meet during the holiays

On Wed, Oct 21, 2020 at 11:59 PM Mark Andrews 
mailto:ma...@isc.org>> wrote:
It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.

> On 22 Oct 2020, at 14:07, scott weeks 
> mailto:sur...@mauigateway.com>> wrote:
>
>
> *From:* NANOG 
> mailto:gmail@nanog.org>> on 
> behalf of Rod Beck 
> mailto:rod.b...@unitedcablecompany.com>>
>> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
> 
>
> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
>
> Right. This means we are going to catch a spaceship for a future nanog / have
> interplanetary governance federation debates with space aliens from Andromeda,
> and we will finally run out of v6 and ipv9 will rule the roost while there’s a
> substantial aftermarket + hijack scene going on for the last remaining v6 
> blocks.
> 
>
>
> More like IP to Nokia's new cell network on the moon:
>
> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
> (Everyone on the moon will want to have access to LOL cats!)
>
> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars and 
> other
> planets by being relayed through communications relay satellites similar to 
> the
> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
> Reconnaissance Orbiter spacecraft.
>
> Or... IP to robots visiting other non-planet objects in the solar system like
> comets/asteroids:
> https://spacenews.com/osiris-rex-touches-down-on-asteroid
> https://www.bbc.com/news/science-environment-47293317
>
> Or... 
>
> The IPI idea has been around for a long time now:
> https://en.wikipedia.org/wiki/Interplanetary_Internet
>
> The main question is will NANOG On The Road meet on the moon?  I missed
> the only Hawaii one, so maybe I could make the moon one!
>
> scott

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: 
ma...@isc.org

Re: Vint Cerf & Interplanetary Internet

[J. Hellenthal via NANOG]

NASOG

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 21, 2020, at 22:59, Mark Andrews  wrote:
> 
> It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.
> 
>> On 22 Oct 2020, at 14:07, scott weeks  wrote:
>> 
>> 
>> *From:* NANOG  on behalf of Rod 
>> Beck 
>>> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
>> 
>> 
>> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
>> 
>> Right. This means we are going to catch a spaceship for a future nanog / have
>> interplanetary governance federation debates with space aliens from 
>> Andromeda,
>> and we will finally run out of v6 and ipv9 will rule the roost while there’s 
>> a
>> substantial aftermarket + hijack scene going on for the last remaining v6 
>> blocks.
>> 
>> 
>> 
>> More like IP to Nokia's new cell network on the moon:
>> 
>> https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
>> (Everyone on the moon will want to have access to LOL cats!)
>> 
>> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars 
>> and other
>> planets by being relayed through communications relay satellites similar to 
>> the
>> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
>> Reconnaissance Orbiter spacecraft.
>> 
>> Or... IP to robots visiting other non-planet objects in the solar system like
>> comets/asteroids:
>> https://spacenews.com/osiris-rex-touches-down-on-asteroid
>> https://www.bbc.com/news/science-environment-47293317
>> 
>> Or... 
>> 
>> The IPI idea has been around for a long time now:
>> https://en.wikipedia.org/wiki/Interplanetary_Internet
>> 
>> The main question is will NANOG On The Road meet on the moon?  I missed
>> the only Hawaii one, so maybe I could make the moon one!
>> 
>> scott
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Circuit ordering software

[Niels Bakker]

* orothsch...@gmail.com (Oliver Rothschild) [Wed 21 Oct 2020, 22:39 CEST]:
For those that have circuit ordering mechanisms in their 
environment, what sort of software do you use?


If you're on the implementing side, you may want to take a look at 
https://ix-api.net/ to see how the three largest IXPs in Europe have 
done this.



-- Niels.

Re: Circuit ordering software

[David Funderburk]

This is excellent! I had not seen it before. Thanks for sharing.

---
Regards,

David Funderburk
GlobalVision
864-569-0703 

On 2020/10/22 08:06, Niels Bakker wrote:

> * orothsch...@gmail.com (Oliver Rothschild) [Wed 21 Oct 2020, 22:39 CEST]: 
> 
>> For those that have circuit ordering mechanisms in their environment, what 
>> sort of software do you use?
> 
> If you're on the implementing side, you may want to take a look at 
> https://ix-api.net/ to see how the three largest IXPs in Europe have done 
> this.
> 
> -- Niels.

Re: cheap MPLS router recommendations

[Baldur Norddahl]

Does this device have deep buffers?

On Wed, Oct 21, 2020 at 11:12 PM Colton Conor 
wrote:

> https://www.multicominc.com/wp-content/uploads/DZS-M3000_M.pdf
>
> On Wed, Oct 21, 2020 at 4:08 PM Colton Conor 
> wrote:
>
>> Well then Adam I would say the Dasan Zhone fits the budget. The M3000
>> seems like a real beast for the price point with 100G ports.
>>
>> Yes, other whitebox vendors are doing this, but they seem to want 2-4k
>> for the whitebox, and even more for the operating system, making it more
>> expensive that Juniper from what I have seen.
>>
>> On Wed, Oct 21, 2020 at 3:27 PM  wrote:
>>
>>> Just to clarify what cheap means, ideally  -$2000 to $4000 new
>>>
>>> -new is preferred as buying used kit on second hand market one is at the
>>> mercy of the price fluctuations and availability.
>>>
>>>
>>>
>>> And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately
>>> there are no details on the webpage (and the datasheet can’t be downloaded…
>>> )
>>>
>>>
>>>
>>> Are there more folks out there bundling open NOS and white-box HW along
>>> with the support for the whole thing?
>>>
>>>
>>>
>>>
>>>
>>> adam
>>>
>>>
>>>
>>> *From:* NANOG  *On
>>> Behalf Of *Colton Conor
>>> *Sent:* Monday, October 19, 2020 4:51 PM
>>> *To:* t...@pelican.org
>>> *Cc:* NANOG 
>>> *Subject:* Re: cheap MPLS router recommendations
>>>
>>>
>>>
>>> I haven't tried one myself, but Dasan Zhone has the M2400 and M3000.
>>> Basically, a whitebox with IP Infusion code on it. New, I think the price
>>> point is sub $2000 to $4000 new. That's a ton of ports for that price
>>> point. Anyone tried these yet?
>>> https://dzsi.com/product-category/mobile-xhaul/
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 19, 2020 at 3:38 AM t...@pelican.org  wrote:
>>>
>>> On Saturday, 17 October, 2020 00:41, "Tony Wicks" 
>>> said:
>>>
>>> > Well, there is always the MX104 (if you want redundancy) or MX80 if you
>>> > don’t. That will give you 80gig wire speed just don’t load it up with
>>> > more than one full table.
>>>
>>> Bear in mind that the MX80 is now in the EoL process, you have <4 years
>>> of support left.  Depending on your expected life-time / depreciation
>>> rules, buying one new right now might be unwise.
>>>
>>> Do *not* throw a full table at it (or any of the PowerPC Junipers)
>>> unless you have a lot of patience for reconvergence, and black-holes while
>>> you wait.
>>>
>>> MX104 is a nice box for getting dual-RE in something relatively compact
>>> and cheap, and has environmental hardening if that matters to you, but is
>>> still not best pleased with full tables.
>>>
>>> OP could do with clarifying "cheap" :)
>>>
>>> Regards,
>>> Tim.
>>>
>>>

Final day of ARIN 46 to be held tomorrow Friday 23 October!

[John Curran]

NANOGers -

ARIN 46’s third and final day will occur tomorrow, and consists of our member 
meeting including our Board and ARIN AC candidate forums and reports on how the 
organization is doing.

Please feel free to join if you are interested - it’s open to all and there’s 
no fee involved (but you do need to register - see details in the message 
below.)

Best wishes!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] Don’t Forget to Attend the Third and Final Day of ARIN 
46
Date: 20 October 2020 at 9:59:52 AM EDT
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

In just a few days, we will reconvene for the third and final day of ARIN 46. 
Join us from 12:00 – 3:00 PM ET on Friday, 23 October for the ARIN 46 Members 
Meeting, where we’ll discuss the 2020 ARIN Elections and hear from the 
candidates themselves during the Advisory Council and Board Forums. We’ll also 
hear updates on ARIN financials, the Board of Trustees, and the Advisory 
Council.

Candidate videos will be published on 22 October, so stay tuned and make sure 
to watch for those! Videos will be available at:

https://www.arin.net/elections

As you know, ARIN 46 is being held via Zoom. For more details about attending 
this virtual meeting, visit:

https://www.arin.net/ARIN46_remote

One hour before the meeting starts each day, registered attendees will receive 
an email from “ARIN no-re...@zoom.us“ with the URL for 
that day’s session. These links are not identical, so be sure you use the 
correct one for each day.

Although we try to stay on schedule as much as we can, note that all times are 
subject to change. View the ARIN 46 agenda and check for updates and any time 
changes at:

https://www.arin.net/ARIN46_agenda

Slides from each session will be posted online at:

https://www.arin.net/ARIN46_materials

Join in the conversation about ARIN 46 by using #ARIN46:

https://twitter.com/hashtag/ARIN46

Please give us feedback on your experience at ARIN 46 by completing the meeting 
survey at:

https://www.surveymonkey.com/r/ARIN46participantsurvey

All entries received by Friday, 30 October will be entered into a raffle to win 
an iPad Air!

Regards,

American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: Vint Cerf & Interplanetary Internet

[Alain Hebert]

    This will deprecated RFC1149, 2549 and 6214 :(

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 2020-10-22 03:20, C. A. Fillekes wrote:


the subgroup for networks on aspherical planetoids would be EGGNOG -- 
we only meet during the holiays


On Wed, Oct 21, 2020 at 11:59 PM Mark Andrews > wrote:


It wouldn’t be NANOG. Perhaps LUNOG or MOONOG.

> On 22 Oct 2020, at 14:07, scott weeks mailto:sur...@mauigateway.com>> wrote:
>
>
> *From:* NANOG mailto:gmail@nanog.org>> on behalf of Rod Beck
mailto:rod.b...@unitedcablecompany.com>>
>>

https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
> 
>
> On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
>
> Right. This means we are going to catch a spaceship for a future
nanog / have
> interplanetary governance federation debates with space aliens
from Andromeda,
> and we will finally run out of v6 and ipv9 will rule the roost
while there’s a
> substantial aftermarket + hijack scene going on for the last
remaining v6 blocks.
> 
>
>
> More like IP to Nokia's new cell network on the moon:
>
>

https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
> (Everyone on the moon will want to have access to LOL cats!)
>
> Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to
reach Mars and other
> planets by being relayed through communications relay satellites
similar to the
> Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
> Reconnaissance Orbiter spacecraft.
>
> Or... IP to robots visiting other non-planet objects in the
solar system like
> comets/asteroids:
> https://spacenews.com/osiris-rex-touches-down-on-asteroid
> https://www.bbc.com/news/science-environment-47293317
>
> Or... 
>
> The IPI idea has been around for a long time now:
> https://en.wikipedia.org/wiki/Interplanetary_Internet
>
> The main question is will NANOG On The Road meet on the moon?  I
missed
> the only Hawaii one, so maybe I could make the moon one!
>
> scott

-- 
Mark Andrews, ISC

1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org

Re: Vint Cerf & Interplanetary Internet

[John Levine]

In article <9ed99fde-19f1-96cc-1021-3420dc492...@mauigateway.com> you write:
>More like IP to Nokia's new cell network on the moon:

Ah, right.  There was news about that earlier this week:

https://www.theonion.com/nasa-builds-4g-tower-on-moon-tastefully-disguised-as-pi-1845414052

R's,
John

Re: Vint Cerf & Interplanetary Internet

[Bryan Holloway]

Don't mess with Belters ...

On 10/22/20 9:20 AM, C. A. Fillekes wrote:


the subgroup for networks on aspherical planetoids would be EGGNOG -- we 
only meet during the holiays


On Wed, Oct 21, 2020 at 11:59 PM Mark Andrews > wrote:


It wouldn’t be NANOG.  Perhaps LUNOG or MOONOG.

 > On 22 Oct 2020, at 14:07, scott weeks mailto:sur...@mauigateway.com>> wrote:
 >
 >
 > *From:* NANOG mailto:gmail@nanog.org>> on behalf of Rod Beck
mailto:rod.b...@unitedcablecompany.com>>
 >>

https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/
 > 
 >
 > On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote:
 >
 > Right. This means we are going to catch a spaceship for a future
nanog / have
 > interplanetary governance federation debates with space aliens
from Andromeda,
 > and we will finally run out of v6 and ipv9 will rule the roost
while there’s a
 > substantial aftermarket + hijack scene going on for the last
remaining v6 blocks.
 > 
 >
 >
 > More like IP to Nokia's new cell network on the moon:
 >
 >

https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface
 > (Everyone on the moon will want to have access to LOL cats!)
 >
 > Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to
reach Mars and other
 > planets by being relayed through communications relay satellites
similar to the
 > Mars Telecommunication Orbiter (canceled),  Mars Odyssey or Mars
 > Reconnaissance Orbiter spacecraft.
 >
 > Or... IP to robots visiting other non-planet objects in the solar
system like
 > comets/asteroids:
 > https://spacenews.com/osiris-rex-touches-down-on-asteroid
 > https://www.bbc.com/news/science-environment-47293317
 >
 > Or... 
 >
 > The IPI idea has been around for a long time now:
 > https://en.wikipedia.org/wiki/Interplanetary_Internet
 >
 > The main question is will NANOG On The Road meet on the moon?  I
missed
 > the only Hawaii one, so maybe I could make the moon one!
 >
 > scott

-- 
Mark Andrews, ISC

1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org

Re: AS203 (CenturyLink/Qwest/Level3/Lumen) hijack report

[Töma Gavrichenkov]

Peace,

On Thu, Oct 22, 2020 at 4:11 AM Töma Gavrichenkov  wrote:
> Following up on the today's massive partial network outage, here's the
> analysis of what actually happened with the AS203's hijack, which is
> the first one for the newly founded Lumen Technologies.
>
> https://blog.qrator.net/en/lumen-aka-centurylink-generating-routing-incidents_101/

And a follow-up with the incident report from Lumen:

--- cut ---
[PROBLEM OVERVIEW]
Customer reporting routing issues to a host on 3rd party network

[SUMMARY OF WORK]
Lumen is not responsible for routing issues on 3rd party network.
Reported prefix is learned from 35415 which appear to have had an
issue in their network

[REASON FOR CLOSURE]
no fault on Lumen

[ROOT CAUSE]
customer/ destination host network
--- cut ---

Looks like Lumen doesn't treat the absence of prefix filters as their fault...

--
Töma

QB server hiccups

[Paul Nash]

After an outage yesterday, I am trying to streamline and simplify the St Felix 
QB setup to make it more reliable and easier to administer.

The most critical factor that influences the overall design is the realistic 
maximum number of simultaneous users.

If we can live with a maximum of two users logged on at any one time, I can 
simplify the system dramatically, which will streamline operations and improve 
reliability.  

If we need to have more than two users logged at any time, then we need the 
current setup, with its various woes.  The problem are not insurmountable, but 
the system is more complex.  FWIW, a quick check looks like Shan has been the 
only active user for the past couple of months, but I may be wrong.

Either way, I need to overhaul some parts of the current setup, which was 
thrown together in an enormous rush.  Once I know what parts we are going to 
follow, I will make appropriate plans and let everyone know.

Yesterday’s problems were caused by the combination of Techsoup and Microsoft.  
Licenses that I ordered and paid for were not delivered correctly, leading to 
the QB server shutting down at an inopportune time.  After restoring the 
server, reverting to trial licenses, I spoke to MS tech support, who suggested 
that we start all over again purchasing the TS licenses.  They also suggested 
that we just buy them directly from MS at full retail price, which is not much 
more that the Techsoup price.

Right now, we should be good for a couple of months, but I want to prevent any 
similar issues in future, and even the regular jumping-through-hoops that I 
have been doing up until now to keen the current system running.

The first issue to resolving this and improving long-term reliability, is to 
decide how many simultaneous users we realistically need.  The rest will flow 
from that.

Regards

paul

Re: Vint Cerf & Interplanetary Internet

[Anne P. Mitchell, Esq.]

> On Oct 22, 2020, at 1:20 AM, C. A. Fillekes  wrote:
> 
> the subgroup for networks on aspherical planetoids would be EGGNOG -- we only 
> meet during the holidays



This should have come with a C&C warning! 

Anne

--
Anne P. Mitchell,  Cartoony at Large
CEO, SuretyMail Email Reputation Certification
Dean of Cyberlaw & Cybersecurity, Lincoln Law School
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative and Legal Consultant
Board of Directors, Denver Internet Exchange
Chair Emeritus, Asilomar Microcomputer Workshop
Former Counsel: Mail Abuse Prevention System (MAPS)
Location: Boulder, Colorado

Amazon Prime Video Contact?

[Ryan Gard]

Hello,

I'm looking to catch someone off list who could look into some issues we're
noticing since yesterday evening with some of our residential IP blocks
being marked as a VPN or Proxying service.

Unfortunately, our old contact for this may no longer be with the company.

Alternatively, if anybody has dealt with this more recently and has had
success in resolving this issue quickly, I'm all ears!

Regards,

-- 
Ryan Gard

APOLOGIES: QB server hiccups

[Paul Nash]

Autocorrect changed a misspelled recipient to “nanog”.

paul (grovelling for forgiveness)

Re: Amazon Prime Video Contact?

[Mike Hammett]

http://thebrotherswisp.com/index.php/geo-and-vpn/ 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Ryan Gard"  
To: "NANOG list"  
Sent: Thursday, October 22, 2020 1:02:36 PM 
Subject: Amazon Prime Video Contact? 


Hello, 


I'm looking to catch someone off list who could look into some issues we're 
noticing since yesterday evening with some of our residential IP blocks being 
marked as a VPN or Proxying service. 


Unfortunately, our old contact for this may no longer be with the company. 


Alternatively, if anybody has dealt with this more recently and has had success 
in resolving this issue quickly, I'm all ears! 


Regards, 


-- 

Ryan Gard 

PLEASE CHECK THE REPLY EMAIL ADDRESS -- Re: QB server hiccups

[Paul Nash]

Typo in the first version copied this to a mailing list.

I sent a newer version shortly after copied to Brian instead :-)

Please delete the earlier one & only reply to the later one.

Thanks

paul

> On Oct 22, 2020, at 1:19 PM, Paul Nash  wrote:
> 
> After an outage yesterday, I am trying to streamline and simplify the St 
> Felix QB setup to make it more reliable and easier to administer.
> 
> The most critical factor that influences the overall design is the realistic 
> maximum number of simultaneous users.
> 
> If we can live with a maximum of two users logged on at any one time, I can 
> simplify the system dramatically, which will streamline operations and 
> improve reliability.  
> 
> If we need to have more than two users logged at any time, then we need the 
> current setup, with its various woes.  The problem are not insurmountable, 
> but the system is more complex.  FWIW, a quick check looks like Shan has been 
> the only active user for the past couple of months, but I may be wrong.
> 
> Either way, I need to overhaul some parts of the current setup, which was 
> thrown together in an enormous rush.  Once I know what parts we are going to 
> follow, I will make appropriate plans and let everyone know.
> 
> Yesterday’s problems were caused by the combination of Techsoup and 
> Microsoft.  Licenses that I ordered and paid for were not delivered 
> correctly, leading to the QB server shutting down at an inopportune time.  
> After restoring the server, reverting to trial licenses, I spoke to MS tech 
> support, who suggested that we start all over again purchasing the TS 
> licenses.  They also suggested that we just buy them directly from MS at full 
> retail price, which is not much more that the Techsoup price.
> 
> Right now, we should be good for a couple of months, but I want to prevent 
> any similar issues in future, and even the regular jumping-through-hoops that 
> I have been doing up until now to keen the current system running.
> 
> The first issue to resolving this and improving long-term reliability, is to 
> decide how many simultaneous users we realistically need.  The rest will flow 
> from that.
> 
> Regards
> 
>   paul

RE: Linux router network cards

[micah anderson]

Thanks for the reply.

Philip Loenneker  writes:
> Take a look at the Mellanox ConnectX 5 series of cards. They handle
> DPDK, PVRDMA (basically SR-IOV that allows live migration between
> hosts), and can even process packets within the NIC for some

>From what I can tell, SR-IOV/PVRDMA aren't really useful for me in
building a router that wont be doing any virtualization.

If the card can do DPDK, can it do XDP?

> The slidedeck for the presentation is here:
> https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/1.9_Rhod_Brown_AusNOG2019.pdf
>
> It's heavily targeting virtualised workloads but some of the feature sets 
> apply to bare-metal uses too.

Yeah, this wont be a virtualized environment, just a router passing
packets, dropping them, handling bgp and collecting flows.

-- 
micah

RE: Linux router network cards

[Jean St-Laurent via NANOG]

Chelsio cards are probably what you are looking for.

https://www.chelsio.com/terminator-6-asic/

It's closer to an asic than a traditional nic as the router/firewall rules
are pushed directly into the hardware.

I don't know how good they are with linux and they seem to be compatible.
https://www.chelsio.com/linux/

You will need to mess around a bit and fiddle here and there. If you don't
mind using FreeBSD instead of linux, you could achieve a smoother and more
integrated experience.

Jean

-Original Message-
From: NANOG  On Behalf Of micah
anderson
Sent: Thursday, October 22, 2020 5:31 PM
To: Philip Loenneker ; NANOG

Subject: RE: Linux router network cards


Thanks for the reply.

Philip Loenneker  writes:
> Take a look at the Mellanox ConnectX 5 series of cards. They handle 
> DPDK, PVRDMA (basically SR-IOV that allows live migration between 
> hosts), and can even process packets within the NIC for some

>From what I can tell, SR-IOV/PVRDMA aren't really useful for me in building
a router that wont be doing any virtualization.

If the card can do DPDK, can it do XDP?

> The slidedeck for the presentation is here:
> https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/1
> .9_Rhod_Brown_AusNOG2019.pdf
>
> It's heavily targeting virtualised workloads but some of the feature sets
apply to bare-metal uses too.

Yeah, this wont be a virtualized environment, just a router passing packets,
dropping them, handling bgp and collecting flows.

-- 
micah

Re: Linux router network cards

[Jared Geiger]

I use DANOS with Intel XL710 10G NICs in DPDK mode for linux based routing.

If you're doing routing protocols, allocate 2 CPU cores to the control
plane and then a CPU core per 10G/1G interface for the dataplane, plus an
extra core for good measure. So for a 4 x 10G router taking in full routes,
2 cores for control plane, 5 cores for the dataplane. Those cores should be
Intel Xeon E5-2600v3/4 or newer and faster the clocks, the better.

Similar CPU core allocations if you choose TNSR.

On Thu, Oct 22, 2020 at 3:21 PM Jean St-Laurent via NANOG 
wrote:

> Chelsio cards are probably what you are looking for.
>
> https://www.chelsio.com/terminator-6-asic/
>
> It's closer to an asic than a traditional nic as the router/firewall rules
> are pushed directly into the hardware.
>
> I don't know how good they are with linux and they seem to be compatible.
> https://www.chelsio.com/linux/
>
> You will need to mess around a bit and fiddle here and there. If you don't
> mind using FreeBSD instead of linux, you could achieve a smoother and more
> integrated experience.
>
> Jean
>
> -Original Message-
> From: NANOG  On Behalf Of micah
> anderson
> Sent: Thursday, October 22, 2020 5:31 PM
> To: Philip Loenneker ; NANOG
> 
> Subject: RE: Linux router network cards
>
>
> Thanks for the reply.
>
> Philip Loenneker  writes:
> > Take a look at the Mellanox ConnectX 5 series of cards. They handle
> > DPDK, PVRDMA (basically SR-IOV that allows live migration between
> > hosts), and can even process packets within the NIC for some
>
> From what I can tell, SR-IOV/PVRDMA aren't really useful for me in building
> a router that wont be doing any virtualization.
>
> If the card can do DPDK, can it do XDP?
>
> > The slidedeck for the presentation is here:
> > https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/1
> > .9_Rhod_Brown_AusNOG2019.pdf
> >
> > It's heavily targeting virtualised workloads but some of the feature sets
> apply to bare-metal uses too.
>
> Yeah, this wont be a virtualized environment, just a router passing
> packets,
> dropping them, handling bgp and collecting flows.
>
> --
> micah
>
>