Date: Tue, 27 Dec 2005 17:28:25 -0800 (PST) From: Ted Mittelstaedt <tedm@toybox.placo.com> To: danial_thom@yahoo.com, Danial Thom <danial_thom@yahoo.com> Cc: freebsd-questions@freebsd.org, "Loren M. Lang" <lorenl@alzatex.com>, "Winelfred G. Pasamba" <winelfredpasamba@gmail.com>, Ted Mittelstaedt <tedm@toybox.placo.com>, Yance Kowara <yance_kowara@yahoo.com> Subject: RE: FreeBSD router two DSL connections Message-ID: <1135733305.43b1ea39b3427@mail.freebsd-corp-net-guide.com> In-Reply-To: <20051227183826.44291.qmail@web33315.mail.mud.yahoo.com> References: <20051227183826.44291.qmail@web33315.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Danial Thom <danial_thom@yahoo.com>: > > > --- Danial Thom <danial_thom@yahoo.com> wrote: > > > > > > > --- Ted Mittelstaedt <tedm@toybox.placo.com> > > wrote: > > > > > > > > Does it meet the test I already outlined? > > > > > > Download the FreeBSD iso then upload it to a > > > remote server, > > > with both lines connected. Time it. > > > > > > Disconnect 1 line, then repeat the test. If > > > the time to > > > download and upload when both DSL lines are > > > connected is > > > half the time it takes when 1 DSL line is > > > connected, then > > > your load-balancing. > > > > > > If not, then you are not - although if it > > makes > > > you feel > > > like you haven't wasted your money claim your > > > "per session load balancing" then I suppose > > it > > > would be > > > uncharitable to make you feel bad by pointing > > > out that > > > this is purely a marketing term with no > > > networking > > > significance. > > > > > > Oops. > > > > > > Ted > > > > > > Ted seems incapable of grasping how things > > work, > > so I don't recommend wasting your time on > > anything he says. > > > > As I stated, you cannot control how traffic > > comes > > into your network, so Ted's little download > > test > > is sure not to work. Traffic is routed to > > whichever ISP has the best route. You can only > > control how traffic goes OUT of your network. > > So > > load-balancing can only increase your upload > > speeds, not your download speeds. If you are > > hosting this is useful. If you have mostly > > download traffic, then its probably not worth > > is. > > > > I don't know if Ted is trying to boondoggle you > > into thinking his view is correct, or he just > > doesn't understand it. I suspect its a bit of > > both. > > > > You should really try the freebsd-isp list, as > > there are at least some people on there that > > have > > a clue. Although even Ted's resume looks good > > on > > paper, so you really can't tell. Incompetence > > is > > widespread. > > > > DT > > To sooth the nerves of the OP, the truth about > this is that it might work and it might not. > Ted's assertion that all ISPs do ingress address > filtering is simply wrong. I will concede this because of all the ISP's in the world, chances are that there is at least 1 that is run so incompetently, connected to a backbone network that is also unbelievably incompetent, that they are not filtering. > Not even close. My > assumption that none do isn't right either. Finally you are admitting that antispoofing filtering is a reality. I am glad to see that. However, you are wrong when you IMPLY that antispoofing access lists are not widespread. Anti spoof lists have a long history. Why even as far back as 1997 Cisco was unofficially offering to assist ISP's to put them in, this was in response to land.c, see here: http://www.apnic.net/mailing-lists/apnic-talk/archive/1997/11/msg00002.html Then in 2000, the IETF decided to codify the requirements for this in the following RFC's: ftp://ftp.ietf.org/rfc/rfc2827.txt ftp://ftp.ietf.org/rfc/rfc3013.txt We also saw then a pledge from the 9 founders of the Internet Security Alliance (http://www.isalliance.org/) to institute antispoofing on their networks, that article is here: http://news.zdnet.com/2100-9595_22-518743.html We also saw calls for this from SANS: http://www.sans.org/dosstep/index.php and that gadfly, Steve Gibson: http://grc.com/dos/grcdos.htm This was 5 years ago. Today, the practice is firmly established, Cisco provides instructions for it: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a 1a55.shtml and the US Department of Homeland Security has recommended it: http://www.dhs.gov/interweb/assetlibrary/NIAC_HardeningInternetPaper_Jan05.pdf and yes, these are the same people that have installed the black boxes that the NSA has used to electronically eavesdrop on the Internet without a search warrant, as was just reported a week or so ago in the NYT, and caused Congress to kill the extension of the Patriot Act. So don't think that those large networks aren't listening to the Feds - by contrast they are actively helping the Feds to spy on us!!! To assert as Danial is doing that they aren't following the Feds when the Feds tell them to anti-spoof is absurd. > IF > when one of your lines goes down you are still > online then you can load-balance outbound. IF you > are multi-homed or have a working backup > scenario, then you can load balance outbound. > I am afraid though that none of that is useful to the OP who wanted to know if he could shoestring load balance to 2 different ISP's for an Internet Cafe. Unless I am quite mistaken, Internet Cafe's are mainly inbound bandwidth consumers. > There is much discussion on the trade-offs of > ingress address filtering, and many believe its > the old "cut off your nose to spite your face". There WAS much discussion about 5 years ago when the Land worm hit, as I recall. There is very little today. Anyone authoratative strongly recommends it, and I know that some neworks are even now requiring ISP customers to do it. MANY isp's (such as the one I work for) automatically setup ingress filters on T1 routers that are placed -at the customer site- as part of our setup templates. And even the el-cheapo DSL routers that are network address translators, those devices won't translate traffic coming into their LAN ports that is spoofed. All Cisco routers in fact when you setup NAT on them you must define the inside subnets to be translated - they don't just accept anything handed to them. And that's just customer edge devices which you technically cannot control since they aren't in your NOC. For inside routers in the NOC, anyone competent has filters on them. i think the last large network we connected to that didn't have tight antispoof filters was MCI North America, and they pulled out of NA a few years back. And even then I'm pretty sure they only had holes that allowed you to spoof addresses they already owned. > It reduces the cpu power of your router by > causing it to test every packet coming in, Wrong. The CPU power of your router is a constant. Access lists CONSUME some of the CPU power of your router, that is true. However, most routers have ample CPU power for an antispoofing access list. It is true that a number of years ago, when antispoofing started getting recommended, that many ISP's and networks did in fact not have routers powerful enough to run antispoof lists. I've heard about ISP's back in the dark ages even running a filtered BGP table on a Cisco 2501 ! But today there's no excuse for it. With the prices of used 7206 VXR's now, any ISP under 10,000 customers can easily get a router plenty powerful enough to filter for less money than a 10 year old used car. And as for the larger ISP's like the Earthlinks and such, those people have lots of money and are on upgrade schedules and by now have updated to powerful enough routers to do antispoofing. How do you think they spy on us, they aren't using underpowered 2501's to do that!!! > it > makes multi-homing not work, Not true, you simply adjust the access list to permit multihoming from the customers who contact you and set it up with you. > and it makes > changing addresses on a large network extremely > more difficult, in order to thwart an unlikely > event. Not true either. Many tools exist to script access lists, for example a crude but interesting one is here: http://www-users.rwth-aachen.de/jens.hektor/security/cisco-acl.html > I recommend that my customers isolate > co-location customers so when worms hit they can > find the problem easier. Few do because its > easier to have everyone on the same wire. You are really a piece of work. In another thread you were railing against corporate admins using Windows terminal server as not being innovative because they can't do "what the real men do" and protect their Windows desktops because it's too hard for them - and here your defending lazy ass dumbshits who aren't even following your own recomendations? > My > cable company, for example, changes their > networking scheme every few months, and if they > had to change ingress filters on 100s of routers > manually it would be ridiculously difficult to > do. Your cable company probably has a Class B assigned from ARIN and is almost certainly NOT changing it's aggregated network block assigned from the numbering authority "every few months" Like everyone else, they can filter with a single statement permitting the aggregated block, they do not need to break out the filtering into every little itty-bitty route if they are that lazy that they can't bestir themselves to use a script like what I posted the URL to. > So they don't address filter. > So they are stupid - why are you using them then? > Ted is somehow in denial that 100s of people load > balance to different destinations. Since he > doesn't know the terms (such as round-robin, etc) > you can be sure he's never done any of it. The > simple truth is that you have to try things. You > never know what your upstream is doing. DSL is a > strange animal that requires muxes in often very > complicated meshes. If you can move your default > router to your "other" router then you are likely > not filtered. > Much more likely is that you didn't bother to read the instructions on your DSL or cable router and the things are still translating and you don't even realize it. If you really want to see if your provider is incompetent in this way, you can use a tool like the following: http://www.csm.ornl.gov/~dunigan/oci/spoof.html That will tell you if your able to spoof. > There are many issues more important than > address-spoofing, such as stability and > performance. Neither of which your going to find on a network that permits unfettered spoofing. If the network is that badly managed on a simple thing like that, it's going to be badly managed on a lot of other things too. > I have customers that are so > disorganized that they can't isolate any known > address group to any specific router, and others > that require that you register your MAC address > with them or nothing will work at all. You can't > postulate what your situation is. You have to do > testing and figure out what you can and can't do. And you also have to know enough to know the difference between the proper way to do something and a cheap hack that is unsupported, and might stop working without warning. > The more you know about how things REALLY work, > the more innovative you can be in your > implementation. > While I don't hold with Steve Gibson's chicken little approach to everything, he did have a good quote (probably stolen from somewhere else) on his site that I linked to above: "the days of an Internet based upon mutual trust among interconnected networks has passed" Go ahead and be innovative all you want, but be responsible too. The "big boy" networks that Danial seems to be so fond of ARE responsible, if not for purely altruistic reasons, it is due to the threat of ending up like the AGIS network - bankrupt because of defending spammers. Danial, it is really amazing you seem to think so many of them out there aren't responsible, and it is rather incredible that you are going so far as to advocate against being responsible - by dragging up hoary old excuses for not anti-spoofing - if you really are an Internet consultant, I really hope you are telling your customers to anti-spoof filter, if you aren't you are very, very irresponsible. It is no wonder you don't want to put your real name on anything your posting. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1135733305.43b1ea39b3427>