Local user database

A LUDB is identified by a unique name, up to 32 characters. Multiple LUDBs can be created for different applications. The LUDB must be administratively enabled to be operational.

The match criteria configured in a user-ordered match-list determine which of the input parameters provided by the application are considered for matching in the host identification fields of a LUDB host entry. Input parameters provided by the application that are not on the match list are ignored.

For some match criteria, an optional mask can be applied to the input parameter before searching for a matching LUDB host entry. Masking is prefix- or suffix-based, or a combination of both. A prefix or suffix string, or a prefix or suffix length, can be specified. The following tables summarizes masking examples. In the third example, a combination of both prefix and suffix string masks is used.

Different match criteria and masks for IPoE and PPP subscriber sessions can be configured simultaneously in a LUDB. At minimum, one criterion must be configured in the match list when LUDB host entries are created. The configuration of masks is optional.

For IPoE, from the available match criteria, up to four can be defined in the match-list: circuit-id, derived-id, dual-stack-remote-id, duid-en, duid-ll-llt, encap-tag-range, encap-tag-separate-range, ip, mac, option60, remote-id, sap-id, service-id, string, and system-id.

For PPP, from the available match criteria, up to three can be defined in the match-list: circuit-id, derived-id, encap-tag-range, encap-tag-separate-range, mac, remote-id, sap-id, service-name, and user-name.

The match criteria and masks that apply for a specific LUDB application are described in Subscriber session authentication in LUDB and LUDB lookup for DHCP server leases.

A host entry belongs to either the IPoE or the PPP section of a LUDB and is identified by a name of up to 32 characters that must be unique within the section.

A host entry contains two sets of parameters:

• host-identification fields used for matching input parameters during a LUDB lookup

  For IPoE, the host-identification fields are: circuit-id, derived-id, duid-en, duid-ll-llt, encap-tag-range, encap-tag-separate-range, ip-prefix, mac, option60, remote-id, sap-id, service-id, string, and system-id.

  For PPP, the host-identification fields are: circuit-id, derived-id, encap-tag-range, encap-tag-separate-range, mac, remote-id, sap-id, service-name, and user-name.

• output parameters returned to the application upon a successful lookup

  The output parameters of the lookup process include identification strings for subscriber session instantiation, DHCP options, IP address information, MSAP parameters, and so on.

Optionally, a default host with the name default can be configured as a wildcard in case the lookup fails to find a matching entry. Host identification fields should not be configured for the default host, as it is a match-all entry. If host identification fields are configured, the default host entry becomes a regular non-default host entry.

Host identification fields and output parameters that apply for a specific LUDB application are described in Subscriber session authentication in LUDB and LUDB lookup for DHCP server leases.

When a LUDB host entry is administratively enabled, the system uses the following validation criteria, before adding the entry to the lookup database:

• A non-default host entry must have at least one host-identification field defined.

• A non-default host entry with none of its host identification fields in common with the match-list is added to the list of unmatched hosts with “no match” as the reason.

• A non-default host entry is added to the lookup database when at least one of the defined host identification fields is in common with the match-list, even when some of the host identification fields are not on the match-list.

• Two or more non-default host entries with the same host identification definitions are duplicates. Only one host entry is added to the lookup database. Duplicates are added to the list of unmatched hosts with “duplicate” as the reason.

Use the following commands can be used to display the list of unmatched hosts.

show subscriber-mgmt local-user-db ppp-unmatched-hosts
show subscriber-mgmt local-user-db ipoe-unmatched-hosts  

The following rules apply while scanning through a LUDB in search of a single matching entry:

• Only criteria on the match-list are considered.

  For example, assume a client for which a MAC address, a circuit-id, and a remote-id are provided as input parameters. If the match-list only contains the MAC address as criterion, the circuit-id and the remote-id input parameters are ignored. Only the MAC address is used to find a matching host entry.

• The order of criteria on the match-list is important.

  The match-list is a user-ordered list, and the criteria are processed left to right.

• As many of the host-identification fields as possible must be matched, while still obeying the first item in this list.

  Only the optionally masked parameters from the match list are verified.

• The default host is excluded from the scan. It is used as a fallback when scanning through a LUDB yields no result.

The rules, as shown in the preceding figure, are described as follows:

• (A) Matching is based on the MAC-address only – When client-a with mac-1 connects, host entry ipoe-x is matched.

• (B) Matching is based on the MAC-address, circuit-id, and remote-id, in this sequence – As client-b enters with mac-1, cid-1, and rid-1, the match-list is scanned and matched left to right, so host ipoe-z is matched.

• (C) Matching is based on the MAC-address only – Even though client-c connects with mac-1, cid-1, and rid-1, the system ignores the circuit-id and the remote-id, so the matching host is ipoe-x. Host ipoe-y is never matched using the defined match-list; because it is on the unmatched host list.

• (D) Matching is based on the MAC-address and the circuit-id, in this sequence – Client-d connects with mac-1 and cid-2, but because the system scans the match-list left through right, the MAC address takes priority over the circuit-id. The matching host is ipoe-x.

The host-matching rules, as shown in the preceding figure, are described as follows:

• (E) For the top part, matching is based on MAC address and the circuit-id, in this sequence – When client-e connects (mac-1, cid-1, and rid-1), the system scans ludb-5-1 and matches host ipoe-x.

