- Test - lists.nanog.org

RE: Enterprise Multihoming
by Burton, Chris 13 Mar '04

13 Mar '04

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: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott McGrath Sent: Friday, March 12, 2004 5:50 PM To: nanog(a)merit.edu 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: > > > > > <On Thu, 11 Mar 2004, Gregory Taylor 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 Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > Regards > Marshall Eubanks > > T.M. Eubanks > e-mail : marshall.eubanks(a)telesuite.com > http://www.telesuite.com >

1 0

Enterprise Multihoming
by John Neiberger 13 Mar '04

13 Mar '04

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 --

16 18

wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
by Henry Linneweh 12 Mar '04

12 Mar '04

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 -Henry Message from yahoo.com. Unable to deliver message to the following address(es). <abuse(a)wholesalebandwidth.com>: 69.6.21.60 does not like recipient. Remote host said: 550 5.7.1 <abuse(a)wholesalebandwidth.com>... Relaying denied Giving up on 69.6.21.60.

12 13

Need a cox.net mail server contact
by Brian Bruns 12 Mar '04

12 Mar '04

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 postmaster(a)cox.net 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. Thanks -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The Abusive Hosts Blocking List http://www.ahbl.org

6 6

OT: jump.net.uk contact
by Charles Sprickman 12 Mar '04

12 Mar '04

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 spork(a)inch.com

2 1

Re: Enterprise Multihoming
by John Neiberger 12 Mar '04

12 Mar '04

>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 --

1 0

Weird network problem.
by Bob Harden 12 Mar '04

12 Mar '04

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) -> 216.41.224.3(80), 19 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16081: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 5 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16082: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3229) -> 216.41.224.3(80), 6 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16083: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3236) -> 216.41.224.3(80), 9 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16084: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3233) -> 216.41.224.3(80), 12 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16085: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 21 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16087: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3239), 19 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16088: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 4 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16089: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 2 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16091: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3218), 3 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16092: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3221), 17 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16093: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3229), 5 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16094: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3236), 7 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16096: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3233), 9 packets Network analysis showed significant amounts of spoofed multicast traffic and odd arp traffic. 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 10:17:16.421886 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 334 10:17:16.423873 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 262 10:17:16.426948 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 254 10:17:16.432095 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 298 10:17:16.435921 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 274 10:17:16.439959 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 328 10:17:16.445317 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 326 10:17:16.449688 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 330 10:17:16.463537 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 322 Steps were taken to elminiate the spoofed traffic on the routers and access servers in the form of ACLs and filter lists. Neither have eliminiated the problem... but to what extent they might have helped has yet to be determined. The problem is still occuring, for some users the duration of the outage seems to have shortened other users notice no difference. It is not yet known if the filtering on the routers and access servers or the conversion to the 10.x.x.x network has made any difference. We should have a better idea in the upcoming days. What Doesn't help: Removing windows updates. Turning off XP firewall. Searching for malware. (SpyBot-SD, Adaware) Virus scanning (Various softwares) Specifying dns servers. Reinstalling windows.

2 1

thanks for the great response on wholesalebandwidth.com major abuser
by Henry Linneweh 12 Mar '04

12 Mar '04

I want to thank everyone on this for the excellant response :) -Henry "Sturgeon, Jon" <JonS(a)futuresoft.com> 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 now added to by personal blacklist. Thanks again, Jon -- ---------------------------------------------------------------------- FutureSoft, Inc. 12012 Wickchester Lane, Suite 600 Houston, TX 77079 If you no longer want to receive commercial e-mail correspondence from FutureSoft, you may remove your address from our records by visiting www.futuresoft.com/emailremoval.asp ----------------------------------------------------------------------

1 0

Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
by German Valdez 12 Mar '04

12 Mar '04

> > >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

2 1

Re: wholesalebandwidth.com major sponsor of spammers refuses to accept email at abuse
by Michael.Dillon＠radianz.com 12 Mar '04

12 Mar '04

>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

1 0