Re: google search threshold

On Fri, Feb 26, 2016 at 3:01 PM, Philip Lavine via NANOG wrote: > Does anybody know what the threshold for google searches is before you get > the captcha?I am trying to decide if I need to break up the overload NAT > to a pool. > There isn't a threshold -- if you send

RE: Thank you, Comcast.

Who said that? Of course, it is almost impossible to do anything malicious with lynx as the browser. Why you need to run scripts from google, adobe, and a myriad of other sources (including not less than 3 third party malvertizing sites, 6 tracking sites, and 2 miscellaneous known-malicious

Sprint Wireless DNS server not resolving ietf.org

ietf.org and its subdomains such as tools.ietf.org are not accessible on Sprint 3G/LTE (DNS timeout). From what I gathered this is affecting Sprint wireless customers nationwide. I created a DNS measurement on ripe atlas and no signs of other carriers experiencing the same issue. Emailed Sprint

Re: Thank you, Comcast.

So we have people saying that blocking residential users from hosting DNS servers is not really providing Internet service. Now we have people saying it isn't service if it doesn't (more or less) completely work in lynx. - Mike Hammett Intelligent Computing Solutions

Re: Thank you, Comcast.

On 27 Feb 2016, at 8:06, Keith Medcalf wrote: Consumer Narrowband Access Networks use these protocols all the time. Most broadband access customers do not actively use these protocols, themselves, with the partial exception of SIP. --- Roland Dobbins

RE: Thank you, Comcast.

Really? Consumer Narrowband Access Networks use these protocols all the time. (I call them narrowband since that is what they are -- even though the common euphamism is broadband, "broad" it certainly is not). > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On

Re: Thank you, Comcast.

On 27 Feb 2016, at 7:59, John Levine wrote: I think that most if not all of the consumer over the top VoIP phones like Vonage use SIP. That's true. One would hope that they're not globally reachable, however. --- Roland Dobbins

Re: Thank you, Comcast.

>True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized >by remote workers via VPNs? Dunno, but I have two of them. I think that most if not all of the consumer over the top VoIP phones like Vonage use SIP. R's, John

RE: Thank you, Comcast.

The default configuration of IE (all versions), Firefox (all versions), Edge (all versions) and Chrome (all versions) is a zero-security configuration. Of course it works fine in a zero-security configuration -- I said that from the get go. It does not work if you do not permit javascript to

Re: Thank you, Comcast.

On 27 Feb 2016, at 7:23, John Levine wrote: The VoIP phones sure use SIP. True, but how prevalent are 'bare' SIP phones vs. VoIP systems utilized by remote workers via VPNs? --- Roland Dobbins

Re: Thank you, Comcast.

>> A certain number of us work from home and connect to headquarters with >> a VPN. and have SIP phones, you know. > >Not typically via/requiring the protocols you mentioned. The VoIP phones sure use SIP. R's, John

RE: mrtg alternative

We use observium. It has most of what you're looking for. Used to use cacti but switched a couple of months ago -Original Message- From: "Baldur Norddahl" Sent: Friday, February 26, 2016 6:18pm To: "nanog@nanog.org" Subject: mrtg

Re: Thank you, Comcast.

On 27 Feb 2016, at 4:03, John Levine wrote: A certain number of us work from home and connect to headquarters with a VPN. and have SIP phones, you know. Not typically via/requiring the protocols you mentioned. --- Roland Dobbins

google search threshold

Does anybody know what the threshold for google searches is before you get the captcha?I  am trying to decide if I need to break up the overload NAT to a pool. -thx

Re[2]: Thank you, Comcast.

I'd expect the Colo's to start "locking this down" about the same time I'd expect ISP's to start implementing BCP38 in earnest. Adam -- Original Message -- From: "Dovid Bender" To: "Damian Menscher" Cc: "Mody, Nirmal"

mrtg alternative

Hi I am currently using MRTG and RRD to make traffic graphs. I am searching for more modern alternatives that allows the user to dynamically zoom and scroll the timeline. Bonus points if the user can customize the graphs directly in the webbrowse. For example he might be able to add or remove

Re: Thank you, Comcast.

On 2/26/16 1:08 PM, Rich Kulawiec wrote: On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote: You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home

Re: Thank you, Comcast.

>The difference in blocking any of the existing ports on your list and >blocking UDP/1900 is that the ports on your list are all registered >ports. Port 1900 is not registered - IANA is under the impression it's registered for SSDP. Do you have some reason to believe they're mistaken?

Re: Thank you, Comcast.

>>Customers regularly use various VPN protocols from GRE, SIT, and >> IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where >> we spend the bulk of our time troubleshooting). > >Not so on consumer broadband access networks, which are what's being >discussed in this thread.

