Re: NANOG Digest, Vol 73, Issue 42

[Matthew Crevier <mjcrevier () gmail com>]

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_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 <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.
> -------------- 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.tinka () seacom mu>
> To: nanog () nanog org
> Subject: Re: carrier comparison
> Message-ID: <201402071721.47057.mark.tinka () 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.engehausen () gmail com>
> To: nanog () nanog org
> Subject: Re: Need trusted NTP Sources
> Message-ID: <52F4FA6A.60807 () 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 <jra () baylink com>
> To: mark.tinka () seacom mu,Mark Tinka
>         <mark.tinka () seacom mu>,nanog () nanog org
> Subject: Re: SIP on FTTH systems
> Message-ID: <3db10818-3072-482b-b619-5a884e10d538 () 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.tinka () 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.tinka () seacom mu>
> To: Jay Ashworth <jra () baylink com>
> Cc: nanog () nanog org
> Subject: Re: SIP on FTTH systems
> Message-ID: <201402071753.01608.mark.tinka () 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
> *************************************