Large-Scale Dial-Out

feature? Does it work?

Yes, we're using it to dial in into remote VPN endpoints for troubleshooting (>100 devices).

The AAA backend is Cisco ACS; I'd choose a different radius server in the future, because adding/managing many devices via web gui is, hmm, suboptimal.

Beside this, LSDO does not cause any trouble on our 3640 NAS, running IOS 12.2(26) with a single PRI and virtual profiles.

BR,

Christian

Hello,

that sounds quite interesting. We're currently thinking about LSDO, too, for a ISDN/DSL-backup szenario with more then 1000 peers. It would be quite heavy to manage the dialer maps

Does that work with redundant synchronized Cisco ACS, too? What happens, if one of the configured redundant ACS is temporarily not reachable?

Are you able to provide some anonymized configuration example from you NAS? (maybe per PM...) Would be great :)

Thank you very much in advance,

Dennis Breithaupt

Christian Zeng wrote:

feature? Does it work?

Hi Dennis Hi Christian

A redundant ACS shouldn't be a problem. You just have to configure a tacacs group and the router will select the first answering ACS himself. LSDO doesn't seem a big deal on the router. Mainly a "Dialer" configuration with an additional "aaa route download" and a "dialer aaa" command. SGBP is only needed if you have more then one chassis which you wish to stack for failover/loadbalance. But off course: a real-life config would be usefull.. :-)

To me the configuration of the ACS/IAS (or whatever) seems the bigger deal. And as Christian allready mentioned: "Who's the volunteer who will sacrifice himself for entering about 1000 routes and 1000 users using the GUI of ACS or IAS and test all the dialers?" ;-) Before starting the project I surely would check for scripting possibilities as the ACS can import configuration data from clear text files:

with an additional "aaa route download" and

which you wish to stack for

You can find the LSDO-important parts of our config below. Some remarks:

We're only using this for remote administration, so I only need to connect to a lookpack address of the remote device. No additional routes for networks behind the dialed device or any routing protocol is involved.

For this simple setup, I decided not to define the static routes for the remote devices on the ACS and then let the router dynamically download them. The ACS only has the authentication and dialing information available for dynamic download. This eliminates the need for many dialer Interfaces/Maps on the router, but each device requires at least one static route entry in the config.

If you'd like to have this routing info on the ACS too, you can define them on the ACS and let the router download these router through "aaa route-download".

This can be handy if you want to route to networks behind the remote router and therefore the amount of route entries is much higher than having only one route for each devices.

Keep in mind that the router downloads and caches these routes, so one one side you'll lower the size of your config but on the other side these downloaded routes are stored in the routers RAM.

You need to create a user on the AAA server with the suffix "-out". Our config uses tacacs for AAA comm., but this can be done with radius, too. The profile hosts some attributes; we're only using outbound:send-auth (=2) for CHAP and outbound:dial-number for the dial string. If you have aaa authorization enabled (like we did), you must have a second user (without the -out suffix) with PPP IP and PPP LCP enabled. This password of this user is then used for ppp authentication at the remote peer.

You can extend the user profiles with attributes as described in the LSDO documentation.

Static routes are defined in a user profile for the router/NAS and not in the user profile of the remote device.

as the ACS can import configuration data

ACS bulk import capabilities are limited. You can import basic definitions like the username and authentication information, but not any additional attributes like the ones I mentioned above, IIRC. I'd prefer a RADIUS server with text config files or a database backend for LDSO profile information (freeradius & co.).

OK, here are the LSDO related parts of the config.

aaa new-model aaa group server tacacs+ tac_srv server XXX.XXX.XXX.XX ! aaa authentication ppp dialin group tac_srv local-case aaa authorization network default group tac_srv local ! controller E1 0/0 pri-group timeslots 1-31 ! interface Loopback2 description LSDO Loopback ip address YYY.YYY.YYY.1 no ip redirects no ip proxy-arp ! interface Serial0/0:15 description D-Channel encapsulation ppp dialer rotary-group 1 ! interface Dialer1 description LSDO ip unnumbered Loopback2 encapsulation ppp dialer in-band dialer aaa dialer idle-timeout 300 dialer-group 1 no peer default ip address ppp authentication chap callin dialin ! ip route YYY.YYY.YYY.2 255.255.255.255 Dialer1 name remote-rtr01 ip route YYY.YYY.YYY.3 255.255.255.255 Dialer1 name remote-rtr02 [...]

And a remote router:

username central-site password ... ! interface Loopback2 description Loopback DialIn ip address YYY.YYY.YYY.2 255.255.255.255 ! interface BRI0 description ISDN no ip address encapsulation ppp dialer pool-member 2 isdn switch-type basic-net3 ! interface Dialer2 description LSDO dialin ip unnumbered Loopback2 encapsulation ppp dialer pool 2 dialer remote-name central-site dialer idle-timeout 0 dialer caller dialer-group 1 no peer default ip address ppp authentication chap

Hi Christian

Thanks for the config! My hope is, that ACS 4.0 (announced for Nov 05) will be better at importing/exporting and automated creation of users. Regarding the memory: Off course I will need more memory with all the routes. But my problem is the growing config in NVRAM. I'm allready using over 110kBs off the available 128kBs. Disregarding the price: It's still easier to upgrade Flash & RAM than to upgrade the NVRAM on a 3640 router... ;-) On the other hand: Does anybody know if the 3640 supports booting a config rather from flash with "boot config slot0:verybig-config" than from NVRAM ?