ISG Reboot and subscriber database/static routes issue

[Olivier ARRIGHI]

Hi Folks, i have a few issues with ISG regarding the handling of customers when the ISG router crashes or reboots.

I'm using option 82 with DHCP, and clients can connect correctly to the ISG router.

The ISG generate a static route toward the QinQ customer, and the subscriber database is OK

The ISG is acting as a DHCP relay, and author is done through a remote radius.

Everything is fine on this side.

ISG#sh subscriber session
Current Subscriber Information: Total sessions 1

Uniq ID Interface    State         Service      Identifier           Up-time
2       IP           authen        Local Term   ABCDEF               04:17:15

ISG#sh ip route static

Gateway of last resort is x.x.x.x to network 0.0.0.0

      x.x.75.0/32 is subnetted, 195 subnets
S        x.x.75.247 is directly connected, TenGigabitEthernet3/1/0.501

Now If there is a hard reboot of the ISG (crash, power supply issue,...) then after reboot , the subscriber database is empty and the generated static routes are gone.

In this situation I have to wait that clients renew their DHCP lease before they can access Internet again. This is not acceptable, especially if the lease is long.

Is there a way to work around this behavior? are you using very short leases? is there a way to have the subscriber database synced remotely and then redownload the database and re install the static routes after the ISG reboots?

thanks for your help guys

OA

[Manuel Rodriguez · Accepted solution]

Hi Olivier,

You may want to try the DHCP database feature. It allows you to copy the DHCP database of the device on a file (even on a remote location). After a reload, the device should be able to rebuild the DHCP database from the file. More on that feature can be found at:

http://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpsv.html#wp1061906

After the DHCP database is restored from the file, sessions should be able to restart and corresponding subscriber routes should be re-added.

Hope it helps.

Regards.

[Olivier ARRIGHI]

Thanks for your help, i'll try this later this week and will post results

;)

Cisco says it is a flat file used to store the database, do you know if this is scalable with 15K users?

By the way, do you know a reasonable dhcp lease for those 15K ftth customers? I have trouble getting some common practices about that

thanks

[Manuel Rodriguez]

Hi Olivier,

I could not find any restriction in the documentation in terms of scalability so I think is worth trying it with 15k users.

Regarding lease time, that's not a straight forward topic. It depends on the nature of the clients. If they are relatively static, then a longer lease time would be good (to avoid overhead from DHCP traffic and processing time at relay agent and server). If time is too short, then you may have too much DHCP traffic which can create overhead and potentially processing issues in relay agent/server. From what I've seen around, 1 day seems to be a common practice.

Regards.

[Olivier ARRIGHI]

Thanks Manuel for the trick. It does work.

However, this is to remind that it is not really vrf aware. You might be able to use it in a vrf if ftp source interface is defined in the box with a vrf (to be tested) but in my case, ftp source interface command is already used with management interface in a different vrf. A vrf info would be great in the CLI command that defines the location of the database.

cheers