Trojan poses as Lycos Europe screensaver
This article made coffee come out of my nose. :-) - ferg http://news.com.com/Trojan+poses+as+Lycos+Europe+screen+saver/2100-7349_3-5481674.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Halo 2 and broadband traffic
Has anyone actually noticed any increases in residential broadband traffic due to Halo 2? - ferg http://news.com.com/Does%20the%20Halo%202%20effect%20threaten%20broadband/2100-1034_3-5481727.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Halo 2 and broadband traffic
Heya, > Has anyone actually noticed any increases in residential > broadband traffic due to Halo 2? > > http://news.com.com/Does%20the%20Halo%202%20effect%20threaten%20broadband/2100-1034_3-5481727.html Here's a really useless datapoint for you :) We have about 12,000 students in our dorms. Because we force students to register their computers via the Web and the XBox/PS2's don't appear to have web browsers, we have somewhat of a handle on who many are in use on campus. We've generally average about four or five new XBox/PS2's per month over the past year but we registered 12 in November (all were on or after 11/9). We're also tracking down another five to ten hosts that we believe are also XBox/PS2s. There were three more registered so far in December. Obviously, this doesn't include any gaming systems that sit behind NAT-boxes. Overall, we typically move around 190/230bbps inbound/outbound from our campus and we've seen no real noticable change in our bandwidth. We do have a few peer-to-peer limiters in the network, so its also possible that the gaming systems are being caught in there. Eric :)
RE: Halo 2 and broadband traffic
I doubt Halo 2 would show anything on most stats as its relatively low bandwidth. However, Half-Life 2 I believe did for some larger residential operators. Many moons ago when Doom 2 was released we busied out modems so we could get more bandwidth over to the US to get it downloaded quicker though. Pizza Hut and Doom Deathmatches on the LAN :-) Regards, Neil. [Transit capacity was 256kb/sec [yes k] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Gauthier > Sent: 08 December 2004 16:09 > To: Fergie (Paul Ferguson) > Cc: [EMAIL PROTECTED] > Subject: Re: Halo 2 and broadband traffic > > > Heya, > > > Has anyone actually noticed any increases in residential broadband > > traffic due to Halo 2? > > > > > http://news.com.com/Does%20the%20Halo%202%20effect%20threaten%20broadb > > and/2100-1034_3-5481727.html > > Here's a really useless datapoint for you :) > > We have about 12,000 students in our dorms. Because we force > students to register their computers via the Web and the > XBox/PS2's don't appear to have web browsers, we have > somewhat of a handle on who many are in use on campus. > We've generally average about four or five new XBox/PS2's per > month over the past year but we registered 12 in November > (all were on or after 11/9). > We're also tracking down another five to ten hosts that we > believe are also XBox/PS2s. There were three more registered > so far in December. Obviously, this doesn't include any > gaming systems that sit behind NAT-boxes. > > Overall, we typically move around 190/230bbps > inbound/outbound from our campus and we've seen no real > noticable change in our bandwidth. We do have a few > peer-to-peer limiters in the network, so its also possible > that the gaming systems are being caught in there. > > Eric :) >
Peering best practices advice needed.
Hi all, Please forgive the simplistic nature of the query.. Basically my company is multi-homed with 2 different providers in the UK, and advertising a /18. Now some colleaguges in another part of the world want to break that /18 into two /19's and advertise one /19 and we advertise the other. This is fine, however we are NOT running IBGP in the core, therefore the UK customers in the /19 will not be able to reach the other /19 as there would be a loop detected through EBGP. Now someone mentioned that we could use AS-LOOP-IN feature which will overcome this problem and allow us to route to each other via EBGP. I really think this is a bad idea but until we get an internal link - I dont see a way forward. So... anyone doing this currently in their network or have any "best practices" way round this. I want our company to be good Netizens but still be able to pass traffic between the 2 /19's. Any help would be greatly appreciated. Rolo ! _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
Re: Halo 2 and broadband traffic
> Overall, we typically move around 190/230bbps inbound/outbound from our campus Oops.. that should read 190/230Mbps... Eric :)
Re: Peering best practices advice needed.
Rolo Tomassi wrote: Hi all, Please forgive the simplistic nature of the query.. Basically my company is multi-homed with 2 different providers in the UK, and advertising a /18. Now some colleaguges in another part of the world want to break that /18 into two /19's and advertise one /19 and we advertise the other. This is fine, however we are NOT running IBGP in the core, therefore the UK customers in the /19 will not be able to reach the other /19 as there would be a loop detected through EBGP. Pardon my simplistic solution, try dropping the /18, and -only- advertise the corresponding /19 from each region. Now someone mentioned that we could use AS-LOOP-IN feature which will overcome this problem and allow us to route to each other via EBGP. I really think this is a bad idea but until we get an internal link - I dont see a way forward. So... anyone doing this currently in their network or have any "best practices" way round this. I want our company to be good Netizens but still be able to pass traffic between the 2 /19's. See above. K.I.S.S. (No offense intended ;) Any help would be greatly appreciated. Rolo ! _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
Re: Peering best practices advice needed.
On Dec 8, 2004, at 12:56 PM, Richard Irving wrote: Please forgive the simplistic nature of the query.. Actually, it is refreshing to see _operational_ questions on the list. :-) Basically my company is multi-homed with 2 different providers in the UK, and advertising a /18. Now some colleaguges in another part of the world want to break that /18 into two /19's and advertise one /19 and we advertise the other. This is fine, however we are NOT running IBGP in the core, therefore the UK customers in the /19 will not be able to reach the other /19 as there would be a loop detected through EBGP. Pardon my simplistic solution, try dropping the /18, and -only- advertise the corresponding /19 from each region. This will only work if you have separate ASNs, which would be my suggested solution. In fact, even if you announce the /18 + both /19s, as long as each site as a separate ASN, it will work. If they must have the same ASN for some reason, have your upstreams send you default route as well as a full table. You will not see the "other" /19, but you will send traffic to the upstream because of the default and they will route it properly. Now someone mentioned that we could use AS-LOOP-IN feature which will overcome this problem and allow us to route to each other via EBGP. I really think this is a bad idea but until we get an internal link - I dont see a way forward. So... anyone doing this currently in their network or have any "best practices" way round this. I want our company to be good Netizens but still be able to pass traffic between the 2 /19's. I've never used AS-LOOP-IN. Sorry. :( But I have used the above solution (and static defaults), and it works fine. -- TTFN, patrick
RE: Halo 2 and broadband traffic
At 4:27 PM + 12/8/04, Neil J. McRae wrote: I doubt Halo 2 would show anything on most stats as its relatively low bandwidth. In addition, there were (until Halo 2 came out) large numbers of users playing Halo 1 on mac/windows/xbox. Halo 2 is xbox only, and Halo one traffic has dropped off. If anything, I would guess there is less related traffic rather then more. This is my professional opinion as a mac Halo 1 participant ;-) -Tom
Re: Peering best practices advice needed.
Hi there, If I understand your predicament correctly, our company has a similar situation. We have two locations from which we need to advertise routes from our AS, but our internal link between these two locations is a very high cost satellite link. This means we can not afford to advertise our whole IP allocation equally from both locations. We have a /19 allocated, and we advertise both the /19 from each location, and the more specific /20 particular to each location. To circumvent the loop detection, we use the hidden Cisco command, neighbour x.x.x.x allow-as in. This allows each location to accept the remote's advertised /20 to be inserted into the routing table. Should connectivity ever be lost across the public networks in between, there is a higher cost static route over the satellite link. Perhaps in a more complex and more meshed AS, this loop dodging would be a bad thing(tm). In our simple two location, semi-discontiguous network layout, it has been a problem-free solution. Hope this helps in some way. Regards, Graham Blake SSI Micro Network Services At 10:03 AM 08/12/2004, Rolo Tomassi wrote: Hi all, Please forgive the simplistic nature of the query.. Basically my company is multi-homed with 2 different providers in the UK, and advertising a /18. Now some colleaguges in another part of the world want to break that /18 into two /19's and advertise one /19 and we advertise the other. This is fine, however we are NOT running IBGP in the core, therefore the UK customers in the /19 will not be able to reach the other /19 as there would be a loop detected through EBGP. Now someone mentioned that we could use AS-LOOP-IN feature which will overcome this problem and allow us to route to each other via EBGP. I really think this is a bad idea but until we get an internal link - I dont see a way forward. So... anyone doing this currently in their network or have any "best practices" way round this. I want our company to be good Netizens but still be able to pass traffic between the 2 /19's. Any help would be greatly appreciated. Rolo ! _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
Re: Halo 2 and broadband traffic
On Wed, Dec 08, 2004 at 02:46:46PM +, Fergie (Paul Ferguson) wrote: > > > Has anyone actually noticed any increases in residential > broadband traffic due to Halo 2? This is lost in the noise of P2P traffic, which is the big bandwidth eater by far. I note that the story is essentially based around statements made by Sandvine. They aren't saying that the amount of broadband traffic is going to increase significantly because of online gaming; they're saying that broadband networks need to prioritize and QoS traffic from gamers, as more people game online. And oddly enough, Sandvine offers a box that does this! :-) They're jumping on the press coverage of Halo 2 to try and raise awareness of their product line. Not that what's being said doesn't have merit, but it's definately a PR push, and definately not a "End of the net predicted, film at 11" moment. Bob
Re: Halo 2 and broadband traffic
Hi Paul: The article you mention is similar to one at the BBC: http://news.bbc.co.uk./2/hi/technology/4079397.stm The source cited in both articles is the same: Sandvine. These guys are not unbiased. They make bandwidth-limiting devices. They proffer their boxes to cable/dsl operators that are trying to avoid spending money on needed infrastructure improvements. (Why provide good service, when you can take the same money and try to buy Disney...) At 09:46 AM 12/8/2004, you wrote: >Has anyone actually noticed any increases in residential >broadband traffic due to Halo 2? > >- ferg > >http://news.com.com/Does%20the%20Halo%202%20effect%20threaten%20broadband/2100-1034_3-5481727.html > > >-- >"Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > [EMAIL PROTECTED] or > [EMAIL PROTECTED]
wi.rr.com
Could someone from Roadrunner contact me off-list please? Jeffrey Sharpe CyberLynk Helpdesk and Support 414.858.9335 or 800.942.8022 [EMAIL PROTECTED]
Re: Peering best practices advice needed.
[EMAIL PROTECTED] wrote: That is what he is doing, however if he is advertising the two /19's, >from two disconnected sites with the same ASN, > they will not be able to reach each other as BGP will >interpret this as a path loop. Yup. I would presume, as they aren't connected, nor running iBGP, they would be running different ASN's. Anything else hurts. On Wed, Dec 08, 2004 at 12:56:13PM -0500, Richard Irving wrote: Rolo Tomassi wrote: Hi all, Please forgive the simplistic nature of the query.. Basically my company is multi-homed with 2 different providers in the UK, and advertising a /18. Now some colleaguges in another part of the world want to break that /18 into two /19's and advertise one /19 and we advertise the other. This is fine, however we are NOT running IBGP in the core, therefore the UK customers in the /19 will not be able to reach the other /19 as there would be a loop detected through EBGP. Pardon my simplistic solution, try dropping the /18, and -only- advertise the corresponding /19 from each region. Now someone mentioned that we could use AS-LOOP-IN feature which will overcome this problem and allow us to route to each other via EBGP. I really think this is a bad idea but until we get an internal link - I dont see a way forward. So... anyone doing this currently in their network or have any "best practices" way round this. I want our company to be good Netizens but still be able to pass traffic between the 2 /19's. See above. K.I.S.S. (No offense intended ;) Any help would be greatly appreciated. Rolo ! _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
ASN and Peering Problem
We currently have two /19 that we advertise on a single ASN. A client would like to obtain /23 or /22 from us. This is not a problem, except that their primary internet provider is someone else, other than us. I think that they would need to have their own ASN to advertise their portion of our ip space to their peers. My question is, should we provide the ASN or should they apply for an ASN? What is the minimum block considered routable, is it reasaonable to advertise a /23 on its own ASN? Are there any other solutions I haven't thought of? Thanks, Adi
Little brother of sitefinder
It has just come to my attention that NetSol is now assigning a CNAME record of resalehost.networksolutions.com to all expired domains. This is so the web site will come up with a "This domain expired on this data, click here to renew." page. resalehost.networksolutions.com has IP 216.168.224.53, doesn't listen on port 25, and has no MX record. The upshot is, mail to expired domains, instead of being rejected outright in the SMTP dialog, sits in our queue for 5 days. Users don't know right away that mail isn't getting through. This isn't quite on the same level as Sitefinder, but it's the same mindset, make a change without examining the impact. The operational impact has been support time spent finding out why mail has supposedly disappeared, and/or is sitting in our queue. Is this new, or have I had my head in the sand ? == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: ASN and Peering Problem
On Dec 8, 2004, at 2:59 PM, Adi Linden wrote: We currently have two /19 that we advertise on a single ASN. A client would like to obtain /23 or /22 from us. This is not a problem, except that their primary internet provider is someone else, other than us. I think that they would need to have their own ASN to advertise their portion of our ip space to their peers. My question is, should we provide the ASN or should they apply for an ASN? They should. What is the minimum block considered routable, is it reasaonable to advertise a /23 on its own ASN? Many people do /24s. There is no real difference between a /24 and /23 in most people's filters. A /20 may or may not get them more reachability, but as long as you accept their /23 and announce the aggregate CIDR, it should not matter. Are there any other solutions I haven't thought of? Yes, but they are all bad. :) -- TTFN, patrick P.S. Wow, two operational posts in one day. What is happening to this list?
Re: ASN and Peering Problem
Assuming that this is in North America (this is NAnog, afterall), they should probably apply to ARIN for both the /22 (if they can justify that much space) and the ASN, or, get the ASN from ARIN and the space from you. As of policy 2002-3, ARIN will assign /22s to end users that have need of a unique routing policy and meet other tests necessary for such an assignment. These are the same tests you would be required to hold them to for you to assign them a PA /22. Owen --On Wednesday, December 8, 2004 13:59 -0600 Adi Linden <[EMAIL PROTECTED]> wrote: We currently have two /19 that we advertise on a single ASN. A client would like to obtain /23 or /22 from us. This is not a problem, except that their primary internet provider is someone else, other than us. I think that they would need to have their own ASN to advertise their portion of our ip space to their peers. My question is, should we provide the ASN or should they apply for an ASN? What is the minimum block considered routable, is it reasaonable to advertise a /23 on its own ASN? Are there any other solutions I haven't thought of? Thanks, Adi -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgppvY90QEhXC.pgp Description: PGP signature
Re: Little brother of sitefinder
I hadn't noticed it, but, I hope that ICANN will take appropriate action on it. It really is about time that Verisign got told "Either run the registry as contracted for the public good, not as your own private revenue producer, or, agree to terminate the contract and we'll find you a successor on reasonable terms." Owen --On Wednesday, December 8, 2004 15:15 -0500 "Christopher X. Candreva" <[EMAIL PROTECTED]> wrote: It has just come to my attention that NetSol is now assigning a CNAME record of resalehost.networksolutions.com to all expired domains. This is so the web site will come up with a "This domain expired on this data, click here to renew." page. resalehost.networksolutions.com has IP 216.168.224.53, doesn't listen on port 25, and has no MX record. The upshot is, mail to expired domains, instead of being rejected outright in the SMTP dialog, sits in our queue for 5 days. Users don't know right away that mail isn't getting through. This isn't quite on the same level as Sitefinder, but it's the same mindset, make a change without examining the impact. The operational impact has been support time spent finding out why mail has supposedly disappeared, and/or is sitting in our queue. Is this new, or have I had my head in the sand ? == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/ -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgpnrdBCVwRs9.pgp Description: PGP signature
Re: Little brother of sitefinder
On Wed, 8 Dec 2004, Owen DeLong wrote: I hadn't noticed it, but, I hope that ICANN will take appropriate action on it. Are they doing this just to Verisign registered domains, or any domains expiring at any registrar? If it's just verisign customers, I don't think this is the afront to the intenret that sitefinder was, but if it's all expired domains, then it's getting close. Do any other .com registrars employ these tactics? I think I've seen it on other TLDs. Thanks -S
ddos?
Anyone aware of ddos affecting savvis, level3, or qwest at the moment? -Dan
Re: ddos?
Captain's Log, stardate Wed, 8 Dec 2004 16:36:31 -0800 (PST), from the fingers of Dan Hollis came the words: > > Anyone aware of ddos affecting savvis, level3, or qwest at the > moment? > > -Dan Yeah, I've been having between 40 - 99% packet loss at the same Savvis hop in Amsterdam over all separate providers. Major Problem for VoIP. It's been happening to me intermittently for like two weeks now. Savvis is blaming all four of our providers and stating that it is not their fault.
RE: ddos?
Hah figures savvis would say that. Best Wishes, Blake L. Smith XtremeBandwidth.com, Inc. 949-330-6400 Office 949-606-7100 Fax www.XtremeBandwidth.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Gilmour Sent: Wednesday, December 08, 2004 5:27 PM To: Dan Hollis; '[EMAIL PROTECTED]' Subject: Re: ddos? Captain's Log, stardate Wed, 8 Dec 2004 16:36:31 -0800 (PST), from the fingers of Dan Hollis came the words: > > Anyone aware of ddos affecting savvis, level3, or qwest at the > moment? > > -Dan Yeah, I've been having between 40 - 99% packet loss at the same Savvis hop in Amsterdam over all separate providers. Major Problem for VoIP. It's been happening to me intermittently for like two weeks now. Savvis is blaming all four of our providers and stating that it is not their fault.
[Fwd: zone transfers, a spammer's dream?]
--- Begin Message --- Hello all, while doing some experiments with dig using a .fm domain I made a small typo. Much to my surprise the whole fm zone was transferable by anyone. It's obvious this is a fabulous source for dictionary spammers who just mail to generic addresses at as much domains as they can possibly find. ([EMAIL PROTECTED], [EMAIL PROTECTED], ...) Intrigued by the .fm zone, I did a quick scan to see which other top level domains allowed zone transfers. It was no surprise to me that some small zones of developing countries were open, but one top level domain immediately caught my eye: getting the complete .ca zone (Canada), 48 Mb in total, serving 471.686 domains is as easy as doing 'dig axfr ca @ca01.cira.ca.' Some zones weren't transferable at the master nameservers, but were transferable at slave servers. Other publicly transferable zones: (quick and dirty count, divide by +/- 3 to get the number of domains, as this lists multiple name servers per domain) wc -l *.zone 432 ao.zone 5050 ba.zone 15 biz.et.zone 4645 bo.zone 45 bt.zone 923 bw.zone 1031788 ca.zone 20 cf.zone 11167 com.eg.zone 208 com.er.zone 377 com.ye.zone 313 cv.zone 5216 dj.zone 3724 ec.zone 51054 ee.zone 36 eg.zone 42 er.zone 54 et.zone 10063 fm.zone 498 ga.zone 482 gd.zone 6829 ge.zone 885 gp.zone 27 gq.zone 13622 gs.zone 45 gu.zone 31 gw.zone 541 gy.zone 16522 jm.zone 2732 kg.zone 76 kh.zone 17 km.zone 1467 kn.zone 210 lc.zone 36 mh.zone 75 mp.zone 22047 ms.zone 69 mt.zone 3697 museum.zone 2013 mw.zone 156 mz.zone 264 na.zone 732 org.eg.zone 415 org.mt.zone 26665 pk.zone 4280 sm.zone 3172 sn.zone 17495 tc.zone 38 td.zone 1999 tp.zone 171 uk.zone 16 um.zone 70 uy.zone 2407 vc.zone 15645 vg.zone 3308 vu.zone 61 ye.zone 220 yu.zone This does not include some second level domains like net.** and org.**, as my quick and dirty script didn't check these. After a much too long introduction here comes my questions: is this deliberate? I can understand that Chad has bigger things to worry about than 24 domains getting on yet another spam list, but why Canada makes nearly half a million domains as easy to grab as this really is a mystery to me. What do you think? Best regards, Lode Vermeiren __ [EMAIL PROTECTED] signature.asc Description: Dit berichtdeel is digitaal ondertekend --- End Message ---
RE: Peering best practices advice needed.
Hello. Three options. 1. Acquire a second ASN, and announce each site's /19 from a different asn. 2. Announce each locations /19 from it's respective location, using the same asn. Use the cisco BGP command Allow-as-in to permit each AS to hear the remote site's network advertisement. 3. If the remote site will not be multihomed, ask their ISP to announce the /19 for you. My gut says that if you are advertising a block in the territory of another RIR, your irr entries will need to be correct to save filtering issues. Good Luck, Ejay > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Rolo Tomassi > Sent: Wednesday, December 08, 2004 11:04 AM > To: [EMAIL PROTECTED] > Subject: Peering best practices advice needed. > > > Hi all, > > Please forgive the simplistic nature of the query.. > > Basically my company is multi-homed with 2 different > providers in the UK, > and advertising a /18. Now some colleaguges in another part > of the world > want to break that /18 into two /19's and advertise one /19 > and we advertise > the other. This is fine, however we are NOT running IBGP in the core, > therefore the UK customers in the /19 will not be able to > reach the other > /19 as there would be a loop detected through EBGP. > > Now someone mentioned that we could use AS-LOOP-IN feature which will > overcome this problem and allow us to route to each other via > EBGP. I really > think this is a bad idea but until we get an internal link - > I dont see a > way forward. So... anyone doing this currently in their > network or have any > "best practices" way round this. I want our company to be > good Netizens but > still be able to pass traffic between the 2 /19's. > > Any help would be greatly appreciated. > > Rolo ! > > _ > Stay in touch with absent friends - get MSN Messenger > http://www.msn.co.uk/messenger
RE: ASN and Peering Problem
If I understand, they would like you and the other provider to both announce the IP space, from your respective ASN's. Real-world, this will work, but causes an "inconsistent origin" bgp error. -ejay > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Adi Linden > Sent: Wednesday, December 08, 2004 1:59 PM > To: [EMAIL PROTECTED] > Subject: ASN and Peering Problem > > > We currently have two /19 that we advertise on a single ASN. A client > would like to obtain /23 or /22 from us. This is not a problem, except > that their primary internet provider is someone else, other than us. > I think that they would need to have their own ASN to advertise their > portion of our ip space to their peers. > > My question is, should we provide the ASN or should they > apply for an ASN? > What is the minimum block considered routable, is it reasaonable to > advertise a /23 on its own ASN? > > Are there any other solutions I haven't thought of? > > Thanks, > Adi
