comcast business service

A while ago I got Comcast's business service. Semi-idle connections are get dropped (I haven't really diagnosed this - I just no that it isn't the client or server but some network in between). However the second and most obvious issue is that intermittently, the service will grind to a halt: --- 8

Re: VMware Training

It means your VMs can run on any host and access the files it requires. If this was not the case then you could not tolerate a hardware failure and expect your VMs to survive. It also means you can do things like evacuate a host and take it down for maintenance. Of course you could build your appl

Re: VMware Training

On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth wrote: > - Original Message - > > From: "Eugeniu Patrascu" > > > If you want block storage, just export an iSCSI device to the ESXi > machines > > (tgtadm on RedHat is all you need and a few gigs of free space). VMFS is > > cluster aware so

Re: spamassassin

Le 2014-02-19 21:48, Randy Bush a écrit : > as the fix is not yet out, would be cool if someone with more fu than i > posted a recipe to hack for the moment. The fix is out now! :D Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source--> http

RE: "Everyone should be deploying BCP 38! Wait, they are ...."

> Actually, it would be nice if someone who writes security software > like NOD32 or Malwarebytes, or spybot, adaware, etc, would > integrate it into their test suite. Then you get the thousands of > users from them added to the results. I have just sent an email to ESET promoting participatio

level3_bx4-montrealak.net consistently dropping 50% of the packets

Hello Everyone, According to mtr command we are consistently seeing level3_bx4-montrealak.net dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get this resolved are greatly appreciated. HOST: victoriaLoss% Snt Last Avg Best Wrst StDev 1.|-- 19

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

| Since you dont see packet loss on the subsequent hops, this is likely just ICMP rate limiting on the control plane. MTR | sends quite a bit of ICMP so this is very common when using MTR. Not a "possible" reason for the degradation of voip from us to our service provider? Is there a more accurat

Re: comcast business service

On Feb 20, 2014, at 4:08 AM, shawn wilson wrote: > A while ago I got Comcast's business service. Semi-idle connections > are get dropped (I haven't really diagnosed this - I just no that it > isn't the client or server but some network in between). However the > second and most obvious issue is

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

On 2/20/2014 6:08 PM, Nick Cameo wrote: > According to mtr command we are consistently seeing > level3_bx4-montrealak.net > dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get > this resolved are greatly appreciated. It's dropping packets _to_ and/or _from_ it. Seem it's go

Re: NTP DRDos Blog post

* st...@ntp.org (Harlan Stenn) [Thu 20 Feb 2014, 00:38 CET]: I'd love to hear any feedback about the post. Don't invent new terms like DrDos. -- Niels.

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

There are reports of problems in Montreal with several other providers over the last several days. These seem to coincide with the Olympics live broadcasts, particularly during the hockey broadcasts. -- Stephen On 2014-02-20 10:08 AM, Nick Cameo wrote: Hello Everyone, According to mtr comma

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:14 PM, Niels Bakker wrote: > Don't invent new terms like DrDos. +1 --- Roland Dobbins // Luck is the residue of opportunity and design.

Re: NTP DRDos Blog post

That's not a new term. http://en.wikipedia.org/wiki/DRDOS DRDoS, a type of network attack named Distributed Reflection Denial of Service. http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack On 2/20/2014 11:14 AM, Niels Bakker wrote: * st...@ntp.o

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:23 PM, Brian Rak wrote: > That's not a new term. It isn't used by folks involved in operational security. It's a marketing term. --- Roland Dobbins // Luck is

Re: NTP DRDos Blog post

On Thu, 20 Feb 2014, Brian Rak wrote: That's not a new term. http://en.wikipedia.org/wiki/DRDOS DRDoS, a type of network attack named Distributed Reflection Denial of Service. http://en.wikipedia.org/wiki/Distributed_Reflection_Denial_of_Service#Reflected_.2F_Spoofed_attack Or Digital Resea

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

A careful reading of the following fixes this issue every time it occurs. I guarantee it. https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf On Thu, Feb 20, 2014 at 10:08 AM, Nick Cameo wrote: > Hello Everyone, > > According to mtr command we are consistently

Re: NTP DRDos Blog post

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:34 AM, Dobbins, Roland wrote: > > On Feb 20, 2014, at 11:23 PM, Brian Rak wrote: > >> That's not a new term. > > It isn't used by folks involved in operational security. It's a marketing > term. > I'll split the difference, folks in operational security dislike the

question about AS relationship

Hi everyone, I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that? Thanks! -- Sky Li

Re: random dns queries with random sources

