NANOG Digest, Vol 73, Issue 42
Matthew Crevier
mjcrevier at gmail.com
Fri Feb 7 16:26:55 UTC 2014
Ntp.nasa.gov never fails me.
Matt
On Feb 7, 2014 10:56 AM, <nanog-request at nanog.org> wrote:
> Send NANOG mailing list submissions to
> nanog at 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 at nanog.org
>
> You can reach the person managing the list at
> nanog-owner at 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 at gmail.com>
> To: Saku Ytti <saku at ytti.fi>
> Cc: NANOG list <nanog at nanog.org>
> Subject: Re: Need trusted NTP Sources
> Message-ID:
> <
> CAAAwwbU+CiTpjXjyAQE1rCT8EE+jX4XhywFPvOC+p4dw6YZPbA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti <saku at 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 at iname.com>
> To: "'Jay Ashworth'" <jra at baylink.com>, "NANOG" <nanog at nanog.org>
> Subject: RE: SIP on FTTH systems
> Message-ID: <[email protected]>
> 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 at baylink.com]
> Sent: Thursday, February 06, 2014 11:59 PM
> To: NANOG
> Subject: Re: SIP on FTTH systems
>
> ----- Original Message -----
> > From: "Frank Bulk" <frnkblk at 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 at 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 at ramapo.edu>
> To: nanog at nanog.org
> Subject: Re: carrier comparison
> Message-ID: <52F4EB63.7020806 at 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 at snappytelecom.net>
> To: Olivier Benghozi <olivier.benghozi at wifirst.fr>
> Cc: nanog at nanog.org
> Subject: Re: carrier comparison
> Message-ID:
> <693349979.661671.1391784549000.JavaMail.root at 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 at Snappytelecom.net
>
> ----- Original Message -----
> > From: "Olivier Benghozi" <olivier.benghozi at wifirst.fr>
> > To: nanog at 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 at seacom.mu>
> To: nanog at nanog.org
> Subject: Re: SIP on FTTH systems
> Message-ID: <201402071720.12145.mark.tinka at 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 at seacom.mu>
> To: nanog at nanog.org
> Subject: Re: carrier comparison
> Message-ID: <201402071721.47057.mark.tinka at 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 at gmail.com>
> To: nanog at nanog.org
> Subject: Re: Need trusted NTP Sources
> Message-ID: <52F4FA6A.60807 at 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 at baylink.com>
> To: mark.tinka at seacom.mu,Mark Tinka
> <mark.tinka at seacom.mu>,nanog at nanog.org
> Subject: Re: SIP on FTTH systems
> Message-ID: <3db10818-3072-482b-b619-5a884e10d538 at 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 at 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 at seacom.mu>
> To: Jay Ashworth <jra at baylink.com>
> Cc: nanog at nanog.org
> Subject: Re: SIP on FTTH systems
> Message-ID: <201402071753.01608.mark.tinka at 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
> *************************************
>
More information about the NANOG
mailing list