RE: Twitter is down (What a shame)

[Ryan Hamel]

Twitter works for me on desktop and mobile.

 

From: NANOG  On Behalf Of ADNS NetBSD 
List Subscriber
Sent: Friday, April 16, 2021 5:23 PM
To: nanog@nanog.org
Subject: Twitter is down (What a shame)

 

Looks like backend is down – main page loads, no content.

 

Does this mean we return to a normal life?

Twitter is down (What a shame)

[ADNS NetBSD List Subscriber]

Looks like backend is down – main page loads, no content.

Does this mean we return to a normal life?

Re: BGP Graceful Restart

[Yang Yu]

On Fri, Apr 16, 2021 at 11:09 AM Graham Johnston
 wrote:
> Largely, I suspect that his point was that if you otherwise do the
> right things during maintenance that graceful-restart has the
> potential of being really problematic if things go wrong, and thus he
> was discouraging the use of it. Is there consensus as to whether
> graceful-restart has any place in a service provider network?

RFC4724 Graceful Restart is used to retain BGP routes where forwarding
plane is NOT disrupted. It can be useful for things that don't have
any alternative path to reduce exposure to control plane outages (e.g.
process restart).
Also sending End of Rib marker (not necessarily enabling GR) can be
helpful to troubleshoot BGP route collection (clear signal on
completion of initial convergence).

There is also LLGR https://tools.ietf.org/html/draft-ietf-idr-long-lived-gr-00

Re: OOB management options @ 60 Hudson & 1 Summer

[Patrick W. Gilmore]

On Apr 16, 2021, at 1:49 PM, Warren Kumari  wrote:
> On Fri, Apr 16, 2021 at 1:08 PM Bryan Fields  wrote:
>> On 4/16/21 1:33 AM, Saku Ytti wrote:
> > https://www.markleygroup.com/cloud/network/out-of-band
> 
> Wow, this is an impressive offering.  I wish more providers would do this.
> 
> +manylots. It's always surprising to me how often companies (in all 
> industries) can be broken up into those that understand the value of goodwill 
> and those that instead nickel-and-dime.
> My local Potbelly (sandwich ship) every now and then will just say "No 
> charge, this one's on us". This only happens around once every 30-40 times I 
> go in, but they loyalty that it has created means that I go there **way** 
> more often than I otherwise would. It also means that in the few times that 
> something goes wrong/I have a bad experience, I don't really care.
> 
> The additional profit that they've made from having me as a loyal customer 
> more than covers the cost of 1 free sammich every N. 
> 
> In many ways Markley seems similar - they feel like they understand that some 
> things (like OOB) are annoying to deal with, and that the loyalty / goodwill 
> provided by being "nice" more than repays the cost of the service.

As the person who created that product for Markley, I can tell you that is 
precisely what we were thinking.

It cost us nearly nothing, made customers stickier, generated good will, and 
created a chance to talk to them about cloud offerings or similar. The only 
“catch” is you need a fiber xconn. The thinking was it was barely more than a 
copper xconn for POTS yet you get gigabit instead of dialup, or you would have 
used fiber to another ISP anyway.

Every serious colo has enough bandwidth that 2 Mbps won’t be noticed, competent 
network engineers (one hopes), and free switch ports (or can get them cheap). 
Why don’t they do this? Perhaps someone in finance feels it can be “monetized”. 
I feel the monetization lowers adoption and kills the other benefits Warren 
mentions above - which are worth a hell of a lot more than the paltry sum they 
would get from billing a few customers.

-- 
TTFN,
patrick