Masataka Ohta necom830.hpcl.titech.ac.jp> writes: > > Joe Maimon wrote: > > > What is the purpose of this? ... > > Masataka Ohta > Hi guys, for a second, have you any clue how to block this traffic on DNS server side? As our company operates recu

prefix advertisement

Can someone from Comcast BGP team contact me off list? I am seeing AS 33491 advertising one of our prefixes. Thanks -Ben

RE: NTP DRDos Blog post

Yes, it was also used here https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 But still, it's just a DDoS. -Message d'origine- De : Brian Rak [mailto:b...@gameservers.com] Envoyé : jeudi 20 fé

Re: question about AS relationship

On Thu, Feb 20, 2014 at 3:14 AM, Song Li wrote: > Hi everyone, > > I have one simple question: as for AS relationship, should customer tell its > provider the AS# of its own customers, or the provider have the right to > require its customers to do that? in an ideal world the ISP is filtering pre

Re: "Everyone should be deploying BCP 38! Wait, they are ...."

- Original Message - > From: "Adam Vitkovsky" > > Actually, it would be nice if someone who writes security software > > like NOD32 or Malwarebytes, or spybot, adaware, etc, would > > integrate it into their test suite. Then you get the thousands of > > users from them added to the result

Re: VMware Training

- Original Message - > From: "Eugeniu Patrascu" > On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth > wrote: > > > - Original Message - > > My understanding of "cluster-aware filesystem" was "can be mounted at the > > physical block level by multiple operating system instances with

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:29 PM, wrote: > Yes, it was also used here > https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-prevention-monitoring-mitigation-techniques-service-provider-enviro-1212 That's still meaningless. The term of art is 'reflection/amplification attac

Re: NTP DRDos Blog post

- Original Message - > From: "Roland Dobbins" > On Feb 20, 2014, at 11:14 PM, Niels Bakker > wrote: > > > Don't invent new terms like DrDos. > > +1 What? Digital Research's MS-DOS clone is attacking things? Cheers, -- jr ':-)' a -- Jay R. Ashworth Baylink

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

Makes even more sense when you're a CS student working on getting your PPL ;) N.

Re: VMware Training

On Thu, Feb 20, 2014 at 8:16 PM, Jay Ashworth wrote: > - Original Message - > > From: "Eugeniu Patrascu" > > > On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth > > wrote: > > > > > - Original Message - > > > My understanding of "cluster-aware filesystem" was "can be mounted at > t

Re: VMware Training

On Wed, Feb 19, 2014 at 9:46 PM, Jay Ashworth wrote: > Why bother with a clustering FS, then, if you cannot actually /use it/ as > one? > It is used as one.It is also a lot more convenient to have a shared filesystem, than a distributed volume manager. You could think of VMDK files on a VM

Re: VMware Training

[See below] On Feb 19, 2014, at 10:46 PM, Jay Ashworth wrote: > Why bother with a clustering FS, then, if you cannot actually /use it/ as one? > - jra > > On February 19, 2014 10:44:22 PM EST, Jimmy Hess wrote: >> On Wed, Feb 19, 2014 at 2:06 PM, Jay Ashworth wrote: >> >>> - Original Me

Re: question about AS relationship

On Thu, Feb 20, 2014 at 3:14 AM, Song Li wrote: > I have one simple question: as for AS relationship, should customer tell its > provider the AS# of its own customers, or the provider have the right to > require its customers to do that? Um... you DO tell your provider the AS numbers of your cust

Re: spamassassin

--As of February 20, 2014 11:22:34 AM +0800, Randy Bush is alleged to have said: http://www.gossamer-threads.com/lists/spamassassin/users/183433 as blabby as nanog, and not really specific body BAYES_99 eval:check_bayes('0.99', '0.999') body BAYES_999 eval:check_bayes('0.999', '1.00') score

Re: NTP DRDos Blog post

On 2/20/2014 9:17 AM, Jared Mauch wrote: I'll split the difference, folks in operational security dislike the term as they feel it's inaccurate. They tend to think it's marketing vs operational related. Reflection attacks are considered a sub-type of DoS/DDoS and do not require a new term. I

Re: NTP DRDos Blog post

On Feb 21, 2014, at 2:37 AM, John wrote: > This is not a new term (certainly >12yo) Actually, it's much more recent than that (in this context; as others have mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone). But I'm going to stop posting about this, now, as Jared sugge

Re: VMware Training

On Feb 20, 2014, at 1:48 PM, Jimmy Hess wrote: > The locking restrictions are for your own protection. If the filesystem > inside your virtual disks is not a clustered filesystem; > two instances of a VM simultaneously mounting the same NTFS volume and > writing some things, is an absolute dis

Re: NTP DRDos Blog post

