Re: alternative to voip gateways

[Nick Edwards]

Been down that road, not a viable option, in fact i'm told if we get
this done without much drama we'll be converting our existing (much
smaller) wifi sites to copper as well, and since they already have all
this copper laid already, might as well use it

On 5/5/20, Baldur Norddahl  wrote:
> Thinking out of the box, why not implement a WISP setup using wifi? This
> kind of gear is more accessible to normal IT staff.
>
> Voice can be implemented by VoIP using Wifi too.
>
> Regards
> Baldur
>
>
> søn. 3. maj 2020 07.22 skrev Nick Edwards :
>
>> The huts or cabins whatever you want to call them,  are right behind
>> the admin building at entrance, so first is about 300 meters and the
>> furtherest  is just under 1 mile
>>
>> Cost will be an issue, Im sure I will have no problems if I have to
>> install a full rack of gateways and another full of dslams if it costs
>> 150K, over something 1/5th the size in one rack that will cost 200k -
>> since the company is not charging them for internet or voice.
>>
>> On 5/2/20, Jeremy Austin  wrote:
>> > What’s the average loop length? Grandstream is probably OK to 5+ kfeet
>> but
>> > you will lose CID before that.
>> >
>> > As the low cost option don’t expect them to be trouble-free (or have
>> > particularly good vendor support), but they might work in your
>> application
>> > if cheap is what makes sense.
>> >
>> > My $.02
>> >
>> > Jeremy Austin
>> >
>> > On Fri, May 1, 2020 at 10:11 PM Andrey Slastenov
>> > 
>> > wrote:
>> >
>> >> Look at MSAN solution. Like Huawei UA5000 or similar solutions from
>> other
>> >> vendors.
>> >>
>> >>
>> >> Regards,
>> >> Andrey
>> >>
>> >> > 2 мая 2020 г., в 07:21, Nick Edwards 
>> >> написал(а):
>> >> >
>> >> > I'm looking at a new sister company we just took over, their remote
>> >> > village has 1700 analogue phone lines to the workers huts, but they
>> >> > go
>> >> > nowhere past the MDF.
>> >> >
>> >> > The office runs voip, now i'm told i have to get phones to the
>> >> > workers
>> >> > because the  AKA previous owners of that
>> >> > business  stopped the build when they ran into financial problems.
>> >> >
>> >> > So my plan is to utilize the existing many miles worth of copper
>> pairs.
>> >> >
>> >> > I'm looking at throwing them into Versa Dslams that use pppoe pass
>> >> > through, throw in a mikoTik 1036 as pppoe server, and we got spare
>> >> > R710 i can use as radius server, and by my limited knowledge this
>> >> > works.
>> >> >
>> >> > OK data done, but... now all those pots out lines need to go
>> >> > somewhere
>> >> > that can handle 1700 or more lines, I am looking at either
>> >> > grandstream
>> >> > 48 port FXS gateways or sangoma vega 50 ports (which Ill use as 48
>> >> > so
>> >> > theres a 1:1 match with dslams) the vega 3050 probably wont be used
>> >> > because they are more than twice the price of grandstream.
>> >> >
>> >> > But this all results in a sh1te load of 48 port gateways (power is
>> >> > not
>> >> > a concern), but wondering if there is another solution that is more
>> >> > cost effective? Seems the regular NEC's Siemens and so on might have
>> >> > an option but I can imagine it will be far more expensive than a
>> >> > bunch
>> >> > of individual gateways.
>> >> >
>> >> > This project is in my mind workable, but i've not done such a thing
>> >> > on
>> >> > a large scale.
>> >> > Those who have experience in this field care to chime in? is my
>> >> > method
>> >> > acceptable or not for such a project size?
>> >> >
>> >> > most pbx's I've done are only few hundred analogue lines where
>> >> > gateways are more suited and definitely more cost effective, at all
>> >> > our locations we use freepbx which works perfectly, and we know the
>> >> > beefyness of the box we'll need to install to handle this load,
>> >> > thats
>> >> > not a problem if we go down the gateway method.
>> >> >
>> >> > thoughts?
>> >>
>> > --
>> > Jeremy Austin
>> > jhaus...@gmail.com
>> >
>>
>