PS: The guest SSID at Markley has no captive portal. It was a problem for 
customers who wanted to have their equipment get on the wifi to download 
images, etc, so we took it off.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 17 Apr, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  856506
Prefixes after maximum aggregation (per Origin AS):  324269
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  406158
Total ASes present in the Internet Routing Table: 71094
Prefixes per ASN: 12.05
Origin-only ASes present in the Internet Routing Table:   61156
Origin ASes announcing only one prefix:   25289
Transit ASes present in the Internet Routing Table:9938
Transit-only ASes present in the Internet Routing Table:311
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  38
Max AS path prepend of ASN ( 37385)  33
Prefixes from unregistered ASNs in the Routing Table:  1009
Number of instances of unregistered ASNs:  1016
Number of 32-bit ASNs allocated by the RIRs:  35730
Number of 32-bit ASNs visible in the Routing Table:   29751
Prefixes from 32-bit ASNs in the Routing Table:  138298
Number of bogon 32-bit ASNs visible in the Routing Table:22
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:522
Number of addresses announced to Internet:   2948654208
Equivalent to 175 /8s, 192 /16s and 228 /24s
Percentage of available address space announced:   79.6
Percentage of allocated address space announced:   79.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  290756

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   226747
Total APNIC prefixes after maximum aggregation:   65533
APNIC Deaggregation factor:3.46
Prefixes being announced from the APNIC address blocks:  222874
Unique aggregates announced from the APNIC address blocks:89504
APNIC Region origin ASes present in the Internet Routing Table:   11485
APNIC Prefixes per ASN:   19.41
APNIC Region origin ASes announcing only one prefix:   3285
APNIC Region transit ASes present in the Internet Routing Table:   1637
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 30
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6646
Number of APNIC addresses announced to Internet:  771967232
Equivalent to 46 /8s, 3 /16s and 73 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-143673
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:245811
Total ARIN prefixes after maximum aggregation:   112965
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   246236
Unique aggregates announced from the ARIN address blocks:117767
ARIN Region origin ASes present in the Internet Routing Table:18794
ARIN Prefixes per ASN:13.10
ARIN 

Re: OOB management options @ 60 Hudson & 1 Summer

[Warren Kumari]

On Fri, Apr 16, 2021 at 1:08 PM Bryan Fields  wrote:

> On 4/16/21 1:33 AM, Saku Ytti wrote:
> > https://www.markleygroup.com/cloud/network/out-of-band
>
> Wow, this is an impressive offering.  I wish more providers would do this.
>

+manylots. It's always surprising to me how often companies (in all
industries) can be broken up into those that understand the value of
goodwill and those that instead nickel-and-dime.
My local Potbelly (sandwich ship) every now and then will just say "No
charge, this one's on us". This only happens around once every 30-40 times
I go in, but they loyalty that it has created means that I go there **way**
more often than I otherwise would. It also means that in the few times that
something goes wrong/I have a bad experience, I don't really care.

The additional profit that they've made from having me as a loyal customer
more than covers the cost of 1 free sammich every N.

In many ways Markley seems similar - they feel like they understand that
some things (like OOB) are annoying to deal with, and that the loyalty /
goodwill provided by being "nice" more than repays the cost of the service.
W




> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

Using RESTful interfaces to ARIN's IRR (Fwd: [arin-announce] New Webinar Registration Now Open: Using ARIN's RESTful API for IRR)

[John Curran]

NANOGers -

FYI - For those operators who want to automate IRR updates with ARIN, please 
see the following upcoming webinar on using our RESTful API, the Operational 
Test and Evaluation (OTE) environment, and more.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] New Webinar Registration Now Open: Using ARIN's 
RESTful API for IRR
Date: 16 April 2021 at 1:26:22 PM EDT
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

Do you need to manage multiple Internet Routing Registry (IRR) records quickly? 
If so, you can set up your system to connect to our IRR database using the 
Representational State Transfer (RESTful) application programming interface 
(API). Our API lets you create, update, and delete multiple objects without 
having to log in to the web interface and perform each task individually. Join 
us to learn how to format IRR REST commands to communicate with ARIN’s database 
using the API.

You’ll learn the following skills at this webinar:

- Accessing the Operational Test and Evaluation Environment (OT)
- Creating, viewing, updating, and deleting an object using a REST call
- Identifying necessary commands and URL structure
- Describing, sending, and formatting payloads, which are sent in Routing 
Policy Specification Language (RPSL)

This webinar will be held twice – once on Tuesday, 27 April, and again on 
Tuesday, 4 May, both at 2:00 - 3:00 PM ET. Simply select which date you’d like 
to attend when filling out the registration form.