On 2/20/2014 11:43 AM, Dobbins, Roland wrote: Actually, it's much more recent than that (in this context; as others have mentioned, DR-DOS was the acronym for Digital Research's MS-DOS clone). I didn't just pluck that 12y term out of the air. I know how much Gibson is hated in some circles, b

Re: NTP DRDos Blog post

On Feb 20, 2014, at 11:43 AM, Jon Lewis wrote: > On Thu, 20 Feb 2014, Brian Rak wrote: > >> That's not a new term. >> >> http://en.wikipedia.org/wiki/DRDOS >> DRDoS, a type of network attack named Distributed Reflection Denial of >> Service. >> http://en.wikipedia.org/wiki/Distributed_Reflect

Re: NTP DRDos Blog post

On Feb 21, 2014, at 2:51 AM, John wrote: > I know how much Gibson is hated in some circles, He isn't/wasn't part of the operational community. It sure looks like you're right, he coined it then - as a marketing term, for marketing himself, heh. Maybe that's one of the reasons it's so disli

Re: VMware Training

On Thu, Feb 20, 2014 at 9:49 PM, Dan Shoop wrote: > > On Feb 20, 2014, at 1:48 PM, Jimmy Hess wrote: > > > The locking restrictions are for your own protection. If the filesystem > > inside your virtual disks is not a clustered filesystem; > > two instances of a VM simultaneously mounting the

Re: comcast business service

If it's one of their new Netgear-branded modems, see if you can get your tech to dig up an SMC. We had the same issue. They swapped out one Netgear modem for another Netgear and the problem continued. The phone techs couldn't see the problem and kept blaming our equipment. They finally sent out

Re: comcast business service

