Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Oct 1998 00:16:09 -0600
From:      "Jeffrey J. Mountin" <jeff-ml@mountin.net>
To:        N <niels@bakker.net>, freebsd-isp@FreeBSD.ORG
Subject:   Re: route changes erratically (routed)
Message-ID:  <3.0.3.32.19981026001609.007161e8@207.227.119.2>
In-Reply-To: <981026001156.13499A-100000@liquid.tpb.net>
References:  <19981025131724.A19988@worldgate.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 12:15 AM 10/26/98 +0100, N wrote:
>Quoth Greg Skafte:
>
>> except that the portmaster is supposed to advertise /29 /30 ... etc. 
>> if that is the valid subnet of a current session.  If you don't want to
>> see routes other than the /28 you need to have the portmaster agregate 
>> the routes to the desired netmask .... 
>
>Livingston^WLucent PortMasters can't do that.  There are two ways to avoid
>polluting your IGP (be it RIPv2 or OSPF based): either set the pool size
>to 32 or 64 (depending on the amount of E1/T1's into your PM3) and start
>the assigned pool at the same boundary, or filter IGP announcements later
>on, possibly utilising route summaries.
>
>> this is the nature of vlsm routing ... you can have routes for most 
>> of any cidr block and still redirect smaller pieces to other places.
>
>PM's suck in this regard, they can generate a handful of routes for a
>block even if they only miss one IP address in it to make it to the next
>^2 natural boundary, and there's no way to tell them to aggregrate it
>anyway.

Care to explain a bit more.  No offense, but I think your off you rocker. :/

Nn excellent feature of the OSPF with a PM2 would be the ability to set
pool-size=32 and use x.y.z.0/27 and x.y.z.224/27, but both x.y.z.0 and
x.y.z.255 would NEVER be assigned.  Instead of 14 routes for 8 PM2's you
have just 8 and life is good.  Plus this scales better than using RIP
and/or static routes and most importantly it would work excellent for those
with E1's on a PM3, unless you don't care to lose 24 IPs for nothing more
than having only one route per unit.

The PM's DO aggregate routes with OSPF just fine, with a little planning
you can really reduce the routes.

Your idea of using using 64 IPs when only 46/48 are needed for T1
implementations is just a plain waste of addresses.  Consider that only 4
and not 5 PM3's can fit on a /24 and instead of having 14 IP addresses that
could used for other purposes, they are wasted.  This also forces you to
use static routes, since with OSPF it would assign .0 and .255 giving some
user a dead connection.  A good example of poor network planning if I ever
saw one.

The most efficient way is to use OSPF and start the first PM3 on .8 and the
whole /24 would be divided like so:

.8   - .55  1st (4 routes)
.56  - .103 2nd (3 routes)
.104 - .151 3rd (4 routes)
.152 - .199 4th (3 routes)
.200 - .247 5th (4 routes)

Only 18 routes total.  Staring on .1 gives 33 routes.  Starting with .2
will only reduce the total to 29 routes.  And this is not "pollution" as
you say, but proper behaviour.  Plug static routes or let OSPF do it's job,
but don't complain about having more than one route per unit.

FWIW, you could gain another 5 or 10 more free IPs if you are using PRI's
at the cost of more routes.  Never bothered to figure out the best way for
this, since using one D channel for more than one PRI isn't common (was
unsupported at the time).  Might be worth it for a PM4 or Assend, but then
I don't think they have a "working" OSPF implemenation yet.  Ditto for
USR/3Com, AFAIK.

No clue why you mention route summaries, when you need to summarize routes
only before BGP insertion.  It has zero relevance to this thread and has
nothing to do with the behavior of OSPF with a PM.  Even if it were, why
bother?  What point is there, oh yeah BGP.  No point there either.  You
need to summarize *anyways* or else your provider is going to bitch.
Nothing less than a /24 should be announced via BGP.  If you have less than
a /24 you shouldn not announce via BGP, only listen.

regards


Jeff Mountin - Unix Systems TCP/IP networking
jeff@mountin.net

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19981026001609.007161e8>