Registration is completely free but space is limited, so register soon:

https://arin.swoogo.com/IRRAPI

We hope to see you there! Contact us at train...@arin.net with any questions.

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: OOB management options @ 60 Hudson & 1 Summer

[Bryan Fields]

On 4/16/21 1:33 AM, Saku Ytti wrote:
> https://www.markleygroup.com/cloud/network/out-of-band

Wow, this is an impressive offering.  I wish more providers would do this.
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: [EXTERNAL_MESSAGE] RE: OOB management options @ 60 Hudson & 1 Summer

[Warren Kumari]

On Fri, Apr 16, 2021 at 12:20 PM Mike McGurty  wrote:

> I believe we were recently quoted a price of like $900/month (between
> cross-connect and monthly charge) for 10Mb OpenGear OOB access in a large
> Canadian Data Center.  We passed.  While I don’t disagree, you have to pay
> for these services.  The cost far exceeds the value for what is provided in
> many cases.
>

I have often been pleasantly surprised by how often I can open a laptop in
a colo, see a list of SSIDs, figure out from the name who runs it, and ask
nicely if I can please attach an AP(/station) and OOB widget to their
network. I've basically always got the response of "Sure, as long as you
are only using it for OOB and don't try route traffic over it, no
worries". Often the reply also includes a "... and, could we do the
same? You stand up an AP and we'll tunnel OOB through it".

Yes, many colo's frown upon/"ban" Wifi, but what they don't notice doesn't
hurt them... The Internet used to be built on people helping each other out
- let's see if we can recreate that

W