Thanks. The tech said they looked at signal levels when I called and didn't see anything. I didn't have a baseline at the time (I do now) and assumed they'd see something there if there was something. I do have the Netgear. So I'll keep this in mind when I call them again (assuming it's really not

Filter NTP traffic by packet size?

Curious if anyone else thinks filtering out NTP packets above a certain packet size is a good or terrible idea. >From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP server. If I query a server for it's list of peer

Re: Filter NTP traffic by packet size?

On 2/20/2014 12:41 PM, Edward Roels wrote: Curious if anyone else thinks filtering out NTP packets above a certain packet size is a good or terrible idea. From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are typical for a client to successfully synchronize to an NTP serve

Re: Filter NTP traffic by packet size?

On Feb 20, 2014, at 3:51 PM, John Weekes wrote: > On 2/20/2014 12:41 PM, Edward Roels wrote: >> Curious if anyone else thinks filtering out NTP packets above a certain >> packet size is a good or terrible idea. >> >> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are >>

Re: Filter NTP traffic by packet size?

Filtering will always break something. Filtering 'abusive' network traffic is intentionally difficult - you either just let it be, or you filter it along with the 'good' network traffic that it's pretending to be. How can you even tell it's NTP traffic - maybe by the port numbers? What if som

Re: comcast business service

On Feb 20, 2014, at 4:08 AM, shawn wilson wrote: > A while ago I got Comcast's business service. Semi-idle connections > are get dropped (I haven't really diagnosed this - I just no that it > isn't the client or server but some network in between). However the > second and most obvious issue is

Re: comcast business service

They often say everything looks okay. I can recall one conversation where the tech said he was talking to my modem and there were no problems all the way to it. I replied that it was unplugged in my hand because I had done so to read the serial number to him, so he couldn't be talking to it. Servic

Re: Filter NTP traffic by packet size?

On Feb 20, 2014, at 4:05 PM, Laszlo Hanyecz wrote: > Filtering will always break something. Filtering 'abusive' network traffic > is intentionally difficult - you either just let it be, or you filter it > along with the 'good' network traffic that it's pretending to be. How can > you even t

Re: prefix advertisement

Did someone get back to you on this yet? If not, let me know. Thanks, John On Thu, Feb 20, 2014 at 7:28 AM, Russell, Ben < ben.russ...@countryfinancial.com> wrote: > Can someone from Comcast BGP team contact me off list? I am seeing AS > 33491 advertising one of our prefixes. > > Thanks > > -B

Re: question about AS relationship

On Thu, 20 Feb 2014 03:14:59 -0500, Song Li wrote: I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that? (Having been on both ends of this...) If you want me t

Re: NTP DRDos Blog post

Hello Harlen , On Wed, 19 Feb 2014, Harlan Stenn wrote: Folks, I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . wget http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ --2014-02-20 15:03:13-- http://nwtime.org/ntp-winter-2013-network-drdos-attacks/

Re: spamassassin

I'm going to forward on what's probably a 'final disposition' post on this below. Note the behavior of the BAYES_999 rule is going to change dramatically. (It will be *in addition* to the BAYES_99 rule, instead of replacing it for messages with the appropriate bayes score.) From: "Kevin A.

Re: NTP DRDos Blog post

I was seeing database connect errors earlier. I suspect the host resources are limited. Jared Mauch > On Feb 20, 2014, at 7:05 PM, "Mr. James W. Laferriere" > wrote: > >Hello Harlen , > >> On Wed, 19 Feb 2014, Harlan Stenn wrote: >> Folks, >> I just posted http://nwtime.org/ntp-winter-2

Re: Filter NTP traffic by packet size?

On 2/20/14, 3:41 PM, "Edward Roels" wrote: >Curious if anyone else thinks filtering out NTP packets above a certain >packet size is a good or terrible idea. > >From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 >are >typical for a client to successfully synchronize to an NTP

Re: NTP DRDos Blog post

On 2/20/2014 7:05 PM, Mr. James W. Laferriere wrote: > Hello Harlen , > > On Wed, 19 Feb 2014, Harlan Stenn wrote: >> Folks, >> I just posted http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ . > wget http://nwtime.org/ntp-winter-2013-network-drdos-attacks/ > --2014-02-20 15:03:13

Re: random dns queries with random sources

On 02/20/2014 08:57 AM, Pavel Zeleny wrote: Masataka Ohta necom830.hpcl.titech.ac.jp> writes: Joe Maimon wrote: What is the purpose of this? ... Masataka Ohta Hi guys, for a second, have you any clue how to block this traffic on DNS server

Re: question about AS relationship

On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote: > so, yes. pleass tell your upstream your customers so > proper filtering can be automated and implemented. > > don't turn up bgp customers without filtering, that kills > kittens. For all the leaking I've seen in the last fo

Re: question about AS relationship

On Friday, February 21, 2014 12:25:33 AM Ricky Beam wrote: > NOBODY should be blindly accepting routing information > from ANYONE, EVER. That's how people appropriate address > space. The reality is that this is (still) happening. Mark. signature.asc Description: This is a digitally signed mes

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 3:41 AM, Edward Roels wrote: > From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are > typical for a client to successfully synchronize to an NTP server. Correct. 90 bytes = 76 bytes + Ethernet framing. Filtering out packets this size from UDP/anythi

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 9:55 AM, Dobbins, Roland wrote: > Filtering out packets this size from UDP/anything to UDP/123 allows time-sync > requests and responses to work, but squelches both the level-6/-7 commands > used to trigger amplification as well as amplified attack traffic. Also, the rever

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 9:55 AM, Dobbins, Roland wrote: > Filtering out packets this size from UDP/anything to UDP/123 allows time-sync > requests and responses to work, but squelches both the level-6/-7 commands > used to trigger amplification as well as amplified attack traffic. That should rea

Re: spamassassin

> The correct score has been pushed, as Simon Perreault mentioned. Taking > out anything you've done and running sa-update should get you a working > ruleset. thank you randy

Re: Filter NTP traffic by packet size?

Type Enforcement in the OS Kernel is the place to do that. Todd On 2/20/2014 2:12 PM, Damian Menscher wrote: On Thu, Feb 20, 2014 at 1:03 PM, Jared Mauch wrote: On Feb 20, 2014, at 3:51 PM, John Weekes wrote: On 2/20/2014 12:41 PM, Edward Roels wrote: Curious if anyone else thinks filter

Re: Filter NTP traffic by packet size?

On Feb 21, 2014, at 11:40 AM, Harlan Stenn wrote: > As a reality check, with this filtering in place does "ntptrace" still work? No, it will not. In order to minimize overblocking of this nature, filtering of this nature should be used with the highest possible degree of granularity, and the

Re: question about AS relationship

Thanks. In order to prevent route leaking, this imformation should be provided to providers. but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private? -- Sky Li On Thursday, February 20, 2014 08:09:35 PM Christo

Re: question about AS relationship

On Friday, February 21, 2014 07:37:52 AM Song Li wrote: > Thanks. In order to prevent route leaking, this > imformation should be provided to providers. Route leaking is not only from customers-to-providers. It can also be from providers-to-providers (and from peers-to- peers). The majority of

Re: question about AS relationship

On Fri, Feb 21, 2014 at 12:37 AM, Song Li wrote: > Thanks. In order to prevent route leaking, this imformation should be > provided to providers. > > but another question, should the AS relationships between customer and its > other neighbors (downstrem/peer/another provider) be private? > perha

Re: question about AS relationship

+--+ +-+ | provider1| |provider2| +--+ +-+ ^ ^ | | | | ++ ++---+++--+ |peer AS2+-