RE: [Fwd: zone transfers, a spammer's dream?]
www.bl.uk? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stephane Bortzmeyer Sent: 14 December 2004 09:52 To: Gadi Evron Cc: nanog list Subject: Re: [Fwd: zone transfers, a spammer's dream?] On Thu, Dec 09, 2004 at 03:52:38AM +0200, Gadi Evron <[EMAIL PROTECTED]> wrote a message of 174 lines which said: > 171 uk.zone Everything is in subdomains like co.uk, so there is no point in blocking zone transfers for the TLD. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: Cogent service
I corrected myself to note this figure was us not ns (but I don't see that post yet). When you say 1-2 ms added under load do you mean CPU load or circuit load? Remember anytime the router has to buffer packets you are going to see delay (unless you use a QoS mechanism - but that's a whole other thread). Your example appears to backup my post - when you go a long way around (despite the numbers of routers involved) it takes longer to get there than the short route, but this isn't the routers making it slow, its the distance. Matt. -Original Message- From: David Diaz [mailto:[EMAIL PROTECTED]] Sent: 20 September 2002 18:35 To: Matt Ryan; William B. Norton; Ralph Doncaster; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Cogent service I dont believe that number at all. Not to disagree with you at all Matt. But real world, it would depend on the design. If you are going router to router then it would be closer to accurate. I have seen 1-2ms added per router under load. That also might factor in a hop inside the room between 1 routers or another gear and a router. Coming in one card, having to do a lookup, going out another card to another box then out the layer 1 circuit to the next city. A VPN might not save this time though. But hubbing to a regional center, and then placing this traffic on an express circuit to the next regional city might save some of these ms. In other words LA to San Fran, an express fiber route to Chi, then out a peering connection. This would save 5-8ms compared to LA, San Fran, Portland, Salt Lake, Chi where at each hope 1-2 routers would insert themselves into the process. In my book, 5-8ms is not a real factor Dont get me started on speed of light on fiber... At 18:21 +0100 9/20/02, Matt Ryan wrote: >>The hop count question is interesting. Is the consensus that it's >>mostly a customer service issue, where latency isnt affected but >>customer perception is? Or is it a real latency issue as more >>routers take a few CPU cycles to make a routing decision. > >The routers these days make a forwarding decision in ~20 ns - its going to >take a few hops before this becomes significant. Speed of light on long >links is a couple of orders of magnitude more delay inducing. > > >Matt. > >--- --- >Live Life in Broadband >www.telewest.co.uk > > >The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential and/or >privileged material. >Statements and opinions expressed in this e-mail may not represent >those of the company. Any review, retransmission, dissemination or >other use of, or taking of any action in reliance upon, this >information by persons or entities other than the intended recipient >is prohibited. If you received this in error, please contact the >sender immediately and delete the material from any computer. > > >=== === -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: Economic Justification / Rationale for MPLS
Whatever the relative technical merits of MPLS/BGP VPNs over other layer 3 VPNs (GRE, IPsec, L2TP etc) there are many service providers around the world selling these services. There is clearly a business need for them, and obviously customers how will buy them (well, we have managed to sell them anyway!), so there is an economic reason to deploy MPLS. Layer 2 based LAN extension services will only extend this market further and again uses MPLS as its base transport mechanism. Matt. -Original Message-From: Shannon Lake [mailto:[EMAIL PROTECTED]]Sent: 01 October 2002 08:26To: [EMAIL PROTECTED]Subject: Economic Justification / Rationale for MPLS Ladies and Gentlemen: I have been conducting research looking for the economic justification for MPLS. I have some feedback, but sound rationale from the industry has eluded me thus far. I am looking for a paper, website, etc that explains the benefits of implementing MPLS (other than technical) or gives some economic modeling for MPLS-based networks. Any help, reasoning, rationale or personal insights/views would be greatly appreciated. Thanks in advance, Shannon M. Lake Sr. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: Blackhole Routes
Something like http://www.cisco.com/en/US/products/ps5888/index.html? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Stewart Sent: 01 October 2004 08:23 To: Eric Germann; [EMAIL PROTECTED] Subject: Re: Blackhole Routes On Thu, 30 Sep 2004 10:35:36 -0400, Eric Germann <[EMAIL PROTECTED]> wrote: > What I would to see (and have never researched in depth) is a way to apply > the blackhole routes on a community to port basis (i.e. we set up a specific > BGP community to filter mail, and that community goes to a route map that > kills only port 25, another community applies to a map that kills port 80, A not particularly scalable method of doing that, which should be ok for small data flows, is to set up routers port25killer.example.net, a port80killer.example.net, etc., with ACLs that block those ports regardless of address, use BGP or OSPF to advertise whichever IP address spaces should be routed there, and set up those machines in whatever sort of firewalling location makes sense. It's more of an enterprise solution than an ISP solution, but if you're a small ISP or dealing with a relatively specific set of problem sites you could probably do it. You may need to burn some CPE on GRE tunnels, depending on your topology, but if you're trying to solve a limited problem like letting your users access Korean web sites while blocking Korean email, it may work. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: BitTorrent is 35% of traffic ?
Cachelogic put appliances into the network that both monitor traffic (semi-deep packet inspection) and also cache P2P content to take the load of your network. While I don't think they made the figures up it's worth bearing in mind they are selling a 'solution' to the problem they highlight. For the record we have seen P2P traffic over 50% of our bandwidth utilisation - if bittorrent is the largest proportion then it could reach 35% of total bandwidth. Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Deepak Jain Sent: 04 November 2004 21:09 To: [EMAIL PROTECTED] Subject: BitTorrent is 35% of traffic ? http://in.tech.yahoo.com/041103/137/2ho4i.html According to Reuters, BT is more traffic than web/other forms of traffic? I'm thinking the sampling methodology here might be a little skewed. Then again, I could be biased. Any other facts that would support this? DJ -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: OpenSSL
MPLS (on its own) gives you jack-squat in terms of delay and jitter. All the clever queuing can do it for you - but then it can for IP (because its the same thing!). Matt. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: 18 March 2003 15:10 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL > > While the timing attack is the attack against the SSL server, it is my > reading of the paper that the attacks' success largely depends on ability to > tightly control the time it takes to communicate with a service using SSL. > Currently, such control is rather difficult to achive on links other than > ethernet. > Doesn´t MPLS provide consistent delay and minimal jitter and thus SSL servers connected to MPLS networks are more suspectible to attack? :-) Pete -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: OpenSSL
lol - I promise in future to read to the bottom of messages. In fact if I didn't top post I would have noticed, but that's a different can of worms 8-) Matt. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: 18 March 2003 17:52 To: Matt Ryan; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL Note the smiley 10 lines down. You have been had. Pete - Original Message ----- From: "Matt Ryan" <[EMAIL PROTECTED]> To: "'Petri Helenius'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 18, 2003 5:58 PM Subject: RE: OpenSSL MPLS (on its own) gives you jack-squat in terms of delay and jitter. All the clever queuing can do it for you - but then it can for IP (because its the same thing!). Matt. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: 18 March 2003 15:10 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL > > While the timing attack is the attack against the SSL server, it is my > reading of the paper that the attacks' success largely depends on ability to > tightly control the time it takes to communicate with a service using SSL. > Currently, such control is rather difficult to achive on links other than > ethernet. > Doesn´t MPLS provide consistent delay and minimal jitter and thus SSL servers connected to MPLS networks are more suspectible to attack? :-) Pete -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: CIsco 7206VXR w/NPE-G1 Question
Do you get commission from Juniper? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 16:51 Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: "Nachi" worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. -alex On Fri, 30 Jan 2004 [EMAIL PROTECTED] wrote: > > Does anyone have definitive speed results on the 3 "built-in" Gig ports > on the NPE-G1? I know that they aren't attached to the PCI Buses, and > don't consume bandwidth points, but all of that is mute. Can all three > of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I > have seen posts that allude to the fact the max throughput on the 3 Gigs > are 800Mbps. It's is like a big mystery that cannot be solved. With a > "J" M7i, I know I'm going to get line rate per port up to the total > forwarding capacity of the FPC. > > We are trying to create a comparison matrix and any info you have would > be great. > > Jack > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Simon Hamilton-Wilkes > Sent: Friday, January 30, 2004 9:36 AM > To: [EMAIL PROTECTED] > Subject: RE: CIsco 7206VXR w/NPE-G1 Question > > > > One more interesting feature - if you need a 4th GigE port, you can add > the GigE I/O card which still uses none of the bus bandwidth points. > The buses are fine for OC3 and below... > > > Simon > > ** > The information contained in this message, including attachments, may contain > privileged or confidential information that is intended to be delivered only to the > person identified above. If you are not the intended recipient, or the person > responsible for delivering this message to the intended recipient, ALLTEL requests > that you immediately notify the sender and asks that you do not read the message or its > attachments, and that you delete them without copying or sending them to anyone else. > -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: CIsco 7206VXR w/NPE-G1 Question
It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. Matt. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 17:43 To: Matt Ryan Cc: [EMAIL PROTECTED] Subject: Re: CIsco 7206VXR w/NPE-G1 Question Matt Ryan wrote: >Do you get commission from Juniper? > > > Where do I get my comission then? I´ve described inferior product as such many times and so far I haven´t seen deposits from vendors in my bank account? !!OT warning!! Pete -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: CIsco 7206VXR w/NPE-G1 Question
The Juniper software is great, very stable under testing (for 2 weeks in the lab). But as with all routers there are pro's and con's and it also has some issues. What is unfortunate is that the poster runs (by their own admission) neither Cisco or Juniper in their network and yet make unfounded claims about the performance of the Juniper under any conditions. Clearly this will never be true as the cost of developing such a box would be prohibitive and the delivery timescales far too long. I'm as happy as the next person to give Cisco a bashing but I also like to see some balance when unrealistic claims are made. Matt. -Original Message- From: Alex Yuriev [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 14:45 To: Matt Ryan Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question > It's not the Cisco bashing I was referring to, but the all singing all > dancing Juniper performance claim. That would not have anything to do with Juniper sucking the least? Alex -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: Firewall opinions wanted please
Depending on your chosen vendor the ACL cost is unlikely to be $0 - if you steal CPU cycles from packet forwarding then you incur earlier router upgrade costs and that has a NPV cost increase associated with it. It's just not as obvious as a invoice for a firewall. Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eric Gauthier Sent: 17 March 2004 17:20 To: [EMAIL PROTECTED] Subject: Re: Firewall opinions wanted please > > _Everyone_ (network connected) should have a firewall. My grandma should > > have a firewall. Nicole, holding dominion over this business network and > > its critical infrastructure, should _definitely_ have a firewall. ;) By "firewall", do you mean "dedicated unit that does statefull filtering" or just "something that will block packets"? We've successfully argued to just about every group here at our University who came to us asking for a "firewall" that, given what they wanted to achieve, they could accomplish the same thing with simple ACLs... I'm sure that the cost of the ACL's (i.e. $0.00) versus the cost of a firewall also helped them in their decision... Eric :) -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
