From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rene Gallati Date: Wed, 31 Mar 2004 21:19:01 +0000 Subject: Re: [LARTC] large routing table Message-Id: <406B35C5.4000806@draxinusom.ch> List-Id: References: <4069FB34.6000507@draxinusom.ch> In-Reply-To: <4069FB34.6000507@draxinusom.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Hello, > by default shape everything, but allow it to burst a bit (if that's not a= problem). Yeah, however my traffic won't really be too large. I expect max=20 bandwidth usage of about 1mbps to 2mbps max. I just need to make sure=20 that stays in the country, because if such bandwidth usage crosses=20 boundaries, its going to create costs that are unbearable. > make MARK X not shaped. >=20 > MARK X some big networks which will always be Switserland. >=20 > Then make a script (using the perl module I metioned previously) to check= whether a new connection should be shaped or not, if it should not be shap= ed, and if it's not part of the marked IP's already, you add an entry to th= e MARK X list the /24 network where the IP address is in. (I think you can = safely say that a /24 network is in one country). The problem is that the geo-skript is wrong - and I already have a=20 "perfect" list, so I rather use this, especially because that list is=20 provided by the people who own the machine/network, so when in doubt I=20 can always claim that I did my best to prevent undesired leakage. As for the minimum size, I too think this is a safe assumption, though I=20 need to check. I already wrote a skript that breaks the list up into=20 different buckets according to the first byte. I just added a little=20 check to see what the largest and smallest prefixes are: This is the output (number of different prefixes sorted per first byte): smallest prefix =3D 24, largest =3D 11 total 6486 15 =3D 7 16 =3D 4 32 =3D 15 40 =3D 7 44 =3D 1 53 =3D 3 57 =3D 1 60 =3D 1 62 =3D 312 63 =3D 4 64 =3D 5 66 =3D 14 69 =3D 5 80 =3D 249 81 =3D 221 82 =3D 153 83 =3D 49 128 =3D 15 129 =3D 16 130 =3D 23 131 =3D 27 132 =3D 2 134 =3D 11 135 =3D 1 136 =3D 5 137 =3D 9 138 =3D 16 139 =3D 18 140 =3D 4 141 =3D 20 143 =3D 9 144 =3D 13 145 =3D 23 146 =3D 27 147 =3D 19 148 =3D 13 149 =3D 21 150 =3D 2 151 =3D 5 152 =3D 6 153 =3D 13 154 =3D 6 155 =3D 24 156 =3D 10 157 =3D 6 158 =3D 10 159 =3D 23 160 =3D 20 161 =3D 9 162 =3D 7 163 =3D 9 164 =3D 21 166 =3D 1 167 =3D 1 168 =3D 7 170 =3D 7 171 =3D 5 192 =3D 532 193 =3D 1246 194 =3D 919 195 =3D 634 196 =3D 10 198 =3D 16 199 =3D 17 202 =3D 43 203 =3D 37 204 =3D 8 205 =3D 5 206 =3D 3 207 =3D 2 208 =3D 17 209 =3D 19 212 =3D 511 213 =3D 438 216 =3D 21 217 =3D 473 193.* is actually the one with most prefixes in it. > After one of these "temporary" marks is inactive for a while, remove it f= rom the MARK X list, increase the "time to stay" for networks which are use= d often. >=20 > So, your server apps should trigger a script (in the background) upon eve= ry new connection (maybe some tcpwrappers can do that, maybe you have to mo= dify a tcpwrapper). >=20 > make sure to update the database used by the scripts, Geo::IP has a "prem= ium database subscription" update thingy. I just talked today with the owner about this and I think I'll go=20 another way. I might use netfilter's connection tracker so that the=20 lookup that decides which class to use is only done on connection setup=20 and not per packet. Still, 6000 rules are too much so I'm going to=20 create a hierarchical ruleset to minimize the worst case. I don't want=20 to have anything beyond 30 rules worst case checking or so because the=20 server runs different applications and I should not make my presence=20 negatively noticeable. I think that is the best approach in this situation. Thanks for all the advice! CU Ren=E9 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/