Yea ignoring radius attribute is not a solution because you are the one sending it and why the heck you will ignore it :)
Well, I suggest you add another static default route pointing to same gateway the one you are learning over OSPF. In this case if you learn default route on user profile you will already have one with lower administrative distance. I strongly suggest you change your application interface which should not permit 0.0.0.0 and such things entering to database while configuring user profile. Regards, Masood -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amr Sent: Monday, August 25, 2008 6:01 PM To: Truman Boyes Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Restricting RADIUS Routes for E120 Dear Truman, The Radius server used in my network is used to provide all the users with thier assigned IP subnets, and the assigned routes to the users are access-internal routes I have a default route in the E120 Router known via OSPF from my Gateway, so when the RADIUS Server by mistake sent framed-route (0.0.0.0/0) to a specific user , the default route is installed as access-internal route pointing to this specific user and all the upload for the E120 went to this users instead of the Gateway via OSPF( as the preferance for the access-internal routes are lower than the ospf routes) I can't ignore this RADIUS attribute as i am using the "framed-route" attribute to assign IP subnets for my users Thanks Amr On Mon, Aug 25, 2008 at 3:37 PM, Truman Boyes <[EMAIL PROTECTED]> wrote: > Hi Amr, > > Your RADIUS server is located upstream from the E120 right? Ie. It is not > an access-internal route but rather it is reachable via another protocol > such as BGP, static, or OSPF. Adjusting protocol preferences is less than > ideal and you should avoid this in almost all designs. > > Why do you say that the performance of the E120 is affected by the default > route that is assigned to a user? > > You can issue 'radius ignore <attribute>' commands to ignore specific > RADIUS messages that are included in the access-accept. I would not just fix > the problem here if the issue is really a mistake in a RADIUS profile > upstream; that would be the best place to fix the issue. > > Truman > > > > On 25/08/2008, at 2:21 AM, Amr wrote: > > Dear All, >> I have a problem in my E120 Router , where i have configured the >> RADIUS Server to send to the Users on the E120 thier IP Subnet so that the >> IP subnets of the users will be "Access-internal" routes as below >> >> E120#sh ip route 10.10.10.10 >> Protocol/Route type codes: >> I1- ISIS level 1, I2- ISIS level2, >> I- route type intra, IA- route type inter, E- route type external, >> i- metric type internal, e- metric type external, >> P- periodic download, O- OSPF, E1- external type 1, E2- external type2, >> N1- NSSA external type1, N2- NSSA external type2 >> L- MPLS label, V- VRF, *- via indirect next-hop >> Prefix/Length Type Next Hop Dst/Met >> Interface >> ------------------ --------- --------------- ---------- >> ----------------------- >> 10.10.10.10/32 *AccIntern *0.0.0.0 2/0 >> GigabitEthernet3/0/0.505252.59 >> >> >> but by mistake someone configured the RADIUS to send the default route >> (0.0.0.0.0/0) for a specific user which affects the performance of the >> E120 >> router and modifyed the current default route learned by OSPF >> >> So the Question is >> Is it possible to restrict the routes the comes from the RADIUS Server and >> not accepting it all (e.g denying the default route from the radius) ? >> or >> >> Is it possible to modify the admin distance for the Access-internal routes >> so that it will be higher that the dynamic default route configured on the >> E120 router ? >> >> Appreciate your help >> >> Thanks In Advance >> >> Regards >> Amr >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp