We have routers with ISDP PRI links, where the routing information arrives from RADIUS via a CHAP login. There are 600 routed objects in the RADIUS database, as well as 10k+ non-routed (dynamic IP) objects. Every ISDN router therefore has a potential 600 directly attached neighbors; although no router has more than 60 links at any one time. Some common equipment may handle this just barely; other is wholly inadequate.
It sounds to me like what you would really like was something akin to the "RPF check" as done on multicast traffic for unicast traffic on your customer routers, perhaps as a per-interface option. If this feature existed you would not accept a packet from a given source and incoming interface unless the box in question has a route for the source pointing back out the same interface. That way you would not get the administrative burden of maintaining access lists and ensuring they're always in synch with the local view of the routing system. Doing this on the customer border routers appears to me to be the obviously right place. Doing this in a place where asymmetrical routing is the norm (as appears to be the case in the current backbones) is obviously a non-starter. I think this has been mentioned several times to various providers in the past without this feature materializing, but one can still hope. (It's not unconceivable that the current access products have not been engineered with sufficient CPU resources to be able to even perform this task...) - Håvard
In message <199801081407.PAA10688@vader.runit.sintef.no>, Havard.Eidnes@runit.sintef.no writes:
We have routers with ISDP PRI links, where the routing information arrives from RADIUS via a CHAP login. There are 600 routed objects in the RADIUS database, as well as 10k+ non-routed (dynamic IP) objects. Every ISDN router therefore has a potential 600 directly attached neighbors; although no router has more than 60 links at any one time. Some common equipment may handle this just barely; other is wholly inadequate.
It sounds to me like what you would really like was something akin to the "RPF check" as done on multicast traffic for unicast traffic on your customer routers, perhaps as a per-interface option. If this feature existed you would not accept a packet from a given source and incoming interface unless the box in question has a route for the source pointing back out the same interface. That way you would not get the administrative burden of maintaining access lists and ensuring they're always in synch with the local view of the routing system.
Or possibly as a RADIUS option, where we really want address integrity; not a filter list; and are willing to accept packets with source addresses fitting a set of ip aggregates.
Doing this on the customer border routers appears to me to be the obviously right place. Doing this in a place where asymmetrical routing is the norm (as appears to be the case in the current backbones) is obviously a non-starter.
Can you trust the customer border router ? I personally don't. Anyone can go out and buy a router and hook it up to the internet; even getting a routed block of addresses doesn't cost all that much.
I think this has been mentioned several times to various providers in the past without this feature materializing, but one can still hope. (It's not unconceivable that the current access products have not been engineered with sufficient CPU resources to be able to even perform this task...)
- Håvard
-- ___ === / / / __ ___ _/_ === Morten Reistad, Network Manager === /--- / / / / /__/ / === EUnet Norway AS, Sandakerveien 64, Oslo === /___ /__/ / / /__ / === <Morten.Reistad@Norway.EU.net> === Connecting Europe since 1982 === phone +47 2209 2940
participants (2)
-
Havard.Eidnes＠runit.sintef.no -
Morten Reistad