Re: Thank you, Comcast.

Lawsuits? There is no reason the dedicated server I have with a 100meg pipe for $65.00 per month is able to spoof IP's. The colo's should be doing a better job to lock this down. Regards, Dovid -Original Message- From: Damian Menscher Date: Fri, 26 Feb 2016

Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 10:16:33AM -0700, Brielle Bruns wrote: > You can't do anything about idiots buying a pro-sumer/professional > device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, > D-Link, Netgear, etc that are targeted towards home users should be > held to the fire for

Re: Thank you, Comcast.

Blake Hudson wrote on 2/26/2016 2:01 PM: Livingood, Jason wrote on 2/26/2016 1:32 PM: On 2/26/16, 11:44 AM, "Blake Hudson" > wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port

Re: Thank you, Comcast.

Livingood, Jason wrote on 2/26/2016 1:32 PM: On 2/26/16, 11:44 AM, "Blake Hudson" > wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the

Re: Standard terminology for a dark fiber path?

As Dave C pointed out, it commonly referenced as a Fiber Span. The fiber span would be inclusive of any splice points and/or patches needed to provide connectivity between point A and point Z. A Fiber Stand is a single piece of glass within the cable sheath, often spliced to create a fiber span.

Re: Thank you, Comcast.

"We all know..." followed by a false statement is amusing. A significant portion of spoofing originates from North America. In a recent attack I'm reviewing, the top sources of spoofing were the southwestern US, the northwestern US, and east Asia (and almost none from Europe). If ISPs

Consumer Equipment Sucks (Re: Thank you, Comcast.)

> On Feb 26, 2016, at 2:28 PM, Livingood, Jason > wrote: > > I think the bigger culprit is not the stuff ISPs buy but what consumers > buy (aka COAM). I’m certainly not a comcast apologist, (I do wish they would service the communities where they had their call

Re: Thank you, Comcast.

On 2/26/16, 11:44 AM, "Blake Hudson" > wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? As Roland suggested,

Re: Thank you, Comcast.

On 2/26/16, 12:33 PM, "NANOG on behalf of Octavio Alvarez" wrote: >On 26/02/16 09:16, Brielle Bruns wrote: >> Place the blame for local resolvers listening on WAN squarely where it >>belongs - the router vendors who make these

Re: messing with DNS, was Thank you, Comcast.

On 2/26/16, 1:03 PM, "NANOG on behalf of John Levine" on behalf of jo...@iecc.com> wrote: T-W and I am fairly sure Comcast have per-customer opt-out from DNS "enhancement". T-W's is at

Re: Thank you, Comcast.

On 2/26/16 10:22 AM, Mike Hammett wrote: Said in a forum comprised largely of ISPs? Bold move. I appreciate the work the technical people here do, but doesn't change the fact that the people who call the shots aren't always on the same page or have the same goals as do the technical people.

Re: Thank you, Comcast.

On Fri, 26 Feb 2016 07:20:28 +0100 (CET) Mikael Abrahamsson wrote: > I know historically there were resolvers that used UDP/53 as source > port for queries, but is this the case nowadays? Empirically from what I've observed, much less than there once was. Looking at a sample

Re: Thank you, Comcast.

This is one of my pet peeves. Another is default passwords for devices. Kudo to TP-Link for not shipping devices with default passwords. Regards, Dovid -Original Message- From: Brielle Bruns Sender: "NANOG" Date: Fri, 26 Feb 2016 10:16:33

Re: Thank you, Comcast.

Disconnecting the US isn’t a viable solution. > On Feb 26, 2016, at 1:48 PM, Dovid Bender wrote: > > We all know what countries this traffic is coming from. While you can > threaten the local ISP's the ones over seas where the traffic is coming from > won't care.

Re: Thank you, Comcast.

On Fri, 26 Feb 2016 10:52:55 -0500, Jay Nugent said: > However, if a 'provider' wishes to block ANYTHING, then they need to > inform the customer IN WRITING exactly what will be blocked so that > customer doesn't waste their time and money with said (limited) service > and vote with their

Re: Thank you, Comcast.

We all know what countries this traffic is coming from. While you can threaten the local ISP's the ones over seas where the traffic is coming from won't care. Regards, Dovid -Original Message- From: Damian Menscher via NANOG Sender: "NANOG"

Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 12:17:32PM -0500, Rich Kulawiec wrote: > On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote: > > On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: > > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > > ports/ > > >

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to

Re: messing with DNS, was Thank you, Comcast.

>Every ISP I have felt with that messes with the DNS, has no valid opt-out >other than using different DNS. The opt-out they use is a HTTP cookie, >which only works for web browsers. It doesn't work for any other program. T-W and I am fairly sure Comcast have per-customer opt-out from DNS

Re: Thank you, Comcast.

> On Feb 26, 2016, at 12:42 PM, John Levine wrote: > > Huh. Is it 1998 again? More like NANOG again. - jared

Re: Thank you, Comcast.

On 26 Feb 2016, at 22:52, Jay Nugent wrote: Customers regularly use various VPN protocols from GRE, SIT, and IPIP, monitoring protocols such as SNMP, as well as RTP and SIP (where we spend the bulk of our time troubleshooting). Not so on consumer broadband access networks, which are

Re: DNS filtering, was Thank you, Comcast.

In article <848464982.14027.1456503347620.JavaMail.mhammett@ThunderFuck> you write: >I think you'd be hard pressed to find more than a tenth of a percent of people >attempt to run their own DNS server. Some do because they think >it'll be better in some way. Rare is the occasion where anything

Re: Thank you, Comcast.

On 27 Feb 2016, at 0:25, Anthony Junk wrote: There is so much arrogance in these posts saying that these things should be blocked because it's best or because it's negligible. I think there's a lack of comprehension on the part of those who don't run large networks and/or who aren't

Re: Thank you, Comcast.

In article you write: >ISP's should block nothing, to or from the customer, unless they make it clear >*before* selling the service (and include it in the Terms and >Conditions of Service Contract), that they are not selling an Internet

Re: Thank you, Comcast.

Once upon a time, Brielle Bruns said: > UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to > the customer also will block responses to recursive queries that > originate from SRC 53/UDP. Connection tracking sorta makes it > stateful to a point, but it can get ugly

Re: Thank you, Comcast.

On 26/02/16 09:16, Brielle Bruns wrote: > Place the blame for local resolvers listening on WAN squarely where it > belongs - the router vendors who make these devices. As long as ISPs massively buy crappy hardware pieces, vendors will make them and sell them. That's how it works. Best regards.

Re: Thank you, Comcast.

On 27 Feb 2016, at 0:16, Brielle Bruns wrote: You can't do anything about idiots buying a pro-sumer/professional device like an EdgeRouter and misconfiguring it, but Linksys/Cisco, D-Link, Netgear, etc that are targeted towards home users should be held to the fire for that kind of screw up.

RE: Thank you, Comcast.

Greetings, On Fri, 26 Feb 2016, Keith Medcalf wrote: ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are

Brighthouse Networks security contact?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear team, I'm looking for a Brighthouse Networks security contact, please. Thank you! Rob. - -- Rabbi Rob Thomas Team Cymru "It is easy to believe in freedom of speech for those with whom we agree."

Re: Thank you, Comcast.

On 27 Feb 2016, at 0:16, Brielle Bruns wrote: UDP is a fun protocol - stateless, so blocking a DST of 53/UDP to the customer also will block responses to recursive queries that originate from SRC 53/UDP. Which are relatively rare, these days. Any device doing this by default is likely

Re: Thank you, Comcast.

Said in a forum comprised largely of ISPs? Bold move. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Brielle Bruns" To: nanog@nanog.org Sent: Friday, February 26,

Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 11:04:49AM -0500, Curtis Maurand wrote: > I run my own resolver from behind my firewall at my home. I don't > allow incoming port 53 traffic. I realize there's not a lot of > privacy on the net, but I don't like having my dns queries tracked > in order to target

Re: Thank you, Comcast.

There is so much arrogance in these posts saying that these things should be blocked because it's best or because it's negligible. The point of having an open internet is that people are going to have use cases that you haven't even thought of and should not be hindered. Even the reasons you have

RE: Thank you, Comcast.

I don't have a problem with an ISP blocking certain things by default as long as they identify them like Comcast has done especially for consumer service. It would be nice if there was a way to opt out of the protection for the few people that need those services either through a web interface

Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 08:55:20AM -0700, Keith Medcalf wrote: > > On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: > > > FWIW, Comcast's list of blocked ports is at > > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > > ports/. The suspensions this

Re: Thank you, Comcast.

On 2/26/16 10:02 AM, Chris Adams wrote: Except that half the time people run their own DNS resolvers because their provider's resolvers are Resolver != authoritative server. Your local DNS resolver doesn't need to be (and should not be) listening to port 53 on the Internet. Only DNS

RE: Thank you, Comcast.

Also worked fine in IE 11 and Firefox. I didn't change any particular security settings either. Might want to check your stuff before you rant on someone's web site. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett

Re: Thank you, Comcast.

On 2/26/16 10:01 AM, Mike Hammett wrote: They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. As long as the profit from doing shady things and lying is greater then the cost of settling a lawsuit, companies

Re: Thank you, Comcast.

This small audience also consists of predominately people that administer networks and would be doing such things. I'll be you'll find a vastly different percentage of the Cross Stitch Operators Group even know what DNS is, much less have any desire to change it. - Mike Hammett

Re: Thank you, Comcast.

Once upon a time, Brielle Bruns said: > >I'm fine with that. Residential customers shouldn't be running DNS > >servers anyway and as far as the outside resolvers to go, e... I > >see the case for OpenDNS given that you can use it to filter (though > >that's easily bypassed),

Re: Thank you, Comcast.

They have to be honest or face litigation. Transparency is the biggest (if not the only) useful thing out of the Open Internet Order. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From:

Re: Thank you, Comcast.

On 26 Feb 2016, at 23:44, Blake Hudson wrote: Jason, how do you propose to block SSDP without also blocking legitimate traffic as well (since SSDP uses a port > 1024 and is used as part of the ephemeral port range on some devices) ? I'm not Jason, but blocking specific port-pairs such as

Re: Thank you, Comcast.

I disagree...the point of what I sent (missed by some) is that in just this small audience there are many that do/have/know about customers that run their own stuff. Trying to blow it off, or minimize those customers just makes you seem a little arrogant. Nothing worse than an arrogant

Re: Thank you, Comcast.

On 2/26/16 9:15 AM, Mike Hammett wrote: I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS

Re: Thank you, Comcast.

Livingood, Jason wrote on 2/26/2016 9:12 AM: FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very

Re: Thank you, Comcast.

On 26 Feb 2016, at 23:15, Mike Hammett wrote: I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. You'll find a heck of a lot more of them doing so unknowingly, because they're running misconfigured, abusable CPE devices which

Re: Thank you, Comcast.

On 26 Feb 2016, at 23:02, Damian Menscher via NANOG wrote: What I'd much rather see Comcast do is use their netflow to trace the source of the spoofed packets (one of their peers or transit providers, no doubt) and strongly encourage (using their legal or PR team as needed) them to trace

Re: Thank you, Comcast.

I think you'd be hard pressed to find more than a tenth of a percent of people attempt to run their own DNS server. Some do because they think it'll be better in some way. Rare is the occasion where anything user configured would outperform a local DNS server managed by the ISP that does no

Re: Thank you, Comcast.

I run my own resolver from behind my firewall at my home. I don't allow incoming port 53 traffic. I realize there's not a lot of privacy on the net, but I don't like having my dns queries tracked in order to target advertising at me and for annoying failed queries to end up at some

Re: Thank you, Comcast.

On Fri, Feb 26, 2016 at 6:28 AM, Jared Mauch wrote: > As a community we need to determine if this background radiation and these > responses are proper. I think it's a good response since vendors can't do > uRPF at line rate and the major purchasers of BCM switches don't

Re: Thank you, Comcast.

On 2/26/16 7:31 AM, Keith Medcalf wrote: ISP's should block nothing, to or from the customer, unless they make it clear*before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially

Re: Thank you, Comcast.

Thats not really a fair comparison, I think a lot of people have issues with people censoring/controlling/prioritizing internet access to make money. Its a somewhat more nuanced conversation when you are talking about doing the same thing to prevent abuse. Cheers, Max > On Feb 26, 2016, at

RE: Thank you, Comcast.

On Feb 26, 2016 8:34 AM, "Keith Medcalf" wrote: > > > ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection

Re: Thank you, Comcast.

Works fine on a default Chrome installation. *shrugs* - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Keith Medcalf" To: "NANOG list" Cc:

Re: Thank you, Comcast.

On 2/26/16 6:27 AM, Mike Hammett wrote: "you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc." I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go,

RE: Thank you, Comcast.

On Friday, 26 February, 2016 08:13, jason_living...@comcast.com said: > FWIW, Comcast's list of blocked ports is at > http://customer.xfinity.com/help-and-support/internet/list-of-blocked- > ports/. The suspensions this week are in direct response to reported abuse > from amplification attacks,

Re: Thank you, Comcast.

I agree with this...from a customer perspective. I've seen ISPs block other traffic as well...even on "business" accounts, and break their customers networks. It's the Internet not a private network... I've never been a typical user though...maybe one of the "dozen" Mike refers to that

Re: Thank you, Comcast.

> On Feb 26, 2016, at 06:31, Keith Medcalf wrote: > > ISP's should block nothing, to or from the customer, unless they make it > clear *before* selling the service (and include it in the Terms and > Conditions of Service Contract), that they are not selling an Internet >

Re: Thank you, Comcast.

*yawn* I expected this from the news sites selling page views, not NANOG where people are supposed to actually know how things work. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From:

Re: Thank you, Comcast.

FWIW, Comcast's list of blocked ports is at http://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/. The suspensions this week are in direct response to reported abuse from amplification attacks, which we obviously take very seriously. We are in the process of considering

Re: Thank you, Comcast.

On 2/26/16, 8:27 AM, "NANOG on behalf of Mike Hammett" wrote: >"you will also block legitimate return traffic if the >customers run their own DNS servers or use opendns / google dns / etc." > >I'm fine with that. Residential customers

Re: Thank you, Comcast.

And you¹d be correct (about SSDP). ;-) - Jason (Comcast) On 2/25/16, 10:52 PM, "NANOG on behalf of Paras Jha" wrote: >It's interesting that they'd call about DNS amplification... You don't >typically see DNS amplified floods

RE: Thank you, Comcast.

ISP's should block nothing, to or from the customer, unless they make it clear *before* selling the service (and include it in the Terms and Conditions of Service Contract), that they are not selling an Internet connection but are selling a partially functional Internet connection (or a

Re: Thank you, Comcast.

Most of the NTP hosts have been remediated or blocked. Using QoS to set a cap of the amount of SNMP and DNS traffic is a fair response IMHO. Some carriers eg: 7018 block chargen wholesale across their network. We haven't taken that step but it's also something I'm not opposed to. As a

Re: Thank you, Comcast.

I agree, At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren’t the ones using it. If the argument is that you need a Business

Re: Thank you, Comcast.

I'm sure someone smarter than I will chime in here, but I'd say far too much effort\resources for too little tangible results. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Dovid

Re: Thank you, Comcast.

On Fri, 26 Feb 2016, Nick Hilliard wrote: Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random. If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns

Re: Thank you, Comcast.

On 26 Feb 2016, at 20:17, Nick Hilliard wrote: If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc. Actually, what they're talking about is blocking packets

Re: Thank you, Comcast.

On Thursday, February 25, 2016, Mike Hammett wrote: > I know. It seems odd, doesn't it? > > They're actually suspending people's accounts for DNS amplification. My > aunt got a call about it tonight. I had already firewalled that off on her > router before they called, but

Re: Thank you, Comcast.

I had a client with a few boxes that had dns wide open. Couldn't you use snort to match against those specific requests and just drop those packets? Regards, Dovid -Original Message- From: Mike Hammett Sender: "NANOG" Date: Fri, 26 Feb 2016

Re: Standard terminology for a dark fiber path?

+1 on span along with fiber count designation. On Feb 25, 2016 8:52 PM, "Dave Cohen" wrote: > FWIW, at my $dayjob (a fiber-based service provider), the accepted term is > "span", which accounts for any continuous segment between add/drop and/or > regen locations (i.e. no

Re: BGP MVPN RFC6513, Section 10

Hi To support the section §10 in your conf you have two choices: a. (§10.1) implementing the RP on your PE (protocol pim rp local). It will advertises the route type after pim register message (or msdp source active from other RP is you have other rp in your network) + be sure to use spt-only

Re: Thank you, Comcast.

"you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc." I'm fine with that. Residential customers shouldn't be running DNS servers anyway and as far as the outside resolvers to go, e... I see the case for OpenDNS given

Re: Thank you, Comcast.

Mikael Abrahamsson wrote: > Why isn't UDP/53 blocked towards customers? I know historically there > were resolvers that used UDP/53 as source port for queries, but is this > the case nowadays? > > I know providers that have blocked UDP/53 towards customers as a > countermeasure to the

Re: Thank you, Comcast.

I do on my network (well, the ISP, not the IX). It makes complete sense. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mikael Abrahamsson" To: "Jared Mauch"