Subject: Re: (usr-tc) Radius and VPN-Neighbor

From: "G. Douglas Davidson" <[email-masked]>
Date: Fri, 04 Feb 2000 19:26:16 +0000

On Feb 3,  2:06pm, G. Douglas Davidson wrote:
> Subject: Re: (usr-tc) Radius and VPN-Neighbor
> On Feb 3, 12:28pm, Brian wrote:
> > Subject: Re: (usr-tc) Radius and VPN-Neighbor
> >
> > What attribute id are you using.  I have used:
> >
> > VENDORATTR  429	USR-VPN-Neighbor	36872	ipaddr
> >
> > successfully.  It has to be one hop away to work however.
> >
>
> I have tried both of these attribute formats:
>
> ATTRIBUTE	USR-PW_VPN_Neighbor		0x9008	ipaddr
> ATTRIBUTE	USR-PW_VPN_Neighbor		36872	ipaddr
>

I believe that I have the attribute successfully transmitted to the TC.  The
format that worked for me was:

ATTRIBUTE       USR-PW-VPN-Neighbor                     36872   ipaddr  USR

with the Radius users file set:

USR-PW-VPN-Neighbor = 198.144.34.46,

I end up with:

INFORMATION FOR SESSION     me
Service Type:                            Framed
Framed Protocol:                         PPP
Speed of Connection:                     Auto
Login Service:                           Telnet
Interface Name:                          slot:9/mod:4
IEA Next Hop Gateway IP Address:         198.144.34.46
Active Session ID:                       2031616
Framed IP Netmask:                       0.0.0.0
Framed Routing:                          None
Framed Callback Identifier:              0
Framed MTU:                              1441
Compression Algorithm:                   None
Compression Reset Mode:                  Auto
Receive Acc Map:                         0
Transmit Acc Map:                        0

I neglected to increment a length field in the section of Radius that returns
attributes to the client, and so I stomped on a few things.

BUT, it still is not working.  I can ping the Next Hop Gateway.  It is on the
same subnet at the ethernet IP on the TC.  Some other settings:

IEA Radius Source Port Authentication      ENABLED
IEA User Radius supplied username          DISABLED
IP RIP                                     ENABLED
IP Number RIP Interfaces:                  1
IP Number RIP Neighbors:                   0
IP RIP Flags:                              METRICS
                                           SEND_REQUEST
IEA Next Hop Routing:                      ENABLED
IEA Send Unsolicited Proxy Arp:            DISABLED
IEA Force Next Hop Route:                  DISABLED

Any thought would be appreciated.

-- 
-----
G Douglas Davidson                      | CityNet, Inc.
[email-masked]                    | Pittsburgh, PA
voice: 412.481.5406			| fax: 412.431.1315

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: "G. Douglas Davidson" <[email-masked]>
Date: Tue, 28 Nov 2000 19:11:31 +0000

On Nov 10, 10:50am, G. Douglas Davidson wrote:
> Subject: Re: (usr-tc) RIPv2 CPU Issue
> On Nov 9, 11:33am, Jeff Mcadams wrote:
> > Subject: Re: (usr-tc) RIPv2 CPU Issue
> > Also sprach G. Douglas Davidson
> > >I've been using RIPv2 to allow our Cisco to route to our TCs, but I
> > >just noticed recently that RIP is a CPU hog on the Cisco.  It is
> > >consuming around 60 percent of the CPU.  Is there anything that can be
> > >done to decrease the amount of RIP updates that the TCs send?  Is OSPF
> > >less of a pig?  Should I segement things so that I proxy arp the
> > >regular dialups and only RIP a subnet for the people I need to route a
> > >subnet to?
> >
> > >Any thoughts appreciated.
> >
> > passive-interface on the cisco is your friend!
> >
> > If you passive-interface all of your RIP interfaces on the cisco, then
> > the cisco knows it doesn't have to keep track of many of the timers on
> > each route that it has to keep track of if its not set for
> > passive-interface.  Each route has a timer associated with it so the
> > router knows when it needs to rebroadcast the route back out again...by
> > eliminating these timers with the passive-interface command, I dropped
> > the cpu load on my 7507 from ~50% to ~15%
> >
> > The only thing you loose by putting passive-interface on everything on
> > the cisco is the ability for the cisco to inform the Arcs about routes
> > it has...but since the usual mode of deployment is for the Arcs to be
> > default routed to the cisco...you really don't loose much of any
> > functionality.
>
> Thanks for the pointer! When I did that though, the updates did not seem to
be
> getting through to the router.  I'm going to try again because is seems that
> some changes sort of blow the Cisco's mind for a bit.
>

I finally got around to finishing the "passive-interface" thing and it really
helped!  From 50 to 60 percent down to 10 to 15 percent.  Excellent!

Thanks a ton Jeff.

-