See what's in store for NANOG 79 Virtual

[NANOG Marketing]

Join us June 1-3 for the NANOG 79 Virtual Meeting
 to share and discover the latest
networking technologies and best practices — without ever leaving home. The
three-day abridged program will feature a keynote, panel discussions,
presentations, and lightning talks presented by some of the industry’s top
minds.

NANOG 79 will also include a number of interactive opportunities, so you
can share your ideas with the greater NANOG community. Each session will
have a live Q so you can directly engage with NANOG 79 speakers, and the
Community Meeting will also include real-time polling so you can provide
feedback and share your insights.

Check out the full NANOG 79 Preview
 to learn more!

[NANOG-announce] See what's in store for NANOG 79 Virtual

[NANOG Marketing]

Join us June 1-3 for the NANOG 79 Virtual Meeting
 to share and discover the latest
networking technologies and best practices — without ever leaving home. The
three-day abridged program will feature a keynote, panel discussions,
presentations, and lightning talks presented by some of the industry’s top
minds.

NANOG 79 will also include a number of interactive opportunities, so you
can share your ideas with the greater NANOG community. Each session will
have a live Q so you can directly engage with NANOG 79 speakers, and the
Community Meeting will also include real-time polling so you can provide
feedback and share your insights.

Check out the full NANOG 79 Preview
 to learn more!
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

RE: CenturyLink Traffic Shift

[Kevin McCormick]

We see the same shift in traffic since Saturday night as well. Not sure about 
the Hulu outage, we did not have any reports.

Kevin McCormick

From: NANOG  On Behalf Of Fick, Brad
Sent: Tuesday, May 5, 2020 7:09 AM
To: nanog@nanog.org
Subject: CenturyLink Traffic Shift

We saw a big shift in traffic away from CenturyLink on Saturday night, looks 
like much of the traffic shifted over to Verizon Digital Media Services 
(Edgecast CDN).  That night we noticed there was a Hulu outage about the same 
time so I suspect that is what it is.  I am wondering if others are seeing the 
same thing and whether or not it will stay this way (away from the CTL (Level3) 
CDN).

Re: CenturyLink Traffic Shift

[Tom Beecher]

Lots of content providers use multiple CDNs, and shift traffic between them
for various reasons.

On Tue, May 5, 2020 at 9:58 AM Fick, Brad  wrote:

> We saw a big shift in traffic away from CenturyLink on Saturday night,
> looks like much of the traffic shifted over to Verizon Digital Media
> Services (Edgecast CDN).  That night we noticed there was a Hulu outage
> about the same time so I suspect that is what it is.  I am wondering if
> others are seeing the same thing and whether or not it will stay this way
> (away from the CTL (Level3) CDN).
>

Re: alternative to voip gateways

[Mel Beckman]

I’ve implemented these kinds of systems both ways, and in my experience, unless 
the existing copper is in bad condition, it’s always a cheaper, faster, and 
more reliable solution.

Construction costs to hang outdoor radios and run cables is significant. The 
installation labor for a wireless deployment is intensive. The primary reason 
WISPs exist is to give people Internet who otherwise don’t have cheap copper 
connections available. Line-of-site, growing trees, mobile obstructions, and 
rooftop cable entry are all potential failure points.

An in-place copper plant with short runs below a mile can support 20-30 Mbps 
per user with a DSLAM, and 100+ Mbps using Ethernet-over-Copper, all with no 
construction costs, and virtually maintenance-free.

 -mel beckman

On May 5, 2020, at 5:06 AM, Baldur Norddahl  wrote:


Thinking out of the box, why not implement a WISP setup using wifi? This kind 
of gear is more accessible to normal IT staff.

Voice can be implemented by VoIP using Wifi too.

Regards
Baldur


søn. 3. maj 2020 07.22 skrev Nick Edwards 
mailto:nick.z.edwa...@gmail.com>>:
The huts or cabins whatever you want to call them,  are right behind
the admin building at entrance, so first is about 300 meters and the
furtherest  is just under 1 mile

Cost will be an issue, Im sure I will have no problems if I have to
install a full rack of gateways and another full of dslams if it costs
150K, over something 1/5th the size in one rack that will cost 200k -
since the company is not charging them for internet or voice.

On 5/2/20, Jeremy Austin mailto:jhaus...@gmail.com>> wrote:
> What’s the average loop length? Grandstream is probably OK to 5+ kfeet but
> you will lose CID before that.
>
> As the low cost option don’t expect them to be trouble-free (or have
> particularly good vendor support), but they might work in your application
> if cheap is what makes sense.
>
> My $.02
>
> Jeremy Austin
>
> On Fri, May 1, 2020 at 10:11 PM Andrey Slastenov 
> mailto:a.slaste...@gmail.com>>
> wrote:
>
>> Look at MSAN solution. Like Huawei UA5000 or similar solutions from other
>> vendors.
>>
>>
>> Regards,
>> Andrey
>>
>> > 2 мая 2020 г., в 07:21, Nick Edwards 
>> > mailto:nick.z.edwa...@gmail.com>>
>> написал(а):
>> >
>> > I'm looking at a new sister company we just took over, their remote
>> > village has 1700 analogue phone lines to the workers huts, but they go
>> > nowhere past the MDF.
>> >
>> > The office runs voip, now i'm told i have to get phones to the workers
>> > because the  AKA previous owners of that
>> > business  stopped the build when they ran into financial problems.
>> >
>> > So my plan is to utilize the existing many miles worth of copper pairs.
>> >
>> > I'm looking at throwing them into Versa Dslams that use pppoe pass
>> > through, throw in a mikoTik 1036 as pppoe server, and we got spare
>> > R710 i can use as radius server, and by my limited knowledge this
>> > works.
>> >
>> > OK data done, but... now all those pots out lines need to go somewhere
>> > that can handle 1700 or more lines, I am looking at either grandstream
>> > 48 port FXS gateways or sangoma vega 50 ports (which Ill use as 48 so
>> > theres a 1:1 match with dslams) the vega 3050 probably wont be used
>> > because they are more than twice the price of grandstream.
>> >
>> > But this all results in a sh1te load of 48 port gateways (power is not
>> > a concern), but wondering if there is another solution that is more
>> > cost effective? Seems the regular NEC's Siemens and so on might have
>> > an option but I can imagine it will be far more expensive than a bunch
>> > of individual gateways.
>> >
>> > This project is in my mind workable, but i've not done such a thing on
>> > a large scale.
>> > Those who have experience in this field care to chime in? is my method
>> > acceptable or not for such a project size?
>> >
>> > most pbx's I've done are only few hundred analogue lines where
>> > gateways are more suited and definitely more cost effective, at all
>> > our locations we use freepbx which works perfectly, and we know the
>> > beefyness of the box we'll need to install to handle this load, thats
>> > not a problem if we go down the gateway method.
>> >
>> > thoughts?
>>
> --
> Jeremy Austin
> jhaus...@gmail.com
>

CenturyLink Traffic Shift

[Fick, Brad]

We saw a big shift in traffic away from CenturyLink on Saturday night, looks 
like much of the traffic shifted over to Verizon Digital Media Services 
(Edgecast CDN).  That night we noticed there was a Hulu outage about the same 
time so I suspect that is what it is.  I am wondering if others are seeing the 
same thing and whether or not it will stay this way (away from the CTL (Level3) 
CDN).

Re: Arista Switches rebooting

[Chris via NANOG]

Hi,

On 5/5/20 4:02 am, Ethan O'Toole wrote:
We found a bug on the 64 port x 100gig model that if you insert a quad 
twinax 10gig fanout cable in many of the ports it will trigger a reboot.


Timing, seems like there is a similar issue for Juniper QFX51110-48S 
devices, just saw PR 1499422:


This technical support bulletin(TSB) has been opened to inform Juniper 
network customers about PR1499422.  On the QFX5110-48S device inserting 
any QSFP-100G-transceiver on one or more network ports will cause FPC 
state to flap.  In the problem state FPC will go down as soon as the 
100G link comes up and FPC flap will be seen every 90 seconds.

