Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
Are such networks maintained somewhere? SPEWS? -GSH - Original Message - From: "william(at)elan.net" <[EMAIL PROTECTED]> To: "Suresh Ramasubramanian" <[EMAIL PROTECTED]> Cc: "Henry Linneweh" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, March 12, 2004 4:37 AM Subject: Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse > > On Fri, 12 Mar 2004, Suresh Ramasubramanian wrote: > > > > > Henry Linneweh writes on 3/12/2004 8:41 AM: > > > I have received almost 200 different spam messages from domains > > > hosted by this provider from russain domains attempting to sell > > > pharmacueticals and other unsolicited services that I do not want > > > tekmailer.com and moosq.com are 2 of the primary abusers from this > > > hosting company > > > > Wholesalebandwidth = Scott Richter. > > > > http://groups.google.com/groups?q=scott+richter+wholesalebandwidth > > > > You can safely nullroute 69.6.0.0/18 > > Don't forget to add 69.6.64.0/20 to your access list - they recently got > this addition and quickly moved quite some number of spam servers there. > > -- > William Leibzon > Elan Networks > [EMAIL PROTECTED] > >
The Cidr Report
This report has been generated at Fri Mar 12 21:47:22 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
05-03-04132261 92241
06-03-04132433 92219
07-03-04132274 92242
08-03-04132268 92202
09-03-04132135 92247
10-03-04132227 92450
11-03-04132445 92466
12-03-04132560 92585
AS Summary
16741 Number of ASes in routing system
6735 Number of ASes announcing only one prefix
1389 Largest number of prefixes announced by an AS
AS7018 : ATTW AT&T WorldNet Services
73583360 Largest address span announced by an AS (/32s)
AS568 : DISOUN DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 12Mar04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 132868925564031230.3% All ASes
AS4323 689 200 48971.0% TWC-34 Time Warner
Communications, Inc.
AS7018 1389 968 42130.3% ATTW AT&T WorldNet Services
AS6197 678 300 37855.8% BNS-14 BellSouth Network
Solutions, Inc
AS7843 492 120 37275.6% ADELPH-13 Adelphia Corp.
AS701 1318 947 37128.1% UU UUNET Technologies, Inc.
AS27364 388 33 35591.5% ARMC Armstrong Cable Services
AS22909 372 34 33890.9% CMCS Comcast Cable
Communications, Inc.
AS6198 547 216 33160.5% BNS-14 BellSouth Network
Solutions, Inc
AS4134 643 317 32650.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS22773 351 39 31288.9% CXAB Cox Communications Inc.
Atlanta
AS1239 968 669 29930.9% SPRN Sprint
AS4355 385 101 28473.8% ERSD EARTHLINK, INC
AS6347 370 87 28376.5% SAVV SAVVIS Communications
Corporation
AS6140 375 111 26470.4% IMPSA ImpSat
AS1221 889 634 25528.7% ASN-TELSTRA Telstra Pty Ltd
AS17676 297 43 25485.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9583 384 140 24463.5% SATYAMNET-AS Satyam Infoway
Ltd.,
AS6478 273 42 23184.6% ATTW AT&T WorldNet Services
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher & Flom LLP
AS209722 509 21329.5% QWEST-4 Qwest
AS14654 2154 21198.1% WAYPOR-3 Wayport
AS20115 629 420 20933.2% CHARTE-72 Charter
Communications
AS11305 243 41 20283.1% INTERL-80 Interland
Incorporated
AS4766 436 244 19244.0% KIX Korea Internet Exchange
for "96 World Internet
Exposition
AS2386 431 240 19144.3% ADCS-1 AT&T Data
Communications Services
AS4519 204 21 18389.7% MAASCO Maas Communications
AS9929 209 30 17985.6% CNCNET-CN China Netcom Corp.
AS6327 206 28 17886.4% SHAWC-2 Shaw Communications
Inc.
AS5668 350 173 17750.6% CIH-12 CenturyTel Internet
Holdings, Inc.
AS3356 853 683 17019.9% LEVEL3 Level 3 Communications
Total 15549 7410 813952.3% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax
Cable Ltd.
64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc.
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
64.46.12.0/24AS7850 IHIGHW iHighway.net, Inc.
64.46.27.0/24AS8674 NETNOD-IX Netnod Internet Exchange Sverige
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
>Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! Are you sure about this? I find it hard to believe that you can justify blocking such a large chunk of South and Central America. How many different networks operators are you blocking in 200/8 ? --Michael Dillon
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
On Thu, Mar 11, 2004 at 10:59:01PM -0800, just me wrote: | | Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! | I'd say that it is not a wise thing to do, but it is up to you. Inside this /8 block there are a lot allocation to important networks in our region. There is also, users that send spam from these IPs, but I see this all the time from IP blocks of all over the world. According to some statistics USA is one of the top in the list of spammers. Do you filter all American blocks in your network? I guess not. You wisely filter only some, like this 69.6.0.0/18. Do you filter all Asia blocks? I guess not... regards, Ricardo. -- Latin American and Caribbean Internet Addresses Registry http://lacnic.net
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! matto In that case you would be blocking all the networks in 29 economies in Latin american and caribbean region. I recomend you verify for more detail information about ip address allocation inside 200/8 in LACNIC whois database service at http://lacnic.net/cgi-bin/lacnic/whois?lg=EN German Valdez Policy Liaison LACNIC
Weird network problem.
Has anybody on the list ran into any problems like this? We don't have a firewall and have tried with and without our ACL's but get the same results. Below is our internal white paper on the situation. If anybody has any ideas they would be much appreciated. Thanks, Bob Harden Network problem information. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix & MacOS History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 3 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16080: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3221) -> 21
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
German Valdez wrote: In that case you would be blocking all the networks in 29 economies in Latin american and caribbean region. The people doing this generally know this. They often also block big chunks of APNIC too. They often believe that the ratio of legitimate mail to spam coming from these networks for their customers is too poor to not block. They'll usually whitelist an address if one of their customers requests it. I'm not condoning the practice; I find it too extreme for my tastes. But there are a number of people doing it. Do a search at groups.google.com for "LACNIC group:news.admin.net-abuse.email" to see what people are saying/blocking. Bob
Re: Weird network problem.
Hey Bob The problem we were seeing was in fact different than the one you seem to have. It was specific to IE and was corrected by a later MS patch. If it is any help, I can give you an account on the network to work with in your diagnosis. Send me an email off list or call. I notice in your documentation that you mention a "conversion to the 10.x.x.x" network. Are you NAT'ing? Herman Harless Director Advanced Data Services NTELOS, Inc. On Fri, 2004-03-12 at 10:06, Bob Harden wrote: > > Has anybody on the list ran into any problems like this? We don't have > a firewall and have tried with and without our ACL's but get the same > results. Below is our internal white paper on the situation. If > anybody has any ideas they would be much appreciated. > > Thanks, > > Bob Harden > > > > > Network problem information. > > Symptoms: At random times dialup, dedicated, & internal network users > are unable to > pass TCP traffic to off network sites. ICMP and UDP appears > to be > uneffected by the outage which lasts anywhere from 2 to 5 > minutes. > > The problem appears to be wide spread with similar reports > from WVNET > and other ISPS. nTelos is experiencing a similar problem but > we have > yet to confirm it is the same. > > Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. > > > Uneffected Platforms: Unix & MacOS > > > History: During the week of 2/9/04 the call center started recieving > reports of > users being unable to connect to sites off the network. Sites > hosted on the internal network are uneffected by the outage. > > Initally it was thought to be a Internet Explorer problem > possably caused > by the KB832894 / IE SP1 or other updates but after further > investigation > it was found that Mozilla users were encountering the same > problem. > > After several days of testing it was determined that during the > outage any > TCP session started on any port would fail. TCP sessions > started before > the outage continue to work and show no ill effects from the > outage. > > After logging connection attempts at various intervals on many > machines > there appears to be no sort of pattern in the outages. Most > machines > encounter the problem, some more than others and a few do not > encounter > it at all. The duration and frequency of the outage is very > fluid. > > During an outage, we can verify that the packet does seem to > leave and reenter > the network: > > Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: > %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> > 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT > 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> > 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: > SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp > 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 > pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 > permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 > 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: > list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets > Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: > %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> > 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: > SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp > 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 > pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 > permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets > > Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: > %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> > 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT > 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> > 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: > SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp > 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 > pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 > permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 > 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: > list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet > Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: > %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> > 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: > SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp > 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:
thanks for the great response on wholesalebandwidth.com major abuser
I want to thank everyone on this for the excellant response :) -Henry"Sturgeon, Jon" <[EMAIL PROTECTED]> wrote: william(at)elan.net wrote:> Don't forget to add 69.6.64.0/20 to your access list - they recently> got this addition and quickly moved quite some number of spam servers> there.Much thanks, William, I hadn't picked up on that. That netblock is nowadded to by personal blacklist.Thanks again,Jon-- --FutureSoft, Inc.12012 Wickchester Lane, Suite 600Houston, TX 77079If you no longer want to receive commercial e-mail correspondencefrom FutureSoft, you may remove your address from our records by visiting www.futuresoft.com/emailremoval.asp--
Security: Cisco time?
Hello, I think cisco woke up now, http://www.theregister.co.uk/content/5/36156.html You NSPs are the worst enemy for the internet security, do you know why? You are allowing your customers to abuse, and ignore the abuse emails, but that doesn't matter since they pay for the bw. Good example, hinet is the spolied kid of Sprint, UUNet, and AT&T, is the worst infected ISP. I don't buy innocent users joke, everyone connected the net is responsible and shouldn't be a problem on it. I think it's the right time to make something for abuseive NSP/ISPs like spews. ahbl.org is good idea. PS: I know most of you, were ignoring the DDoS till it's too late now, soon we will see the internet goes down, and not trust worthy. Thanks, -J Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
Re: Enterprise Multihoming
I think its too easy, thats the problem. For <$1000 (excluding bandwidth/ccts) you can buy a box, connect to your two providers, get an ASN and IPs and you're away. Compare to the telephone network, to 'multihome' you need to get licenses, allocations of numbers and codes thats not so easy, get some SS7 kit and do your data builds.. you're talking quite a lot more money and certainly a lot more difficult technically. Perhaps we should make the Internet more difficult :) I dont agree that connecting to two+ upstreams makes you better. In my experience end networks have a couple of orders of magnitude more downtime than a PoP in any reasonably large ISP. Ie the percentage theoretical improvement is small. In addition you seriously increase the complexity of your system, chances are you're using the cheapest kit you could find (or at least cheaper and smaller than what I would use).. its not great at BGP and may fall over when you get a minor DoS attack, you probably generate flaps quite a bit from adhoc changes and if you're announcing a /24 then thats going to get you dampened quickly.. so you actually create a new weakest link. Also most of the corporates I've dealt with take defaults rather than full tables.. so if the provider does have an issue you still forward the traffic, theres no failover of outbound routing. Even if you spend (waste) the money on some decent gear, you're on your own and when a problem occurs the ISPs are going to be less helpful to you (not by choice, I mean they dont have control of your network any more.. there knowledge of whats causing problems is limited to the bit that they provide to you), so chances are your problems may be more serious and take longer to diagnose and fix. IMHO avoid multihoming. You will know when you are big enough and you *need* to do it, if you're not sure or you only want to do it cause you heard everyone else is and its real cool then I suggest you dont. Steve On Thu, 11 Mar 2004, John Neiberger wrote: > > On another list we've been having multihoming discussions again and I > wanted to get some fresh opinions from you. > > For the past few years it has been fairly common for non-ISPs to > multihome to different providers for additional redundancy in case a > single provider has problems. I know this is frowned upon now, > especially since it helped increase the number of autonomous systems and > routing table prefixes beyond what was really necessary. It seems to me > that a large number of companies that did this could just have well > ordered multiple, geographically separate links to the same provider. > > What is the prevailing wisdom now? At what point do you feel that it is > justified for a non-ISP to multihome to multiple providers? I ask > because we have three links: two from Sprint and one from Global > Crossing. I'm considering dropping the GC circuit and adding another > geographically-diverse connection to Sprint, and then removing BGP from > our routers. > > I see a few upsides to this, but are there any real downsides? > > Flame on. :-) > > Thanks, > John > -- >
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
On 03/12/04, "Gu?bj?rn S. Hreinsson" <[EMAIL PROTECTED]> wrote: > Are such networks maintained somewhere? SPEWS? http://www.spamhaus.org/ is always a good place to start. They've got the most comprehensive public collection of information about spammer operations. -- J.D. Falk "be crazy dumbsaint of the mind" <[EMAIL PROTECTED]> -- Jack Kerouac
Re: Counter DoS
> Fortunately people with less clue usually have less bandwidth. Obviously > there are exceptions. I would expect to see localized tragedies if > something like this would get deployed but predicting death of the > internet is clueless. Hmm thats little comfort if your sharing your cable modem PVC with one of these bozos who goes and maxes out your shared 512k. See thats the thing with DoS attacks, they cause problems for everyone not just the target, from the users sharing with the source host(s) right thro the ISPs carrying the traffic wondering why their usually quiet FE port just went 100% or why their Cisco7200 has 100% CPU and dropped all its BGP and onto the users sharing with the destination who now dont have any bandwidth available. Steve
Re: Enterprise Multihoming
>>> "Stephen J. Wilcox" <[EMAIL PROTECTED]> 3/12/04 9:06:38 AM >>> >I dont agree that connecting to two+ upstreams makes you better. In my >experience end networks have a couple of orders of magnitude more downtime than >a PoP in any reasonably large ISP. Ie the percentage theoretical improvement is >small. > >In addition you seriously increase the complexity of your system, chances are >you're using the cheapest kit you could find (or at least cheaper and smaller >than what I would use).. its not great at BGP and may fall over when you get a >minor DoS attack, you probably generate flaps quite a bit from adhoc changes and >if you're announcing a /24 then thats going to get you dampened quickly.. so you >actually create a new weakest link. Also most of the corporates I've dealt with >take defaults rather than full tables.. so if the provider does have an issue >you still forward the traffic, theres no failover of outbound routing. > >Even if you spend (waste) the money on some decent gear, you're on your own and >when a problem occurs the ISPs are going to be less helpful to you (not by >choice, I mean they dont have control of your network any more.. there knowledge >of whats causing problems is limited to the bit that they provide to you), so >chances are your problems may be more serious and take longer to diagnose and >fix. The above arguments are rather similar to the ones I heard on the other discussion list I mentioned, and they were somewhat compelling. > >IMHO avoid multihoming. You will know when you are big enough and you *need* to >do it, if you're not sure or you only want to do it cause you heard everyone >else is and its real cool then I suggest you dont. In our case, we already are multihoming and I'm considering moving away from that to a simpler solution. It's been my assertion that we didn't need to multihome in the beginning. The decision was made at a level higher than me. However, now that we have it I'm trying to determine the pros and cons related to moving to a single provider. Thanks, John --
Re: Enterprise Multihoming
Stephen J. Wilcox wrote: IMHO avoid multihoming. You will know when you are big enough and you *need* to do it, if you're not sure or you only want to do it cause you heard everyone else is and its real cool then I suggest you dont. There _is_ another element that I tried to point to yesterday. If you are on record for making arguments about how there are better ways to spend the money, and your boss's boss gets replaced by a kid with all the tap-dance skills needed to sell smoke, flash and sizzle, what you become is "unemployed". And somebody half your age or less at less than your salary puts in the new OCn's (n = 3-12) and all the rest. Being right is important, but ... -- Requiescas in pace o email
Re: Enterprise Multihoming
At 4:06 PM + 3/12/04, Stephen J. Wilcox wrote: I think its too easy, thats the problem. Hoping that I don't sound too much like Bill Clinton, that depends on what you mean by "it." If "it" is multihoming, with your own ASN, to two providers, your raise some valid points. Is there an intermediate alternative before you go all out? Yes, I think so, assuming your current provider has multiple POPs. Let me examine some of your points if we consider RFC 1998-style multi-POPping (I just invented that highly technical term) using PA address space. For <$1000 (excluding bandwidth/ccts) you can buy a box, connect to your two providers, get an ASN and IPs and you're away. Alternatively, another POP link, and preferably another router. If you are more concerned with loop failures than router failures, not a completely unreasonable assumption, you could get away with one router that has multiple interfaces, and spend some of the savings on backup power -- possibly a backup power supply in addition to the UPS, such as a Cisco RPS on their smaller routers. While you'll probably take a performance hit, or if you can reduce to critical traffic on an outage, you might get away with a second smaller router. I dont agree that connecting to two+ upstreams makes you better. In my experience end networks have a couple of orders of magnitude more downtime than a PoP in any reasonably large ISP. Ie the percentage theoretical improvement is small. Like everything else, It Depends. My experience is that access links fail more often than provider routing systems, especially with a clueful provider. Since you can't guarantee that your physical connectivity to two different ISPs doesn't involve a shared risk group in the lines, there are still some things you may not be protected against. One option, depending on the plant in your area, is that if you are considering a second router, consider putting it in a nearby building, reachable by WLAN (if you are minimizing costs), where that building minimally has different ducts to the telco end office, and ideally goes to a different end office. Not always possible, but to be considered. Longer-range wireless (radio or optical) links get more expensive. In addition you seriously increase the complexity of your system, chances are you're using the cheapest kit you could find (or at least cheaper and smaller than what I would use).. its not great at BGP and may fall over when you get a minor DoS attack, you probably generate flaps quite a bit from adhoc changes and if you're announcing a /24 then thats going to get you dampened quickly.. That's a motivation for PA address space, where the provider aggregate is less likely to be small and easily damped. so you actually create a new weakest link. Also most of the corporates I've dealt with take defaults rather than full tables.. so if the provider does have an issue you still forward the traffic, theres no failover of outbound routing. Again looking at intermediate solutions, there are always partial routes such as customer routes of the provier. Even if you spend (waste) the money on some decent gear, you're on your own and when a problem occurs the ISPs are going to be less helpful to you (not by choice, I mean they dont have control of your network any more.. there knowledge of whats causing problems is limited to the bit that they provide to you), so chances are your problems may be more serious and take longer to diagnose and fix. Again, an operational advantage of multiPOPping and working with one carrier, although you aren't going to be protected against insanity of their BGP/ IMHO avoid multihoming. You will know when you are big enough and you *need* to do it, if you're not sure or you only want to do it cause you heard everyone else is and its real cool then I suggest you dont. MHO would be to look at "multihoming" as a spectrum of solutions rather than a binary choice of single-provider-single-link versus multiple-provider. In given situations, you might also want to look at DSL or cable for diversity, tunneling to an ISP since the broadband provider is unlikely to be willing to speak BGP. Even dialup/ISDN, sometimes for critical workstations, has its place. Shameless plug: I do go through these options in my book, Building Service Provider Networks (Wiley). Even there, though, I only run through the alternatives. You will still have to make your own cost-benefit decisions based on business policy, budget, clue level and cost of alternatives.
Re: Enterprise Multihoming
>Shameless plug: I do go through these options in my book, Building >Service Provider Networks (Wiley). Even there, though, I only run >through the alternatives. You will still have to make your own >cost-benefit decisions based on business policy, budget, clue level >and cost of alternatives. A copy of which I have sitting here at my desk. Ah, yes. Beginning at p. 344, "Multlinking and Multihoming: The Customer Side". I suppose I should re-read that section. :-) Regarding our internal network, I wish I could skip ahead to p. 517, "VPNs and Related Services". Unfortunately, the VPN products that are available right now are double the cost of our frame relay network. Oh well, perhaps someday my price will come. Thanks, John --
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
On Fri, 12 Mar 2004, Ricardo G Patara wrote: On Thu, Mar 11, 2004 at 10:59:01PM -0800, just me wrote: | | Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! I'd say that it is not a wise thing to do, but it is up to you. Inside this /8 block there are a lot allocation to important networks in our region. There is also, users that send spam from these IPs, but I see this all the time from IP blocks of all over the world. It is an effective solution in my specific application, with my set of users. I have a 100% hit rate with no false positives. I am not suggesting other folks do the same unless their requirements are also the same. I certainly wouldn't do this at my day job as [EMAIL PROTECTED], for example. According to some statistics USA is one of the top in the list of spammers. Do you filter all American blocks in your network? I guess not. You wisely filter only some, like this 69.6.0.0/18. I filter the blocks that I see a 1:0 spam to ham ratio from, wherever they are located. I also try to aggregate where I can. The LACNIC blocks were a convenient place to do so. Do you filter all Asia blocks? I guess not... I certainly do filter abuseive asian networks, except for networks that my users need connectivity to, or networks that I have not seen abuse from: http://mrtg.snark.net/blacklist.cgi I think you'll see that there's no region singled out there. You might also be forgetting that the reason I singled out the LACNIC blocks, is that they are the third largest source of unwanted SMTP traffic I see. I'm sorry if my actions have offended you, because there really is nothing personal going on here, just pragmatism and a desire to prevent as much spam as possible from reaching my users. Matt Ghali speaking as [EMAIL PROTECTED] only [EMAIL PROTECTED]< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
--- hrlinneweh wrote: > tekmailer.com and moosq.com are 2 of the primary > abusers from this hosting company Wholesale Bandwidth are spammers, the 4th worst in the world according to spamhaus.org. According to senderbase.org, those two domains are the 8th and 18th biggest sources of all Internet e-mail, ahead of entire networks of worm ridden cable users. http://www.theregister.co.uk/content/55/35937.html also makes interesting reading. --- gsh wrote: > Are such networks maintained somewhere? SPEWS? Spamhaus has useful data. There was some talk of a MAPS style BGP feed from Spamhaus which would be ideal, but I don't know what the current situation is. SBL data is available direct from Spamhaus or from http://spfilter.sourceforge.net/data/sbl/ -- Alex Clark __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
Hello, I also just want to make clear that there is nothing personal going on neither from my side. BTW, I tried to answer this directly to you, but as you block the whole 200/8, it was not possible. Interestingly, this could be your your first "ham" message from LACNIC region. Not this time... :( I sent my message to the list just to make it clear that not everyone in LACNIC region is spammer. The way you said the following: | Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! sounded that you had no idea what LACNIC is, and don't even care. To you it is just a bunch of spammer. Other might had the wrong impression that really doesn't matter what LACNIC is, and start to block the 200/8 because someone does so. Just my thoughts, Regards, Ricardo. On Fri, Mar 12, 2004 at 10:03:31AM -0800, just me wrote: | | On Fri, 12 Mar 2004, Ricardo G Patara wrote: | | On Thu, Mar 11, 2004 at 10:59:01PM -0800, just me wrote: | | | | Behind all of LACNIC's 200/8 and Iskimaro, whoever the heck they are! | | I'd say that it is not a wise thing to do, but it is up to you. | | Inside this /8 block there are a lot allocation to important networks | in our region. | There is also, users that send spam from these IPs, but I see this all | the time from IP blocks of all over the world. | | | It is an effective solution in my specific application, with my set of | users. I have a 100% hit rate with no false positives. I am not | suggesting other folks do the same unless their requirements are also | the same. I certainly wouldn't do this at my day job as | [EMAIL PROTECTED], for example. | | According to some statistics USA is one of the top in the list of | spammers. | Do you filter all American blocks in your network? I guess not. You | wisely filter only some, like this 69.6.0.0/18. | | I filter the blocks that I see a 1:0 spam to ham ratio from, wherever | they are located. I also try to aggregate where I can. The LACNIC | blocks were a convenient place to do so. | | Do you filter all Asia blocks? I guess not... | | I certainly do filter abuseive asian networks, except for networks | that my users need connectivity to, or networks that I have not seen | abuse from: | | http://mrtg.snark.net/blacklist.cgi | | I think you'll see that there's no region singled out there. You might | also be forgetting that the reason I singled out the LACNIC blocks, is | that they are the third largest source of unwanted SMTP traffic I see. | | I'm sorry if my actions have offended you, because there really is | nothing personal going on here, just pragmatism and a desire to | prevent as much spam as possible from reaching my users. | | Matt Ghali | speaking as [EMAIL PROTECTED] only | | [EMAIL PROTECTED]< |Flowers on the razor wire/I know you're here/We are few/And far |between/I was thinking about her skin/Love is a many splintered |thing/Don't be afraid now/Just walk on in. #include
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
> --- hrlinneweh wrote: > > tekmailer.com and moosq.com are 2 of the primary > > abusers from this hosting company > > Wholesale Bandwidth are spammers, the 4th worst in the > world according to spamhaus.org. But 69.6.0.0/18 is not listed in http://www.spamhaus.org/drop/ Is the Spamhaus BL different from the Drop? This network is listed in the SBL... -GSH
OT: jump.net.uk contact
Hi, Don't see them on the NOC list, can't reach them, can't dig out a contact address from alternate connectivity using lynx on their website. If you're from jump.net.uk, drop me a line here about reaching 216.220.96.0/19 via Level3. Thanks, Charles -- Charles Sprickman [EMAIL PROTECTED]
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
Ricardo G Patara wrote: According to some statistics USA is one of the top in the list of spammers. Do you filter all American blocks in your network? I guess not. You wisely filter only some, like this 69.6.0.0/18. Do you filter all Asia blocks? I guess not... When this came up the previous time, I suggested that disconnecting Florida from the Internet would be a good start to reduce abuse. However, since some people seem to care about the hardly measurable amount of legitimate traffic coming from there, this has not happened. Pete
Re: OT: jump.net.uk contact
On Fri Mar 12, 2004 at 04:17:40PM -0500, Charles Sprickman wrote: > Don't see them on the NOC list, can't reach them, can't dig out a contact > address from alternate connectivity using lynx on their website. > > If you're from jump.net.uk, drop me a line here about reaching > 216.220.96.0/19 via Level3. Network Next HopMetric LocPrf Weight Path * 216.220.96.0/19 166.90.136.141 41 90 0 3356 8059 8059 8059 8059 8059 8059 8059 8059 8059 i That's some fairly excessive pre-pending! I think you'll find that's why your route is being filtered. Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x(01)37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x(01)37701) | non sit, noli BBC Internet Ops | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
Matthew Hallacy (was Re: Need a cox.net mail server contact)
On Thu, 11 Mar 2004 00:06:10 -0600 "Matthew S. Hallacy" <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 11, 2004 at 12:34:29AM -0500, Brian Bruns wrote: > > > > Hello all, > > > > If a cox.net mail admin, or someone who knows a cox.net mail admin > > could contact me offlist about them blocking 2mbit.com in their mail > > servers, that would be great. I've tried contacting their > > [EMAIL PROTECTED] with UNBLOCK in the subject, but it just bounces > > the mail back at me with the same error as if I was trying to > > contact one of their users. Sooo, you kinda see the issue. > > Get used to it, a lot of mail servers are rejecting mail that comes > from DSL and Cable modem lines, you're hosting 2mbit.com on roadrunner > (despite calling it an 'RF T1' (??)) and thus, it will be blocked. > > > Open Solutions For A Closed World / Anti-Spam Resources > > http://www.sosdg.org > > > > The Abusive Hosts Blocking List > > http://www.ahbl.org > > The irony.. > > -- > Matthew S. HallacyFUBAR, LART, BOFH > Certified http://www.poptix.net GPG public > key 0x01938203 lets look at your website mister hallacy. [EMAIL PROTECTED] root]# host www.poptix.net www.poptix.net has address 24.72.12.135 hrm... 24/8... looks like a cablemodem to me, lets see [EMAIL PROTECTED] root]# whois 24.72.12.135 [Querying whois.arin.net] [whois.arin.net] Cable Regina CABLER (NET-24-72-0-0-1) 24.72.0.0 - 24.72.143.255 Access Communications - Regina Customer Network CUST-REGINA-1 (NET-24-72-2-0-1) 24.72.2.0 - 24.72.49.255 my my, we have a cablemodem. And using it with no other claim to any point in network administration, like say a blacklist which blocks over 1 million spam e-mails per day, or the largest and most complete RHSBL on the internet, or perhaps community/free web and e-mail hosting for anti-spammers? Mister Hallacy, do you in fact provide anything back to the community from whom you've consumed so much? But wait there's more! lets find out about that server... it's stats can be seen here: http://www.techmonkeys.org/phpSysInfo/ I hope he isn't running his website off the lexar jumpdrive :) http://www.techmonkeys.org/ which is the same ip as poptix.net [EMAIL PROTECTED] root]# host www.techmonkeys.org www.techmonkeys.org has address 24.72.12.135 But enough about technology, lets talk about poptix himself. Mister Hallacy or a kiddie associate, in response to my comment about #nanog being script kiddies, contacted a script kiddie via phone to harass him while impersonating a member of my staff, with the intent of having my network attacked. He has repeatedly harassed me via telephone, and his prank calls during DoS attacks(perhaps he was responsible for them?) are well documented on this list. http://www.merit.edu/mail.archives/nanog/2003-10/msg00719.html Mister Hallacy is a felon, convicted of computer tampering in 2000. He is serving 5 years probation. http://3jane.ashpool.org/~poptix/MyStory.html Look to the last section. and the rest of his actions documented here and above. And in regards to your certifications... real certifications come from Cisco and Novell, not a Cracker Jack box. I firmly assert that Matthew Hallacy provides no signal to this list. He does nothing but Denial of Service attack and harass it's members. He impersonates members of the list to harass other members of this list. THIS IS NOT A PLAYGROUND. I have sent Sue Harris 3 private e-mails in the last 48 hours, to which I have gotten no respone. I am now publically calling on Sue Harris to remove Matthew and his gang of script kiddies from #nanog from this list. Their behavior is deplorable. Their attitude is #damaging to this list, and their antics off the list towards members of this list are inexcusable and illegal. For the last time, harassment and impersonation of the users of this list, is not only ontopic, but the rapid knowledge and ability to deal with this situation is integral to it's continued success. -- Andrew D Kirch | Abusive Hosts Blocking List | www.ahbl.org Security Admin | Summit Open Source Development Group | www.sosdg.org Key At http://www.2mbit.com/~trelane/trelane.key Key fingerprint = B4C2 8083 648B 37A2 4CCE 61D3 16D6 995D 026F 20CF
Re: Matthew Hallacy (was Re: Need a cox.net mail server contact)
On Fri, 12 Mar 2004, Andrew D Kirch wrote: [snip chilish spew] Get over it, and fight your petty battle somewhere else. - d. -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/
Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
--On Thursday, March 11, 2004 7:11 PM -0800 Henry Linneweh <[EMAIL PROTECTED]> wrote: I have received almost 200 different spam messages from domains hosted by this spam-l is over that way -> google is also your friend and do you have to keep sending multipart mail?
Re: Counter DoS
On Thu, 11 Mar 2004, Petri Helenius wrote: > > Gregory Taylor wrote: > > > > > Oh yes, lets not forget the fact that if enough sites have this > > 'firewall' and one of them gets attacked by other sites using this > > firewall it'll create a nuclear fission sized chain reaction of > > looping Denial of Service Attacks that would probably bring most major > > backbone providers to their knees. > > > Fortunately people with less clue usually have less bandwidth. When pricing structures and deployment of broadband in the US approaches that of Korea and Japan, I think you'll find that that isn't the case in the US anymore. > Obviously > there are exceptions. I would expect to see localized tragedies if > something like this would get deployed but predicting death of the > internet is clueless. > > Pete > > >> > > > > > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: Enterprise Multihoming
As Marshall noted multi-homing gives you the ability to switch providers easily. This ability also gives you leverage with your network providers since vendor lock-in does not exist. This is a strong business case for multihoming and is one the financial types understand and appreciate. In a prior incarnation I worked for a distributor who had a online ordering system. Our telcom coordinator got a "great" deal on bundled internet service and telephony from a unnamed vendor. Due to the peering arrangements the carrier had major customers were unable to place orders in a timely fashion. I set up a new AS and set up multihoming with another carrier and made our customers happy again. Subsequently said carrier had an outage which took down our link to them for 7 weeks. Since this was an internal problem at our provider multiple links to this carrier would not have benefited us in the least. A multihoming strategy also allows you to select providers who provide connectivty to your business partners and customers which is another win for obvious reasons. Scott C. McGrath On Thu, 11 Mar 2004, Marshall Eubanks wrote: > > There is another thing - if you are multi-homed, and want to switch > providers, it is pretty seamless and painless - no renumbering, no > loss of connection, etc., as you always have a redundant path. > > > On Thursday, March 11, 2004, at 12:34 PM, Pekka Savola wrote: > > > > > >> Mutli-homing a non-ISP network or system on multiple carriers is a > >> good > >> way to maintain independent links to the internet by means of > >> different > >> peering, uplinks, over-all routing and reliability. My network on > >> NAIS > >> is currently multi-homed through AT&T. I use a single provider as > >> both > >> of my redundant links via 100% Fiber network. Even though this is > >> cheaper for me, all it takes is for AT&T to have some major outage > >> and I > >> will be screwed. If I have a backup fiber line from say, Global > >> Crossing, then it doesn't matter if AT&T takes a nose dive, I still > >> have > >> my redundancy there. > > > > Well, I think this, in many cases, boils down to being able to pick > > the right provider. > > > > I mean, some providers go belly-up from time to time. Others are > > designed/run better. > > > > For a major provider, complete outage of all of its customers is such > > a big thing they'll want to avoid it always. If it happens, for a > > brief moment, once in five years (for example), for most companies > > that's an acceptable level of risk. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oykingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > Regards > Marshall Eubanks > > T.M. Eubanks > e-mail : [EMAIL PROTECTED] > http://www.telesuite.com >
RE: Enterprise Multihoming
Address portability all depends on if you IP blocks are assigned by ARIN/RIPE/APNIC/ISP portable or if you are using the ISP's address space. It has been my experience that multi-homing to diverse ISP's with multiple circuits per ISP (i.e. Primary/Secondary with ISP-A and Primary/Secondary with ISP-B) is the best option if you can afford the cost and your bandwidth requires it. Like it was stated before, if you can afford the possible downtime associated with multi-homing to a single ISP then yes there are definitely cost savings to be had and reduced administrative overhead; but, if you cannot afford the possibility of downtime then separate ISP's is the only way to go. Chris Burton Network Engineer Walt Disney Internet Group: Network Services The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact Walt Disney Internet Group at 206-664-4000. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott McGrath Sent: Friday, March 12, 2004 5:50 PM To: [EMAIL PROTECTED] Subject: Re: Enterprise Multihoming As Marshall noted multi-homing gives you the ability to switch providers easily. This ability also gives you leverage with your network providers since vendor lock-in does not exist. This is a strong business case for multihoming and is one the financial types understand and appreciate. In a prior incarnation I worked for a distributor who had a online ordering system. Our telcom coordinator got a "great" deal on bundled internet service and telephony from a unnamed vendor. Due to the peering arrangements the carrier had major customers were unable to place orders in a timely fashion. I set up a new AS and set up multihoming with another carrier and made our customers happy again. Subsequently said carrier had an outage which took down our link to them for 7 weeks. Since this was an internal problem at our provider multiple links to this carrier would not have benefited us in the least. A multihoming strategy also allows you to select providers who provide connectivty to your business partners and customers which is another win for obvious reasons. Scott C. McGrath On Thu, 11 Mar 2004, Marshall Eubanks wrote: > > There is another thing - if you are multi-homed, and want to switch > providers, it is pretty seamless and painless - no renumbering, no > loss of connection, etc., as you always have a redundant path. > > > On Thursday, March 11, 2004, at 12:34 PM, Pekka Savola wrote: > > > > > >> Mutli-homing a non-ISP network or system on multiple carriers is a > >> good > >> way to maintain independent links to the internet by means of > >> different > >> peering, uplinks, over-all routing and reliability. My network on > >> NAIS > >> is currently multi-homed through AT&T. I use a single provider as > >> both > >> of my redundant links via 100% Fiber network. Even though this is > >> cheaper for me, all it takes is for AT&T to have some major outage > >> and I > >> will be screwed. If I have a backup fiber line from say, Global > >> Crossing, then it doesn't matter if AT&T takes a nose dive, I still > >> have > >> my redundancy there. > > > > Well, I think this, in many cases, boils down to being able to pick > > the right provider. > > > > I mean, some providers go belly-up from time to time. Others are > > designed/run better. > > > > For a major provider, complete outage of all of its customers is such > > a big thing they'll want to avoid it always. If it happens, for a > > brief moment, once in five years (for example), for most companies > > that's an acceptable level of risk. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oykingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > Regards > Marshall Eubanks > > T.M. Eubanks > e-mail : [EMAIL PROTECTED] > http://www.telesuite.com >
Load Balancing Multiple DS3s (outgoing) on a 7500
Does anyone know of an article, or documentation regarding load balancing the traffic on 3 or more FastEthernet interfaces on the outgoing direction? Right now we're running BGP internally, and the routes that are being chosen based upon the final BGP decision step or what I like to call the 'IP address tie breaker' which is not always optimal. We have a cisco 7500 that is connected to 4 other Cisco 7500s which each have 45Mbps ds3s to the Internet, we would like to load balance the outgoing traffic across all 4 of these 7500s, can anyone shine any advice my way? I noticed that there are instructions on Cisco's site regarding doing LB on 12000s. Anyways thanks in advance ;-) -Drew
Re: Load Balancing Multiple DS3s (outgoing) on a 7500
On Mar 12, 2004, at 10:39 PM, Drew Weaver wrote: Does anyone know of an article, or documentation regarding load balancing the traffic on 3 or more FastEthernet interfaces on the outgoing direction? Right now we're running BGP internally, and the routes that are being chosen based upon the final BGP decision step or what I like to call the 'IP address tie breaker' which is not always optimal. We have a cisco 7500 that is connected to 4 other Cisco 7500s which each have 45Mbps ds3s to the Internet, we would like to load balance the outgoing traffic across all 4 of these 7500s, can anyone shine any advice my way? I noticed that there are instructions on Cisco's site regarding doing LB on 12000s. Load balancing with BGP is the same on any cisco router. Are you doing BGP with the routers on the other side of those DS3s? If you are, you will need their help in load balancing properly. Get them to allow you peering with a loopback interface and use equal cost static routes to do the load balancing to that loopback interface. -- TTFN, patrick
FW: hey had eric sent you
Title: Message I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -Original Message- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.
Re: Load Balancing Multiple DS3s (outgoing) on a 7500
Patrick, I suspect that each FE goes to a different AS... On 3/12/04 7:27 PM, "Patrick W.Gilmore" <[EMAIL PROTECTED]> wrote: > > On Mar 12, 2004, at 10:39 PM, Drew Weaver wrote: > >> Does anyone know of an article, or documentation regarding >> load balancing the traffic on 3 or more FastEthernet interfaces on the >> outgoing direction? Right now we're running BGP internally, and the >> routes that are being chosen based upon the final BGP decision step or >> what I like to call the 'IP address tie breaker' which is not always >> optimal. We have a cisco 7500 that is connected to 4 other Cisco 7500s >> which each have 45Mbps ds3s to the Internet, we would like to load >> balance the outgoing traffic across all 4 of these 7500s, can anyone >> shine any advice my way? I noticed that there are instructions on >> Cisco's site regarding doing LB on 12000s. > > Load balancing with BGP is the same on any cisco router. > > Are you doing BGP with the routers on the other side of those DS3s? If > you are, you will need their help in load balancing properly. Get them > to allow you peering with a loopback interface and use equal cost > static routes to do the load balancing to that loopback interface.
Re: Load Balancing Multiple DS3s (outgoing) on a 7500
On Mar 12, 2004, at 11:24 PM, joe mcguckin wrote: I suspect that each FE goes to a different AS... Yeppers. We've been corresponding privately, and you got it right (unlike me). He'll be okie. It's just a little difficult for BGP to "load balance" outbound bits when the bulk of the Internet these days is 2 AS hops away from each of four upstreams. Not impossible, but it doesn't happen by default either. -- TTFN, patrick
Re: Load Balancing Multiple DS3s (outgoing) on a 7500
On 12 Mar 2004, at 23:24, joe mcguckin wrote: Patrick, I suspect that each FE goes to a different AS... In that case, sample/count outbound traffic volumes by (prefix/AS/AS_PATH/something), sort the resulting list, and develop an import policy based on the top N entries which shares the traffic by tweaking some other attribute to avoid the last-resort tie-break. Or bypass the measurement part, and make wild guesses about where your traffic is going, and apply an import policy based on that. Either way, lather, rinse, repeat. There might be something relevant in the slot I did in this tutorial in Richmond Hill: http://www.nanog.org/mtg-0206/te.html Joe
RE: Load Balancing Multiple DS3s (outgoing) on a 7500
> Patrick W.Gilmore wrote: > It's just a little difficult for BGP to "load balance" > outbound bits when the bulk of the Internet these days > is 2 AS hops away from each of four upstreams. Not > impossible, but it doesn't happen by default either. Indeed. If the following conditions are met: a) all four upstreams are transit providers (and therefore even a default to any would be fair game) b) the goal is to distribute more evenly (in terms of bandwidth) the egress traffic between the four upstreams (in other terms, the egress traffic tends to peg one of the upstreams (which are being paid to carry the traffic) for no clear reason) IMHO there is nothing wrong with some WAEG route-map to police egress traffic to a different upstream that the one the BGP process would have chose at the 5th tie-breaker, all 4 including the AS-PATH being equal. My $0.02 plus tax. Michel.
Port 80 Navigation Problem (was:FW: hey had eric sent you)
Title: Message My apologies to the list - I haven't slept in a day or two and completely forgot to make a semi-intelligent subject line... mjr -Original Message-From: Riley, Marty Sent: Friday, March 12, 2004 22:18To: [EMAIL PROTECTED]Subject: FW: hey had eric sent you I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -Original Message- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:
Re: FW: hey had eric sent you
On Fri, 2004-03-12 at 21:17, Riley, Marty wrote: > 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 > This is UPnP discovery. Take a look here: http://www.nthelp.com/upnpscrewup.htm http://www.linuxsa.org.au/mailing-list/2002-11/1134.html I see a lot of unicast UPnP traffic on my networks. UPnP seems like a train wreck waiting to happen, to me. It would be interesting to see what happens if one of your users turns UPnP off on their host. Just a shot in the dark. -- James H. Edwards Routing and Security At the Santa Fe Office: Internet at Cyber Mesa [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: hey had eric sent you
MessageThis in reply to the earlier thread Weird Problems? Well barring that, I've seen simuliar issues, maybe not the exact same timings but. I've noticed a couple of things while working with a roll out of Active-Directory and a recent upgrade to I.E 6.0 for the user base. Since there were several thousand users involved some of the issues were simply bad configs/drivers/etc. However one of the stats I have noticed is that in certain situations where a system is connected to a Cisco 3548, and the client is running in an Auto detect (AD/AN) mode that things are horendiously slow during boot up, and at various times seem to hang unexplainably. It seemed corrected by setting the client to 100/Full, but not in all cases. Lots of HTTP complaints still remain about accessing webpages etc. but never consistant. This of course is a pretty fresh problem and is still in my queue for research to start this Monday. As well, we've found that there was an odd bug with Cisco's 6513s and their 48 port 10/100/1000 line cards. This was using the latest IOS/CAT software at the time. Again not sure if its a documented problem but, several users were unable to Telnet or FTP to systems that teminated to the 6513, oddly we were able to icmp echo and pass HTTP. After sometime and 2 TACs I found that there was a bug regarding these items and real small packets (I Think less than 64bits??) being passed thru the 6513 and got an RMA for new Line cards. Again, perhaps nothing to do with your situation. Since the Nix systems and non-Doze seem not to have an issue, perhaps you can enlighten me with further Sniffs/Captures of these events directly? As soon as I get some more data/Captures on my end from the problems I'm seeing I can forward those apon request so as to keep S/N ratio down on Nanog (: Cheers, -Joe - Original Message - From: Riley, Marty To: [EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:17 PM Subject: FW: hey had eric sent you
UPnP
On Fri, 12 Mar 2004, James Edwards wrote: > I see a lot of unicast UPnP traffic on my networks. > UPnP seems like a train wreck waiting to happen, to me. Yep. Giving insecure PC's the power to change firewall settings. Doesn't sound like the cleverest idea. I have a firewall, my computer can't be a zombie. Yes, I click on every attachment I see and install every program any random web site offers me, but I have a firewall so my computer can't be a zombie :-( But it does demostrate that people really, really want to run their applications no matter how we try to stop them. Instead of blocking people from running their applications, can we figure out better ways for them to run them safely?
Re: Enterprise Multihoming
Most of the multi-homing talk has been about failover capabilities between different providers. What about the effects of multiple providers when neither has actually failed; such as different paths for inbound/outbound traffic. One provider may have better connectivity to x site whereas the other provider has better connectivity to y. (Or is this not as important as it used to be?) On Fri, Mar 12, 2004 at 09:15:55AM -0700, John Neiberger wrote: > In our case, we already are multihoming and I'm considering moving away > from that to a simpler solution. It's been my assertion that we didn't > need to multihome in the beginning. The decision was made at a level > higher than me. However, now that we have it I'm trying to determine the > pros and cons related to moving to a single provider.
