Hi all,
I was wondering on peoples ideas that we should delete current ip
allocations, and do it again, based on simple geographical information. As
far as I can see, this won't have to long a impact, at most a week (right
James?)
The disadvantages for giving them away now:
- Lack of route aggregation (supernetting), which leads to more
resources needing to processor/memory to run the LSA alogorythm.
- Route flapping (ie, an interface going up/down) causing LSA
computations (which can be fixed by OSPF areas).
- In the future when we need to fix some of these problems,
(scalbility) it will be harder and take longer, than if we wait a little
while now.
Route Aggregation is where routers advertise larger routes to other boxes
who don't need to know all the smaller routes.
For example, if you had 4 /24's (keep in mind we are using /28's) like
this
[172.16.0.0] \ [10.10.10./24] / [172.16.4.0]
[172.16.1.0] \ [router A ] -> [router B] / [172.16.5.0]
[172.16.2.0] / | \ [172.16.6.0]
[172.16.3.0] / | \ [172.16.7.0]
|
[border router C]
Why would router B need to know about all of router's A tables, when it
increases memory/cpu/convergence time, when all router B would need to know
is 172.16.0.0/22?
Route flapping is where a network is not advertised, then is advertised
(mebe a cable is unplugged and plugged in again..). Due to OSPF having
triggered updates (and reverse poison and soone), the network has to
recalcuate the Shortest Paths. Route aggregation helps prevent this because
it will still advertise a larger network. (erm, something I'm not exactly
sure on if the first or last subnet is taken out of it. Possibly zebra has
an option to make it auto summerise quickly.)
If we instead have the IP addresses handled out on first serve/first come
basis, we can't summerise the routes, and the routing tables become larger
and larger.
With the border routers, (assuming we give IP addresses relative to the
area), can advertise its whole area with say a /22 covering all the
smaller /28's, which is opposed to exchanging smaller routes, because these
networks are scattered all over Melbourne. In my given diagram, all router
C would have to know is 172.16.0.0/20. Granted, my diagram is simplistic,
but it should demonstrate why I mean effectively. (please keep that it'd be
difficult*, if not impossible to make a fully meshed topology, there will
be links similar to this.)
Assuming I've made sense here and people agree with me (please tell me why
I'm wrong :), mebe I don't understand all this/smoking crack/*) What is the
optimal basic areas, in IRC James and I discussed about these issues (I
could attach the log if people wanted, but you'll haveto wait till I get
home), he suggested 8 areas (N, NE, E, SE, S, SW, W, NW), possibly 16.
While I can understand peoples frustation at waiting longer, myself I
prefer to wait a week for better network performance, and possibly having
to fix this in the future, where people have already been given and are
seriously using their IP allocations.
IPv6 won't fix these particular problems, as I suspect IPv4 will still be
in use for a while yet. For example, I can't think of any games (given I
don't play games all that often), that support IPv6. (How many ISP's have
fully IPv6 addresses and infrastructure? Yes, you can tunnel, but its
ugly :))
If you've read this far, double thanks for listening/reading ;)
Sincerely,
Andrew Griffiths
P.S Has anyone looked at zebra to see if you can strike routes from a
routing exchange / whatever. This would be useful if people's routers
mistakenly advertise 192.168.58.0 because they two subnets/whatever.
P.P.S For people tunneling traffic over a wired equipment, possibly have a
look at interface binding/bonding/whatever and load balence.
P.P.P.S Who wants to get together and play with OSPF on day? I suspect that
using seperate wireless channels would be easier (assuming you had two
interfaces) than MAC address blocking? If we wanted to be adventorous, we
could do a mixture of wired / 2 wireless / single wireless and stuff :)
* difficult = council permission, planes, equipment, lack of
pcmcia/irqs/io's etc, and so on. It'd be possible within smaller areas, but
in whole, its not going to happen across melbourne.
To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message