Ntp.nasa.gov never fails me. Matt On Feb 7, 2014 10:56 AM, <nanog-request@nanog.org> wrote:
Send NANOG mailing list submissions to nanog@nanog.org
To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request@nanog.org
You can reach the person managing the list at nanog-owner@nanog.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..."
Today's Topics:
1. Re: Need trusted NTP Sources (Jimmy Hess) 2. RE: SIP on FTTH systems (Frank Bulk) 3. Re: carrier comparison (Vlade Ristevski) 4. Re: carrier comparison (Faisal Imtiaz) 5. Re: SIP on FTTH systems (Mark Tinka) 6. Re: carrier comparison (Mark Tinka) 7. Re: Need trusted NTP Sources (Roy) 8. Re: SIP on FTTH systems (Jay Ashworth) 9. Re: SIP on FTTH systems (Mark Tinka)
----------------------------------------------------------------------
Message: 1 Date: Fri, 7 Feb 2014 06:38:06 -0600 From: Jimmy Hess <mysidia@gmail.com> To: Saku Ytti <saku@ytti.fi> Cc: NANOG list <nanog@nanog.org> Subject: Re: Need trusted NTP Sources Message-ID: < CAAAwwbU+CiTpjXjyAQE1rCT8EE+jX4XhywFPvOC+p4dw6YZPbA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2014-02-06 21:14 -0500), Jay Ashworth wrote:
My usual practice is to set up two in house servers, each of which talks to: Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them.
+1 to having at least 3 NTP servers. Because complete outage is only one kind of failure.
Don't forget poor performance due to high latency, or Server X emitting corrupted or inaccurate data
-- -JH
------------------------------
Message: 2 Date: Fri, 7 Feb 2014 07:30:08 -0600 From: "Frank Bulk" <frnkblk@iname.com> To: "'Jay Ashworth'" <jra@baylink.com>, "NANOG" <nanog@nanog.org> Subject: RE: SIP on FTTH systems Message-ID: <00b401cf2408$b846cde0$28d469a0$@iname.com> Content-Type: text/plain; charset="UTF-8"
Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. MACFF is supposed to solve that (we haven't turned it on, yet, because the vendor's implementation requires us to do some work on our provisioning system to make it easier).
Frank
-----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Thursday, February 06, 2014 11:59 PM To: NANOG Subject: Re: SIP on FTTH systems
----- Original Message -----
From: "Frank Bulk" <frnkblk@iname.com>
And then you need MACFF to overcome the split-horizon to that customers in the same subnet can talk to each other. =)
In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any "real" traffic there. Just attack traffic.
Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-)
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
------------------------------
Message: 3 Date: Fri, 07 Feb 2014 09:19:15 -0500 From: Vlade Ristevski <vristevs@ramapo.edu> To: nanog@nanog.org Subject: Re: carrier comparison Message-ID: <52F4EB63.7020806@ramapo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm not setting it on my router locally but sending it over to Cogent as a community string per page 22 of their user guide.
http://cogentco.com/files/docs/customer_service/guide/global_cogent_customer...
They use it to manipulate how traffic gets back to me so that is incoming from my routers view.
I also pad the AS for the networks that I prefer to come back through the other ISP..
On 2/7/2014 5:27 AM, Olivier Benghozi wrote:
Hi Vlade,
Well, if you are trying to balance the incoming traffic load with local-pref attribute, I can understand your disappointment :) Since it doesn't work at all this way: local-pref is local to an AS and deals with outgoing traffic only.
B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too.
-- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854
------------------------------
Message: 4 Date: Fri, 7 Feb 2014 14:49:09 +0000 (GMT) From: Faisal Imtiaz <faisal@snappytelecom.net> To: Olivier Benghozi <olivier.benghozi@wifirst.fr> Cc: nanog@nanog.org Subject: Re: carrier comparison Message-ID: <693349979.661671.1391784549000.JavaMail.root@snappytelecom.net> Content-Type: text/plain; charset=utf-8
Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken)
This is the common issue / challenge in how to determine up-stream path outage and then doing appropriate route engineering on an automatic basis.
Maybe a SLA monitor type scripting/configuration be useful in your case.
Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net
----- Original Message -----
From: "Olivier Benghozi" <olivier.benghozi@wifirst.fr> To: nanog@nanog.org Sent: Friday, February 7, 2014 5:25:53 AM Subject: Re: carrier comparison
Hi Faisal,
You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider.
To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with.
Well, technically there's BFD that might do the trick. But of course it won't be available; it's not usually, so specially with Cogent... :) But maybe its link was just overloaded in fact.
-- Olivier
------------------------------
Message: 5 Date: Fri, 7 Feb 2014 17:20:08 +0200 From: Mark Tinka <mark.tinka@seacom.mu> To: nanog@nanog.org Subject: Re: SIP on FTTH systems Message-ID: <201402071720.12145.mark.tinka@seacom.mu> Content-Type: text/plain; charset="us-ascii"
On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote:
Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't.
This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level.
I prefer EVC Split Horizon to Private VLAN's, though.
Mark.