Re: large routing table

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

You may wanna try this out (after adapting it a bit).
It's been written for the romanian iex in order to mark internal
traffic. It uses BGP tables and is quite fast. If you have access to BGP
routes then your task is to modify a script and add a cron job.
The address is http://sourceforge.net/projects/mipclasses/.

-- 
Adrian Vasile <adi@xxxxxxxxxx>

On Thu, 2004-04-01 at 00:19, Rene Gallati wrote:
> 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 
> bandwidth usage of about 1mbps to 2mbps max. I just need to make sure 
> that stays in the country, because if such bandwidth usage crosses 
> boundaries, its going to create costs that are unbearable.
> 
> > make MARK X not shaped.
> > 
> > MARK X some big networks which will always be Switserland.
> > 
> > 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 shaped, and if it's not part of the marked IP's already, you add an entry to the 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 
> "perfect" list, so I rather use this, especially because that list is 
> provided by the people who own the machine/network, so when in doubt I 
> 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 
> need to check. I already wrote a skript that breaks the list up into 
> different buckets according to the first byte. I just added a little 
> check to see what the largest and smallest prefixes are:
> 
> This is the output (number of different prefixes sorted per first byte):
> smallest prefix = 24, largest = 11
> total 6486
> 15 = 7
> 16 = 4
> 32 = 15
> 40 = 7
> 44 = 1
> 53 = 3
> 57 = 1
> 60 = 1
> 62 = 312
> 63 = 4
> 64 = 5
> 66 = 14
> 69 = 5
> 80 = 249
> 81 = 221
> 82 = 153
> 83 = 49
> 128 = 15
> 129 = 16
> 130 = 23
> 131 = 27
> 132 = 2
> 134 = 11
> 135 = 1
> 136 = 5
> 137 = 9
> 138 = 16
> 139 = 18
> 140 = 4
> 141 = 20
> 143 = 9
> 144 = 13
> 145 = 23
> 146 = 27
> 147 = 19
> 148 = 13
> 149 = 21
> 150 = 2
> 151 = 5
> 152 = 6
> 153 = 13
> 154 = 6
> 155 = 24
> 156 = 10
> 157 = 6
> 158 = 10
> 159 = 23
> 160 = 20
> 161 = 9
> 162 = 7
> 163 = 9
> 164 = 21
> 166 = 1
> 167 = 1
> 168 = 7
> 170 = 7
> 171 = 5
> 192 = 532
> 193 = 1246
> 194 = 919
> 195 = 634
> 196 = 10
> 198 = 16
> 199 = 17
> 202 = 43
> 203 = 37
> 204 = 8
> 205 = 5
> 206 = 3
> 207 = 2
> 208 = 17
> 209 = 19
> 212 = 511
> 213 = 438
> 216 = 21
> 217 = 473
> 
> 193.* is actually the one with most prefixes in it.
> 
> > After one of these "temporary" marks is inactive for a while, remove it from the MARK X list, increase the "time to stay" for networks which are used often.
> > 
> > So, your server apps should trigger a script (in the background) upon every new connection (maybe some tcpwrappers can do that, maybe you have to modify a tcpwrapper).
> > 
> > make sure to update the database used by the scripts, Geo::IP has a "premium database subscription" update thingy.
> 
> I just talked today with the owner about this and I think I'll go 
> another way. I might use netfilter's connection tracker so that the 
> lookup that decides which class to use is only done on connection setup 
> and not per packet. Still, 6000 rules are too much so I'm going to 
> create a hierarchical ruleset to minimize the worst case. I don't want 
> to have anything beyond 30 rules worst case checking or so because the 
> server runs different applications and I should not make my presence 
> negatively noticeable. I think that is the best approach in this situation.
> 
> Thanks for all the advice!
> 
> CU
> 
> RenÃ
> 
> _______________________________________________
> LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux