Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: IPSec VPN server (Nathan Anderson)
2. Pre-deployment/upgrade and Constant Quality Monitoring
(Lakmal Fernando)
3. Re: IPSec VPN server (Eric Wieling)
4. Re: 911 address policy for company phones at home (Mary Lou Carey)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Jan 2013 00:42:53 -0800
From: Nathan Anderson <[email protected]>
To: "'Jimmy Hess'" <[email protected]>, "'Eric Wieling'"
<[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [VoiceOps] IPSec VPN server
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hear, hear. Surely I'm not the only one who has read through Cisco errata for
kicks and thought to myself after reading some of them, "how in the heck did
this manage to get past QA?" (Speaking of...some of you may have seen this
before, but:
http://etherealmind.com/cisco-culture-of-buggy-code-and-the-failure-of-the-tac/)
As a former boss of mine once told me, "all hardware sucks, all software
sucks...some just suck less than others."
You have to bear in mind that my history with MikroTik goes back to the 2.x
days. Most of the bugs we would run into were eventually traced to code that
they didn't even have a hand in engineering (e.g., Quagga), and most of that
stuff has since been replaced with new implementations of the same features
written by them from scratch. That's not to say that their own code is
perfect, 'cause it isn't, but it is head-and-shoulders above the stuff they
were using befor (there were some dark days a few years back where I was ready
to swear off the product for good). I would say that most of the time, the
routers we still encounter the occasional problem on are the ones where
multiple features are being heavily used: route exchanges via BGP and OSPF,
MPLS LDP exchanges, a bunch of VPLS tunnels, several hundred simultaneous PPP
sessions, a complex queue tree plus individual rate-limiting queues for each
PPP tunnel... I'm not saying this to excuse it when we do have problems tha!
t are obviously software-related, but rather to illustrate the point that
based on my past experience, you are much less likely to encounter a problem if
you are only using a single feature (say, IPsec) or a small handful of features.
As an example, the MikroTik router doing double-duty as the gateway to both our
office and one of our NOCs -- which itself is hardly simplistically configured
-- has been up for 300 days now, and the last time it was rebooted was so that
we could perform a software upgrade to fix a sporadic problem we were having
with random OSPF neighbor adjacency resets (and the upgrade did fix it).
We also still have not gotten an answer from Eric on what product he is
currently using that is so unstable that it has to be rebooted once annually,
or even what class of product it is. There are days where I would kill for
products that only had to be rebooted once a year...again, not excusing those
that do need that reboot, but just trying to put things in perspective a
little. :-) As Jimmy I believe accurately pointed out, if that kind of uptime
is important to someone, then you need to be investing in a
high-availability/hardware-redundancy/failover-pair solution of some kind.
--
Nathan Anderson
First Step Internet, LLC
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Jimmy Hess
Sent: Sunday, January 20, 2013 9:37 PM
To: Eric Wieling
Cc: [email protected]
Subject: Re: [VoiceOps] IPSec VPN server
On 1/20/13, Eric Wieling <[email protected]> wrote:
There are very few networking products in existence that haven't had
some kind of software stability problem or bad hardware design
problem at one time or another; so don't mark down earlier version
experience against MicroTik.
I can tell you with certainty, that PIX515s crash too, and in certain
configurations have very serious stability issues in certain
situations; so do ASAs, and just about any router from any vendor.
There aren't many non-trivial devices you can't say that kind of thing
about. Manufacturer instructions, and running appropriate firmware
versions, are very important.
If it's a requirement that you have less than 1 crash a year, then
that would most likely require something that can be used in a
failover pair; possibly two of those PIX 51xx s.
Otherwise, there is really no way on earth to have a significant
level of assurance of availability.
If you don't require an extensive feature set; usually using the
simplest device and simplest software possible, will give you fewer
things that can break.
Using devices with more complex elements, like general purpose
computers with spinning disks, would be asking for trouble, even
though off the shelf servers that can run Linux are cheap.
Make sure the configuration will be simple, a common configuration for
the device, and fully supported and warranted by the manufacturer.
I definitely do expect the mature appliance products on stable
codebases, which have more engineering into them, when used in fully
supported configurations to be on average a lot more reliable than
some MicroTik components -- but the fact of the matter is you might
have the bad luck of the draw, in regards to hardware, even with a
competitors' device costing 100x as much.
Regardless of manufacturer, some percentage of the components will
have defects, it could be a hardware defect so minor that it just
causes on average 2 crashes a year.
> We are looking for something which crashes LESS than once per year. "had a
> few stability problems" doesn't give me a warm fuzzy feeling about the
> product. Configuration management is nice, but how important is it for a
> device which is never modified and has only one tunnel?
--
-JH
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Message: 2
Date: Mon, 21 Jan 2013 05:03:52 -0800 (PST)
From: Lakmal Fernando <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [VoiceOps] Pre-deployment/upgrade and Constant Quality
Monitoring
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
You may check Arptel, www.arptel.com. ?They are having a system to test
your?requirements.
Best Regards,
Lakmal Fernando?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130121/ee3abd4c/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 21 Jan 2013 10:32:42 -0500
From: Eric Wieling <[email protected]>
To: Nathan Anderson <[email protected]>, "'Jimmy Hess'"
<[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [VoiceOps] IPSec VPN server
Message-ID:
<616B4ECE1290D441AD56124FEBB03D081046CE663C@mailserver2007.nyigc.globe>
Content-Type: text/plain; charset="us-ascii"
-----Original Message-----
From: Nathan Anderson [mailto:[email protected]]
Sent: Monday, January 21, 2013 3:43 AM
To: 'Jimmy Hess'; Eric Wieling
Cc: '[email protected]'
Subject: RE: [VoiceOps] IPSec VPN server
We also still have not gotten an answer from Eric on what product he is
currently using that is so unstable that it has to be rebooted once annually,
or even what class of product it is. There are days where I would kill for
products that only had to be rebooted once a year...again, not excusing those
that do need that reboot, but just trying to put things in perspective a
little. :-) As Jimmy I believe accurately pointed out, if that kind of uptime
is important to someone, then you need to be investing in a
high-availability/hardware-redundancy/failover-pair solution of some kind.
===========================
Juniper Netscreen 25
------------------------------
Message: 4
Date: Mon, 21 Jan 2013 09:53:58 -0600
From: "Mary Lou Carey" <[email protected]>
To: "'Frank Bulk'" <[email protected]>, "'Jay Hennigan'"
<[email protected]>, "'VoiceOps'" <[email protected]>
Subject: Re: [VoiceOps] 911 address policy for company phones at home
Message-ID: <147401cdf7ef$865eda20$931c8e60$@com>
Content-Type: text/plain; charset="us-ascii"
Thanks Frank....good to know! I'm sure I just wasn't searching with the
right key words to find that. I wonder if they offer it as a stand alone
product or you can only get it when you sign up for their VOIP 911 service.
Mary Lou Carey
BackUP Telecom Consulting
[email protected]
Office: 615-791-9969 x 2001
-----Original Message-----
From: Frank Bulk [mailto:[email protected]]
Sent: Saturday, January 19, 2013 7:10 PM
To: 'Mary Lou Carey'; 'Jay Hennigan'; 'VoiceOps'
Subject: RE: [VoiceOps] 911 address policy for company phones at home
It looks like there are vendors that make it possible for PSAPs to access
near-realtime info:
http://www1.911enable.com/resource-center/faq (see "What is a VoIP
Positioning Center?")
Frank
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Mary Lou Carey
Sent: Saturday, January 19, 2013 8:17 AM
To: 'Jay Hennigan'; 'VoiceOps'
Subject: Re: [VoiceOps] 911 address policy for company phones at home
PBXs can associate a single line for one location or have multiple lines,
one for each location so that there is an address in the ALI database for
each location. These lines are all fixed though so it's very different from
VOIP because the end user can move their phone to any location that has
internet access and use it without the switch being re-programmed. That's
why there is a requirement for the CLEC to offer a way for the customer to
update their information in the ALI database themselves.
Someone asked me about who provides the VOIP ALI update solution and I
couldn't find a provider, but in researching it I did find that there
appears to be an issue with this method because the ALI database doesn't
update in real time and since users could plug their phone in and update the
address, it didn't mean that the ALI database identified the location
correctly. YMAX commented to the FCC in November 2011 (see the link below)
that they had a solution that could work. It involved attaching a GSM
cellular transceiver to their MagicJack device so the location could be
identified but it also relied on having some type of database with customer
locations to help it identify which PSAP needed to be contacted so it
doesn't appear that is totally thought out either. It appears to me that
even though there are some requirements that the FCC put out about updating
the ALI database, the details of exactly how that will work aren't totally
worked out because of the issue with the ALI database. To me......that seems
like a great business opportunity for someone! If you could figure out how
to get a VOIP phone to automatically identify the exact location of the
phone whenever its plugged in and transmit that location to a VOIP ALI
database (which you'd need to create), then you could sell the service to
both PSAPs AND VOIP providers!
http://apps.fcc.gov/ecfs/document/view;jsessionid=c1M1QZvLvW9XfyYDpTwlMGN1QK
T7yhs21npc4ThYvwR61R6JK4yv!-56284754!-224088840?id=7021744691
Mary Lou Carey
BackUP Telecom Consulting
[email protected]
Office: 615-791-9969 x 2001
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Jay Hennigan
Sent: Friday, January 18, 2013 6:33 PM
To: VoiceOps
Subject: Re: [VoiceOps] 911 address policy for company phones at home
On 1/18/13 3:46 PM, Mike Ray wrote:
> The difference here is the demarcation point. If you're handing off
> analog lines, there are two important differences:
>
> 1. You're not providing the PBX functionality as part of the telephone
> service and, 2. You're using a technology that is incapable of sending
> a different ANI than what's in your switch for each line.
An extension-only SIP phone doesn't have a unique ANI.
> So the requirement here is that the e911 ALI address must match the
> physical location where you have those lines installed.
But there are no "lines" for DID-less extensions or for that matter an
"installation" in the case of softphones.
The company HQ where the main ANI is answered is the ALI address. Call it
and talk to the receptionist. Drive there in a police car and visit the
same receptionist.
> If you are looking to protect yourself from the customer moving to a
> new location, ATA, PBX and all, you just use a contract provision
> requiring them to notify you of address changes. You could also
> require them to have you move the service to the new location for more
security there.
Yes, and you should.
> So, different animal that the hosted PBX question...
ATA, PBX and all is indeed a different animal than an extension-only remote
phone.
The problem, and I don't know if there is a full solution, is that PSTN
telephone numbers have always been used to identify the destination of a
call. 9-1-1 assumes that this identifier of a destination positively and
unequivocally also identifies the origin.
Think in terms of laptops with softphones. There is no way to make that
work with the present 9-1-1 infrastructure.
--
Jay Hennigan - CCIE #7880 - Network Engineering - [email protected] Impulse
Internet Service - http://www.impulse.net/ Your local telephone and
internet company - 805 884-6323 - WB6RDV
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
End of VoiceOps Digest, Vol 43, Issue 42
****************************************