Re: Arista Switches rebooting

[Brandon Martin]

On 5/5/20 2:09 AM, Saku Ytti wrote:

I2C is a pretty terrible bus, particularly if you try to actually hang
everything off of a single I2C bus, single misbehaving speaker and you
might get your power supplies offline. Hopefully we'll move to I3C or
10SPE Ethernet soon. Or maybe some sort of I2C switch where every
connection is on its own bus.


I was of the impression that, due to addressing, I2C bus switches are 
already typically used between each transceiver port and the system bus 
(hopefully one of many) that connects the micro to the ports (hopefully 
relatively dedicated to that purpose).


That's certainly been the case in all of the switches I've torn down 
and, last time I checked at least the SFP specification, there wasn't 
much of a way around it since there was each transceiver uses the same, 
fixed addresses for ID and DDM.


But yes, I2C, while very useful, is the devil.  Clock stretching is 
particularly annoying along with the requisite use of open-drain drivers 
to accomplish it.


I was not aware of 10SPE, though...looks very useful (for lots of 
purposes).  Physical multi-drop on low-cost cabling is quite useful.

--
Brandon Martin

Re: alternative to voip gateways

[Mike Hammett]

You can get a support contract on used Calix\Occam gear. A company I started 
helping a couple years ago was able to get a support contract on gear they had 
owned for 15 years. They price the support based on the number of subscribers 
served off of their gear, not how many and which devices you use to do it. I 
could have a chassis per customer and it wouldn't impact the support contract. 


Well, depending on what you mean by support contract. They won't do hardware 
replacement with the contract I have, but the gear is cheap enough, it's just 
easier to replace the gear than to deal with hardware support. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Nick Edwards"  
To: nanog@nanog.org 
Sent: Monday, May 4, 2020 8:13:51 PM 
Subject: Re: alternative to voip gateways 

Thanks guys, much appreciated! 
Company wants new, not second hand, so it's reasonable to get support 
contract - at least for first year or two :) Not a lot should ever 
change once set up, even if staff change, they wont have access to 
residential SIP details anyway. 


On 5/5/20, Brandon Martin  wrote: 
> On 5/4/20 9:44 AM, Colton Conor wrote: 
>> Adtran has a built in web interface too. I it slow, but it does work. I 
>> like CLI better. 
> 
> Oh yeah, I forgot about that. It does work for most day-to-day tasks, 
> though there are some things you can't do from it and have to drop to 
> the CLI for. Overall, I prefer the CLI. 
> -- 
> Brandon Martin 
> 

Re: alternative to voip gateways

[Baldur Norddahl]

Thinking out of the box, why not implement a WISP setup using wifi? This
kind of gear is more accessible to normal IT staff.

Voice can be implemented by VoIP using Wifi too.

Regards
Baldur


søn. 3. maj 2020 07.22 skrev Nick Edwards :