• (E) For the bottom part, matching is based on the circuit-id first, then the MAC address – When client-e connects (mac-1, cid-1, and rid-1), the system scans ludb-5-2 and matches host ipoe-y.

• (F) Matching is based on MAC address and the circuit-id, in this sequence – When client-f-1 (mac-1) connects, the matching host is ipoe-x because only the MAC address is provided and checked. When client-f-2 (cid-1) connects, the matching host is ipoe-y because only the client-id is provided and checked. When client-f-3 (mac-1, cid-1) connects, the matching host is ipoe-z.

• (G) Matching is based on the MAC address only – When client-g with mac-2 connects, host default is matched because there is no explicit entry matching mac-2.

As shown in the preceding examples, the system only checks parameters provided by the client in the sequence defined by the match-list. Other parameters are not checked.

A LUDB, on its own, is not functional. The LUDB must be associated with the intended application. The following tables provide an overview of the LUDB applications and the configuration to associate an LUDB with the application..

The following sections describe VLAN range matching and LUDB troubleshooting commands.

In PPPoE access scenarios without access node or with access nodes that do not insert PPPoE vendor specific tags Circuit ID or Remote ID, the user may be required to configure this information in the LUDB so that the Circuit ID and Remote ID access loop information tags can be picked up in the pre-authentication phase and used for RADIUS authentication and reporting in RADIUS accounting messages.

[ex:/configure subscriber-mgmt]
A:admin@node-2# info
    local-user-db "ludb-1" {
        ppp {
            match-list [user-name]
            host "host-1" {
                admin-state enable
                host-identification {
                    user-name {
                        name "cpe-1@domain1.com"
                    }
                }
                authentication {
                    radius-auth-policy "auth-policy-1"
                }
                access-loop-information {
                    circuit-id {
                        ascii-string "LUDB inserted circuit-id"
                    }
                    remote-id {
                        ascii-string "LUDB inserted remote-id"
                    }
                }
                password {
                    ignore
                }
            }
        }
    }

A:node-2>config>subscr-mgmt# info
----------------------------------------------
        local-user-db "ludb-1" create
             ppp
                match-list username
                host "host-1" create
                    access-loop-information
                        circuit-id string "LUDB inserted circuit-id"
                        remote-id string "LUDB inserted remote-id"
                    exit
                    host-identification
                        username "cpe-1@domain1.com"
                    exit
                    auth-policy "auth-policy-1"
                    password ignore
                    no shutdown
                exit
            exit
        exit
----------------------------------------------

[ex:/configure subscriber-mgmt]
A:admin@node-2# info
    local-user-db "chap-db" {
        admin-state enable
        ppp {
            match-list [derived-id user-name]
            host "testuser" {
                admin-state enable
                host-identification {
                    derived-id "testuser"
                    user-name {
                        name "testuser"
                    }
                }
                identification {
                    sla-profile-string "sla-2"
                }
                password {
                    chap "cYhRmQYW0kLW3s0LrtEnBjWlAwFa/1Kx" hash2
                }
            }
        }
    }
    
    local-user-db "padi-db" {
        admin-state enable
        ppp {
            match-list [derived-id]
            host "testuser" {
                admin-state enable
                host-identification {
                    derived-id "testuser"
                }
                authentication {
                    user-db "chap-db"
                }
                msap-defaults {
                    service 500
                    group-interface {
                        name "g1"
                    }
                }
            }
        }
    }

A:node-2>config>subscr-mgmt# info
----------------------------------------------
        local-user-db "chap-db" create
            ppp
                match-list derived-id username
                host "testuser" create
                    host-identification
                        derived-id "testuser"
                        username "testuser"
                    exit
                    password chap "cYhRmQYW0kLW3s0LrtEnBjWlAwFa/1Kx" hash2
                    identification-strings 254 create
                        sla-profile-string "sla-2"
                    exit
                    no shutdown
                exit
            exit
            no shutdown
        exit
       
        local-user-db "padi-db" create
            ppp
                match-list derived-id
                host "testuser" create
                    host-identification
                        derived-id "testuser"
                    exit
                    msap-defaults
                        group-interface "g1"
                        service 500
                    exit
                    user-db "chap-db"
                    no shutdown
                exit
            exit
            no shutdown
        exit
----------------------------------------------

See "Local User Database for DHCPv4 Server" in 7450 ESS, 7750 SR, and 7950 XRS Advanced Configuration Guides Part III for more information about LUDB lookup for DHCPv4 server leases.

Assigning a LUDB to a DHCPv6 server allows the server to insert DHCPv6 options for a specific DHCPv6 client or a group of DHCPv6 clients identified by the match criteria in the LUDB.

A local DHCPv6 server can be used for IPoE users and for PPP users. The LUDB lookup for the DHCPv6 server application is always performed in the IPoE section. The DHCPv6 client messages are encapsulated as follows:

• For IPoE clients, the DHCPv6 client messages received by the DHCPv6 server are encapsulated in Relay-Forward messages by an optional Lightweight DHCPv6 Relay Agent (LDRA) and a DHCPv6 relay agent.

• For PPPoE clients, the DHCPv6 client messages received by the DHCPv6 server are encapsulated in Relay-Forward messages by a DHCPv6 relay agent after PPPoE de-encapsulation.

The DHCPv6 server can be in the same router as the DHCPv6 relay agent, but that is not a requirement.