>
>
> Michael
>
>
>
> *From: *NANOG  on behalf of "
> jstal...@ieee.org" 
> *Date: *Friday, April 16, 2021 at 12:03 PM
> *To: *'Matthew Crocker' , 'NANOG' <
> nanog@nanog.org>
> *Subject: *[EXTERNAL_MESSAGE] RE: OOB management options @ 60 Hudson & 1
> Summer
>
>
>
>
>
> Ha! “Surprised”? Well, offering OOB for a reasonable price could be a
> differentiator for the savvy colo providers, but bean counters say: “Huh?
> If customer X wants OOB, they can pay ~$300/mo for a cross-connect”.
> ~$300/mo might seem an exaggeration, but not for some of us. Even ~$150/mo
> is ridiculous.
>
>
>
> If 4G-ish mobile service won’t work, expect to pay. ;-(
>
>
>
> -Joel
>
>
>
> *From:* NANOG  *On Behalf Of 
> *Matthew
> Crocker
> *Sent:* Thursday, April 15, 2021 3:15 PM
> *To:* NANOG 
> *Subject:* OOB management options @ 60 Hudson & 1 Summer
>
>
>
>
>
> I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some
> low cost bandwidth options for out of band management.  Currently I have
> Opengear boxes at each site with cell modems but they don’t work too well.
> I either need to replace them with new cell based devices or find a
> wireless/ethernet bandwidth option.   I only need a couple serial ports and
> ethernet for when everything breaks.
>
>
>
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>
>
>
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.
>
>
>
> Thanks
>
>
> --
>
> This electronic message contains information from American Eagle
> Outfitters, Inc. that may be privileged and/or confidential. If you are not
> the intended recipient, any disclosure, copy, distribution or use of the
> contents of this message is prohibited. If you have received this email in
> error, please contact the sender immediately and destroy this message.
> Thank you.
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

Re: BGP Graceful Restart

[Mel Beckman]

I use it BGP Graceful Restart in order to avoid route flapping penalties and 
undesired path selection when adding or removing prefixes on border routers 
(which entails ACL changes as well). However, when BGP is used as a data center 
fabric, I have heard it can cause complex failure modes lasting many minutes or 
even hours. I found this VMWare Validated Design Document 5.0.1 warning:

NSXT-VISDN-038 Do not enable Graceful Restart between BGP neighbors. Avoids 
loss of traffic. Graceful Restart maintains the forwarding table which in turn 
will forward packets to a down neighbor even after the BGP timers have expired 
causing loss of traffic

I don't run BGP as an east-west protocol, so I've never had cause to use this, 
but this might be one of the risks the speaker of the talk you heard was 
referring to.

 -mel


From: NANOG  on behalf of Graham 
Johnston 
Sent: Friday, April 16, 2021 7:11 AM
To: nanog@nanog.org 
Subject: BGP Graceful Restart

I do believe that I understand the intended purpose of BGP
graceful-restart. With that said, I was watching a video of a talk
given by someone respected in the industry the other day on the use of
graceful-shutdown and at the beginning of the talk there was a quick
disclaimer that his topic had nothing to do with graceful-restart
along with some text on the slide that provided me a clear indication
that he was not a fan of graceful-restart.

Largely, I suspect that his point was that if you otherwise do the
right things during maintenance that graceful-restart has the
potential of being really problematic if things go wrong, and thus he
was discouraging the use of it. Is there consensus as to whether
graceful-restart has any place in a service provider network?

Thanks,
Graham

Re: OOB management options @ 60 Hudson & 1 Summer

[Phil Lavin via NANOG]

> On 15 Apr 2021, at 23:29,   wrote:
> 
>  
> Ha! “Surprised”? Well, offering OOB for a reasonable price could be a 
> differentiator for the savvy colo providers, but bean counters say: “Huh? If 
> customer X wants OOB, they can pay ~$300/mo for a cross-connect”. ~$300/mo 
> might seem an exaggeration, but not for some of us. Even ~$150/mo is 
> ridiculous.

$300/month would be a bargain at One Summer

For what it’s worth, I really like Markley. Everybody that works there is 
fantastically helpful and they don’t cut corners on their infrastructure. Only 
gripe is X-Connect pricing

Re: [EXTERNAL_MESSAGE] RE: OOB management options @ 60 Hudson & 1 Summer

[Mike McGurty]

I believe we were recently quoted a price of like $900/month (between 
cross-connect and monthly charge) for 10Mb OpenGear OOB access in a large 
Canadian Data Center.  We passed.  While I don’t disagree, you have to pay for 
these services.  The cost far exceeds the value for what is provided in many 
cases.

Michael

From: NANOG  on behalf of 
"jstal...@ieee.org" 
Date: Friday, April 16, 2021 at 12:03 PM
To: 'Matthew Crocker' , 'NANOG' 
Subject: [EXTERNAL_MESSAGE] RE: OOB management options @ 60 Hudson & 1 Summer


Ha! “Surprised”? Well, offering OOB for a reasonable price could be a 
differentiator for the savvy colo providers, but bean counters say: “Huh? If 
customer X wants OOB, they can pay ~$300/mo for a cross-connect”. ~$300/mo 
might seem an exaggeration, but not for some of us. Even ~$150/mo is ridiculous.

If 4G-ish mobile service won’t work, expect to pay. ;-(

-Joel

From: NANOG  On Behalf Of Matthew 
Crocker
Sent: Thursday, April 15, 2021 3:15 PM
To: NANOG 
Subject: OOB management options @ 60 Hudson & 1 Summer


I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some low 
cost bandwidth options for out of band management.  Currently I have Opengear 
boxes at each site with cell modems but they don’t work too well.  I either 
need to replace them with new cell based devices or find a wireless/ethernet 
bandwidth option.   I only need a couple serial ports and ethernet for when 
everything breaks.

I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer

I’m surprised OOB bandwidth isn’t a feature for colocation providers.

Thanks



This electronic message contains information from American Eagle Outfitters, 
Inc. that may be privileged and/or confidential. If you are not the intended 
recipient, any disclosure, copy, distribution or use of the contents of this 
message is prohibited. If you have received this email in error, please contact 
the sender immediately and destroy this message. Thank you.

Re: OOB management options @ 60 Hudson & 1 Summer

[Shane Ronan]

Someone has been spending time at Equinix.

On Fri, Apr 16, 2021 at 12:01 PM  wrote:

>
>
> Ha! “Surprised”? Well, offering OOB for a reasonable price could be a
> differentiator for the savvy colo providers, but bean counters say: “Huh?
> If customer X wants OOB, they can pay ~$300/mo for a cross-connect”.
> ~$300/mo might seem an exaggeration, but not for some of us. Even ~$150/mo
> is ridiculous.
>
>
>
> If 4G-ish mobile service won’t work, expect to pay. ;-(
>
>
>
> -Joel
>
>
>
> *From:* NANOG  *On Behalf Of 
> *Matthew
> Crocker
> *Sent:* Thursday, April 15, 2021 3:15 PM
> *To:* NANOG 
> *Subject:* OOB management options @ 60 Hudson & 1 Summer
>
>
>
>
>
> I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some
> low cost bandwidth options for out of band management.  Currently I have
> Opengear boxes at each site with cell modems but they don’t work too well.
> I either need to replace them with new cell based devices or find a
> wireless/ethernet bandwidth option.   I only need a couple serial ports and
> ethernet for when everything breaks.
>
>
>
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>
>
>
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.
>
>
>
> Thanks
>
>
>

BGP Graceful Restart

[Graham Johnston]

I do believe that I understand the intended purpose of BGP
graceful-restart. With that said, I was watching a video of a talk
given by someone respected in the industry the other day on the use of
graceful-shutdown and at the beginning of the talk there was a quick
disclaimer that his topic had nothing to do with graceful-restart
along with some text on the slide that provided me a clear indication
that he was not a fan of graceful-restart.

Largely, I suspect that his point was that if you otherwise do the
right things during maintenance that graceful-restart has the
potential of being really problematic if things go wrong, and thus he
was discouraging the use of it. Is there consensus as to whether
graceful-restart has any place in a service provider network?

Thanks,
Graham

Re: OOB management options @ 60 Hudson & 1 Summer

[Phil Lavin via NANOG]

> On 15 Apr 2021, at 23:14, Matthew Crocker  wrote:
>  
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>  
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.

In --dayJob we were a customer of 1 Summer. OOB was provided by Markley in the 
form of a couple of L3 circuits on SMF with some static IPs. I don’t recall the 
exact commercial relationship as I wasn’t in the company at the time it was 
negotiated but it was effectively supplied free of charge with the rack space. 
Cross-connects at 1 Summer are so damn expensive it’s impractical to take a 
feed from anybody else. That said, if you’re in the MMR then you probably have 
a lot more flexibility.

In other DCs we tended to either sub-lease rack space from a colo provider, as 
they could provide a feed from their adjacent network racks for very little 
cost, or we found a friendly network in the same suite to either take a cheap 
feed from or swap bandwidth with.

LTE reception in the majority of DCs is awful so I was never willing to trust 
it to work when needed.

RE: OOB management options @ 60 Hudson & 1 Summer

[jstalder]

 

Ha! "Surprised"? Well, offering OOB for a reasonable price could be a
differentiator for the savvy colo providers, but bean counters say: "Huh? If
customer X wants OOB, they can pay ~$300/mo for a cross-connect". ~$300/mo
might seem an exaggeration, but not for some of us. Even ~$150/mo is
ridiculous.

 

If 4G-ish mobile service won't work, expect to pay. ;-(

 

-Joel

 

From: NANOG  On Behalf Of Matthew
Crocker
Sent: Thursday, April 15, 2021 3:15 PM
To: NANOG 
Subject: OOB management options @ 60 Hudson & 1 Summer

 

 

I have routers in both 60 Hudson St & 1 Summer St and I'm looking for some
low cost bandwidth options for out of band management.  Currently I have
Opengear boxes at each site with cell modems but they don't work too well.
I either need to replace them with new cell based devices or find a
wireless/ethernet bandwidth option.   I only need a couple serial ports and
ethernet for when everything breaks.

 

I'm in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer

 

I'm surprised OOB bandwidth isn't a feature for colocation providers.

 

Thanks

 

Re: OOB management options @ 60 Hudson & 1 Summer

[Matthew Crocker]

Geez,  I’ve been at 1 Summer for 6+ years, never new they offered this.  I’ll 
have to check it out

Thanks

-Matt


From: Saku Ytti 
Date: Friday, April 16, 2021 at 1:34 AM
To: Matthew Crocker 
Cc: NANOG 
Subject: Re: OOB management options @ 60 Hudson & 1 Summer
CAUTION: This email originated from outside of Crocker. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.



On Fri, 16 Apr 2021 at 01:18, Matthew Crocker 
mailto:matt...@corp.crocker.com>> wrote:

I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some low 
cost bandwidth options for out of band management.  Currently

I’m surprised OOB bandwidth isn’t a feature for colocation providers.

That would surprise me too.

https://www.digitalrealty.com/connectivity/ip-bandwidth
https://www.markleygroup.com/cloud/network/out-of-band

--
  ++ytti

Re: OOB management options @ 60 Hudson & 1 Summer

[Dovid Bender]

We use Raritan console devices in NJR2 and I couldn't be happier. They
allow you to have to connections. We have a VPN device that is connected to
our wan switches and then we have Verizon LTE as a backup. When we first
went with T-Mobile we had problems with the connectivity (see
https://mailman.nanog.org/pipermail/nanog/2019-January/098723.html). We
then moved over to Verizon where the signal was strong but we had issues
with the MTU issues (see
https://mailman.nanog.org/pipermail/nanog/2019-June/101576.html). I ended
up adding a rule to the raritan to lower the PDU and that allowed
connectivity via the cellular network. I used the cellular modem that
raritan recommended although I probably could have gone with something
cheaper like the MikroTik LtAP.



On Thu, Apr 15, 2021 at 6:14 PM Matthew Crocker 
wrote:

>
>
> I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some
> low cost bandwidth options for out of band management.  Currently I have
> Opengear boxes at each site with cell modems but they don’t work too well.
> I either need to replace them with new cell based devices or find a
> wireless/ethernet bandwidth option.   I only need a couple serial ports and
> ethernet for when everything breaks.
>
>
>
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>
>
>
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.
>
>
>
> Thanks
>
>
>

Re: FreeBSD-13 MOTD Gone

[Mark Tinka]

On 4/16/21 09:48, John Hay wrote:


Hi Mark,

There is now /etc/motd.template that is used to create /var/run/motd 
on startup.


Thanks.

Still doing the upgrade, so haven't had a chance to look under the hood.

Mark.

Re: FreeBSD-13 MOTD Gone

[John Hay]

Hi Mark,

There is now /etc/motd.template that is used to create /var/run/motd on
startup.

Regards

John


On Fri, 16 Apr 2021 at 09:14, Mark Tinka  wrote:

> ...380390400410420430440450460470480490
> Attempting to automatically merge changes in files... done.
>
> The following file will be removed, as it no longer exists in
> FreeBSD 13.0-RELEASE: /etc/motd
> Does this look reasonable (y/n)?
>
> Anybody know the back story?
>
> Mark.
>
>

FreeBSD-13 MOTD Gone

[Mark Tinka]

...380390400410420430440450460470480490 
Attempting to automatically merge changes in files... done. The 
following file will be removed, as it no longer exists in FreeBSD 
13.0-RELEASE: /etc/motd Does this look reasonable (y/n)? Anybody know 
the back story? Mark.

Re: OOB management options @ 60 Hudson & 1 Summer

[Mitcheltree, Harold B]

Give the Verizon Machine to Machine plan a try before you give up on the 
cellular.

--Pete

From: NANOG  on behalf of Saku 
Ytti 
Sent: Friday, April 16, 2021 12:33 AM
To: Matthew Crocker 
Cc: NANOG 
Subject: Re: OOB management options @ 60 Hudson & 1 Summer



On Fri, 16 Apr 2021 at 01:18, Matthew Crocker 
mailto:matt...@corp.crocker.com>> wrote:


I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some low 
cost bandwidth options for out of band management.  Currently



I’m surprised OOB bandwidth isn’t a feature for colocation providers.

That would surprise me too.

https://www.digitalrealty.com/connectivity/ip-bandwidth
https://www.markleygroup.com/cloud/network/out-of-band

--
  ++ytti