> The huts or cabins whatever you want to call them,  are right behind
> the admin building at entrance, so first is about 300 meters and the
> furtherest  is just under 1 mile
>
> Cost will be an issue, Im sure I will have no problems if I have to
> install a full rack of gateways and another full of dslams if it costs
> 150K, over something 1/5th the size in one rack that will cost 200k -
> since the company is not charging them for internet or voice.
>
> On 5/2/20, Jeremy Austin  wrote:
> > What’s the average loop length? Grandstream is probably OK to 5+ kfeet
> but
> > you will lose CID before that.
> >
> > As the low cost option don’t expect them to be trouble-free (or have
> > particularly good vendor support), but they might work in your
> application
> > if cheap is what makes sense.
> >
> > My $.02
> >
> > Jeremy Austin
> >
> > On Fri, May 1, 2020 at 10:11 PM Andrey Slastenov 
> > wrote:
> >
> >> Look at MSAN solution. Like Huawei UA5000 or similar solutions from
> other
> >> vendors.
> >>
> >>
> >> Regards,
> >> Andrey
> >>
> >> > 2 мая 2020 г., в 07:21, Nick Edwards 
> >> написал(а):
> >> >
> >> > I'm looking at a new sister company we just took over, their remote
> >> > village has 1700 analogue phone lines to the workers huts, but they go
> >> > nowhere past the MDF.
> >> >
> >> > The office runs voip, now i'm told i have to get phones to the workers
> >> > because the  AKA previous owners of that
> >> > business  stopped the build when they ran into financial problems.
> >> >
> >> > So my plan is to utilize the existing many miles worth of copper
> pairs.
> >> >
> >> > I'm looking at throwing them into Versa Dslams that use pppoe pass
> >> > through, throw in a mikoTik 1036 as pppoe server, and we got spare
> >> > R710 i can use as radius server, and by my limited knowledge this
> >> > works.
> >> >
> >> > OK data done, but... now all those pots out lines need to go somewhere
> >> > that can handle 1700 or more lines, I am looking at either grandstream
> >> > 48 port FXS gateways or sangoma vega 50 ports (which Ill use as 48 so
> >> > theres a 1:1 match with dslams) the vega 3050 probably wont be used
> >> > because they are more than twice the price of grandstream.
> >> >
> >> > But this all results in a sh1te load of 48 port gateways (power is not
> >> > a concern), but wondering if there is another solution that is more
> >> > cost effective? Seems the regular NEC's Siemens and so on might have
> >> > an option but I can imagine it will be far more expensive than a bunch
> >> > of individual gateways.
> >> >
> >> > This project is in my mind workable, but i've not done such a thing on
> >> > a large scale.
> >> > Those who have experience in this field care to chime in? is my method
> >> > acceptable or not for such a project size?
> >> >
> >> > most pbx's I've done are only few hundred analogue lines where
> >> > gateways are more suited and definitely more cost effective, at all
> >> > our locations we use freepbx which works perfectly, and we know the
> >> > beefyness of the box we'll need to install to handle this load, thats
> >> > not a problem if we go down the gateway method.
> >> >
> >> > thoughts?
> >>
> > --
> > Jeremy Austin
> > jhaus...@gmail.com
> >
>

Re: Arista Switches rebooting

[Vincent Bernat]

 ❦  5 mai 2020 09:09 +03, Saku Ytti:

>> We found a bug on the 64 port x 100gig model that if you insert a quad
>> twinax 10gig fanout cable in many of the ports it will trigger a reboot.I
>
> I've seen a similar issue in another vendor, where specific SFP
> inserted would reload the linecard. This was because the SFP didn't
> answer fast enough to I2C queries and the polling code couldn't handle
> the error so it crashed the whole linecard. Vendor didn't fix the
> code, because it didn't happen on vendor optic, while obviously they
> must have understood they can't guarantee vendor optic answers in a
> timely manner in I2C.

We had a similar issue, but vendor fixed the issue (despite it only
happened with cheap third-party optics). If we talk about the same
vendor, it was fixed in 17.3R4, 17.4R3, 17.3R3-S4 and 18.1R3-S4. It's PR
1425893 (not public).
-- 
Man is the only animal that blushes -- or needs to.
-- Mark Twain

Re: Arista Switches rebooting

[Saku Ytti]

On Mon, 4 May 2020 at 23:06, Ethan O'Toole  wrote:

> We found a bug on the 64 port x 100gig model that if you insert a quad
> twinax 10gig fanout cable in many of the ports it will trigger a reboot.I

I've seen a similar issue in another vendor, where specific SFP
inserted would reload the linecard. This was because the SFP didn't
answer fast enough to I2C queries and the polling code couldn't handle
the error so it crashed the whole linecard. Vendor didn't fix the
code, because it didn't happen on vendor optic, while obviously they
must have understood they can't guarantee vendor optic answers in a
timely manner in I2C.

I2C is a pretty terrible bus, particularly if you try to actually hang
everything off of a single I2C bus, single misbehaving speaker and you
might get your power supplies offline. Hopefully we'll move to I3C or
10SPE Ethernet soon. Or maybe some sort of I2C switch where every
connection is on its own bus.


-- 
  ++ytti