Ntp.nasa.gov never fails me. Matt On Feb 7, 2014 10:56 AM, <nanog-requ...@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-requ...@nanog.org > > You can reach the person managing the list at > nanog-ow...@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 <mysi...@gmail.com> > To: Saku Ytti <s...@ytti.fi> > Cc: NANOG list <nanog@nanog.org> > Subject: Re: Need trusted NTP Sources > Message-ID: > < > caaawwbu+citpjxjyaqe1rct8ee+jx4xhywfpvoc+p4dw6yz...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti <s...@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" <frnk...@iname.com> > To: "'Jay Ashworth'" <j...@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:j...@baylink.com] > Sent: Thursday, February 06, 2014 11:59 PM > To: NANOG > Subject: Re: SIP on FTTH systems > > ----- Original Message ----- > > From: "Frank Bulk" <frnk...@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 > j...@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 <vrist...@ramapo.edu> > To: nanog@nanog.org > Subject: Re: carrier comparison > Message-ID: <52f4eb63.7020...@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_user_guide.pdf > > 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 <fai...@snappytelecom.net> > To: Olivier Benghozi <olivier.bengh...@wifirst.fr> > Cc: nanog@nanog.org > Subject: Re: carrier comparison > Message-ID: > <693349979.661671.1391784549000.javamail.r...@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: supp...@snappytelecom.net > > ----- Original Message ----- > > From: "Olivier Benghozi" <olivier.bengh...@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.ti...@seacom.mu> > To: nanog@nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <201402071720.12145.mark.ti...@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. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/be185b23/attachment-0001.bin > > > > ------------------------------ > > Message: 6 > Date: Fri, 7 Feb 2014 17:21:46 +0200 > From: Mark Tinka <mark.ti...@seacom.mu> > To: nanog@nanog.org > Subject: Re: carrier comparison > Message-ID: <201402071721.47057.mark.ti...@seacom.mu> > Content-Type: text/plain; charset="us-ascii" > > On Friday, February 07, 2014 04:49:09 PM Faisal Imtiaz > wrote: > > > 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) > > You would also need your provider to support BFD (and by > support I mostly mean willing to run, as modern gear today > is technically capable). > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/b2db7fc3/attachment-0001.bin > > > > ------------------------------ > > Message: 7 > Date: Fri, 07 Feb 2014 07:23:22 -0800 > From: Roy <r.engehau...@gmail.com> > To: nanog@nanog.org > Subject: Re: Need trusted NTP Sources > Message-ID: <52f4fa6a.60...@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/7/2014 3:35 AM, Saku Ytti 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: > >> > >> And then point everyone in house to both of them, assuming they accept > >> multiple server names. > > 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. > > > > "A man with a watch knows what time it is. A man with two watches is > never sure." > > > > ------------------------------ > > Message: 8 > Date: Fri, 07 Feb 2014 10:41:44 -0500 > From: Jay Ashworth <j...@baylink.com> > To: mark.ti...@seacom.mu,Mark Tinka > <mark.ti...@seacom.mu>,nanog@nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <3db10818-3072-482b-b619-5a884e10d...@email.android.com> > Content-Type: text/plain; charset=UTF-8 > > I would assume that this whole mostly depends on which particular > protocols and approaches your edge equipment can implement most efficiently > - efficiently enough, that is, to be able to do it on every single port in > a chassis. > > On February 7, 2014 10:20:08 AM EST, Mark Tinka <mark.ti...@seacom.mu> > wrote: > >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. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > ------------------------------ > > Message: 9 > Date: Fri, 7 Feb 2014 17:53:01 +0200 > From: Mark Tinka <mark.ti...@seacom.mu> > To: Jay Ashworth <j...@baylink.com> > Cc: nanog@nanog.org > Subject: Re: SIP on FTTH systems > Message-ID: <201402071753.01608.mark.ti...@seacom.mu> > Content-Type: text/plain; charset="us-ascii" > > On Friday, February 07, 2014 05:41:44 PM Jay Ashworth wrote: > > > I would assume that this whole mostly depends on which > > particular protocols and approaches your edge equipment > > can implement most efficiently - efficiently enough, > > that is, to be able to do it on every single port in a > > chassis. > > Well, Split Horizon would be enabled on all the customer- > facing ports. > > I am not aware of any protocol restrictions when running > Split Horizon. I haven't run into any issues yet. > > Mark. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 836 bytes > Desc: This is a digitally signed message part. > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20140207/5ac5a1fc/attachment.bin > > > > End of NANOG Digest, Vol 73, Issue 42 > ************************************* >
