Mapping Subscriber Domains to Access and Session Options

To configure a domain map for subscriber management:

Subscriber management supports a wildcard domain map feature that enables you to configure a domain mapping that is based on a partial wildcard match. When there is no exact match between the subscriber domain name and a configured domain map, subscriber management next looks for a partial match between the subscriber domain name and a wildcard domain map.

To create the wildcard domain map, you include the asterisk wildcard character when you configure the domain map name, such as, domain map example*. You can insert the wildcard character anyplace within the domain map, and the wildcard can represent zero or any number of characters. The asterisk is the only supported wildcard character.

For example, the configuration statement domain map example*northern.com creates a wildcard domain map that is a partial match for all domain names beginning with example and ending with northern.com, such as examplenorthern.com, example-northern.com, and example1234northern.com. However if you move the wildcard character in the domain map name to domain map example-northern*.com, this creates a more restrictive match that requires the partial matching domain names to start with example-northern, such as example-northern555.com or example-northern-alpha.com.

Wildcard domain mapping is also useful when subscriber management derives subscriber usernames from the DHCPv4 Agent Remote ID (option 82 suboption 2) or the DHCPv6 Remote-ID (option 37). In these cases, the resultant username is in the format subscriberID|service-plan|accountID|unused; for example, EricSmith|premiumTier1|314159265|0000 (where the | character is the delimiter). In this example, subscriber management parses the username left-to-right, and identifies the subscriber’s domain as premiumTier1|314159265|0000. To create a wildcard domain map that is used for this subscriber, you might configure domain map premiumTier1*.

The following example describes how four subscribers are mapped to different domains.

For this example, there are three domain maps configured; the default domain map, a domain map named example3000.com, and a wildcard domain map named example*. The subscribers are mapped as shown in the following list:

• eric@example3000.com—There is an exact domain map match, so the subscriber is mapped to domain example3000.com.

• jack@example1001.com—There is no exact match, but there is a partial match to the wildcard domain, so the subscriber is mapped to the wildcard domain example*.

• ginger@example-western.com—There is no exact match, but there is a partial match to the wildcard domain, so the subscriber is also mapped to the wildcard domain example*.

• sunshine@test.com—There is no exact match, nor is there a partial match to the wildcard domain, so the subscriber is mapped to the default domain.

To configure a wildcard domain map:

You use access profiles to specify the access rules and options (for example, the RADIUS authentication server and attributes) that the router applies to subscriber sessions. The domain map feature enables you to apply a specific access profile for subscribers in a particular domain.

Access profiles can be specified or modified in several different ways. If conflicts occur, the router applies the access profiles based on the precedence rules shown in Table 2.

To include an access profile in a domain map:

You can use the domain map feature to specify the address pool that the router uses to allocate address for subscriber sessions. The address pool can include both IPv4 and IPv6 address ranges.

Address pools can be specified or modified in several different ways. If conflicts occur, the router applies the address pool based on the precedence rules shown in Table 3.

To specify the address pool used for a domain map:

A dynamic profile defines the set of characteristics that provide dynamic access and services for subscriber sessions (such as class-of-service, protocols, and interface support). The domain map feature enables you to apply a specific dynamic profile based on subscriber domains.

Dynamic profiles are configured at the [edit dynamic-profiles] hierarchy, and can be specified or modified in several different ways. If conflicts occur, the router applies the dynamic profiles based on the precedence rules shown in Table 4.

To include a dynamic profile in a domain map:

By default, a domain map uses the subscriber logical system/routing instance as the context in which the authd daemon sends AAA authentication and accounting requests. You can optionally configure the domain map to direct AAA requests to a particular context, based on the subscriber domain name. Specifying a non-default AAA context enables you to manage workflow and traffic load, and to efficiently make changes for a large number of subscribers. For example, after upgrading your RADIUS services, you might configure a domain map to specify that all subscribers in the domain example.com are now authenticated by a RADIUS server in a particular AAA context.

To configure the logical system/routing instance context used for AAA requests:

By default, the router places a subscriber in the logical system/routing instance context of the interface on which the subscriber negotiations start. You can later change the routing instance of the subscriber’s context through the use of either a domain map or the RADIUS authentication server.

Subscriber management is supported in the default logical system only, however you can configure the domain map to use a non-default routing instance. Also, if a non-default routing instance is already configured, you can configure the domain map to use the default routing instance.

To configure the logical system/routing instance context used for a subscriber’s interface :

Tunnel profiles specify tunnel definitions (for example, a set of L2TP tunnels and their attributes) that the router applies to subscriber sessions. The domain map feature enables you to apply a specific tunnel profile to subscribers in a particular domain.

To include a tunnel profile in a domain map:

Tunnel switch profiles determine whether packets in an L2TP subscriber session from a LAC are switched to another session that has a different destination LNS. The tunnel switch profile can also specify how certain L2TP AVPs are handled when the packets are switched to a second tunnel. The domain map feature enables you to apply a specific tunnel switch profile to subscribers in a particular domain.

To include a tunnel switch profile in a domain map:

You can configure how the router determines the domain names that are used for the domain mapping feature. At the global level, you can specify rules that are used for domain maps. The global rules enable you to specify additional characters that the router can recognize as domain or realm name delimiters and to specify the direction the router uses to parse domain or realm names. The purpose of parsing a domain or realm name is to identify a single, unique name that the router uses as the subscriber’s domain name, regardless of whether the source of the name is in the typical domain name format (joseph@example.com) or in the realm name format (example.com\marilyn). The router uses the resulting domain name for operations such as domain map lookup and processing. At the domain map level, you can also enable domain name stripping. Domain name stripping specifies that the router remove the parsed domain or realm name from the subscriber username prior to performing any additional processing for the domain map.

To configure domain name usage rules for domain maps:

A delimiter is the character that separates a subscriber username from the domain or realm name. Delimiters are commonly used for domain or realm name parsing or domain name stripping. You can specify a maximum of eight delimiters that the router uses to recognize domain or realm names for a domain map. If you do not configure any delimiters, the router uses the @ character by default for domain names. There is no default delimiter for realm names.

For example, your network might include the subscribers bob@test.com, pete!example.com, and test.net\maria. In this case, you would configure the router to recognize the characters @ and ! as domain name delimiters, and the \ character as a realm name delimiter.

Keep the following guidelines in mind when specifying delimiters:

• You cannot use the semicolon (;) as a delimiter.

• If you configure optional domain name delimiters, you must also specify the @ character (the default delimiter) if you want to continue to use it as a delimiter.

• If you configure optional domain name delimiters and then unconfigure them, the router sets the domain map delimiter back to the default @ character.

To configure domain and realm name delimiters for domain maps:

The router parses the username domain or realm name in order to identify a single, unique name that the router uses as the subscriber’s domain name, regardless of whether the source of the name is in the typical domain name format (joseph@example.com) or in the realm name format (example.com\marilyn). You can specify the whether the router first searches the subscriber username for a domain name or for a realm name. If the router does not find the specified name (for example, you specify realm-first and there is no realm name in the username), then the router searches for the second type of name (domain name, in this case). If the router does not find either a realm-name or a domain name, then there is no domain that can be used for domain mapping operations.

To configure the domain name parsing direction for domain maps:

You can specify the direction in which the router performs the parsing operation it uses to identify subscriber domain or realm names for domain maps. During the parsing operation, the router searches the username until it recognizes a delimiter. It then considers anything to the right of the delimiter as the domain. By default, the router parses from right to left, starting at the right-most character in the username.

The router uses a subscriber’s domain name to perform domain map lookup and processing operations. You can configure how the router identifies a unique domain name when the user’s name is presented in a traditional domain name format or a realm name. In the traditional domain name format, the user’s name is followed by the domain name; for example, joe@example.com. In the realm name format, the user’s name is preceded by the domain name, referred to as the realm name; for example, example.com@joe. The purpose of parsing a domain or realm name is to identify a single name that the router uses as the subscriber’s domain name, regardless if the source of the name is the user’s original domain name or realm name. The router uses the resulting domain name for operations such as domain map lookup and processing. At the domain map level, you can also enable domain name stripping.

The domain parsing direction you use is important when there are nested domain names. For example, for the username user1@test.com@example.com, right-to-left parsing produces a domain name of example.com. For the same username, left-to-right parsing produces a domain name of test.com@example.com.

To configure the domain name parsing direction for domain maps:

You can configure the router to strip the domain name from usernames before any AAA services are used. Domain name stripping is done for domain maps. The router uses the delimiters and parsing direction you globally configure to determine the domain name that is removed. For example, if the router uses the default delimiter and parsing direction right-to-left, the username user1@example.com is stripped to be user1.

To configure the router to strip the domain name from usernames in a domain map:

For some use cases, you might want to provision L2TP LAC subscriber usernames and authentication passwords off the router chassis. You can strip off the user portion of the username and override the user password.

You can configure how the router identifies the user portion to be stripped when the username is presented in either the traditional domain name format or the realm name format. In the traditional domain name format, the user’s name is followed by the domain name; for example, joe@example.com. In the realm name format, the user’s name is preceded by the domain name, referred to as the realm name; for example, example.com@joe.

You can specify the direction in which the router performs the parsing operation that it uses to identify the user portion of the username. During the parsing operation, the router searches the username until it recognizes a delimiter. By default, the router parses from left to right, starting at the left-most character in the username. Everything to the left of the delimiter is the user portion. This direction works for the traditional domain name format. With this configuration, the router identifies and strips joe from joe@example.com.

For usernames in the realm name format, you need to change the parsing direction to right-to-left. The router parses from right to left, starting at the right-most character in the username. When the router recognizes the delimiter, it considers anything to the right of the delimiter as the user portion. With this configuration, the router identifies and strips joe from example.com@joe.

To configure the user portion to be stripped from the username for all usernames associated with a domain map:

Specify the parsing direction you want the router to use:

• Use left-to-right when the username is in the typical domain name format, in which the domain name follows the user’s name.

• Use right-to-left when the username is in the realm name format, in which the realm name precedes the user’s name.

You can specify a new password to override the existing password for authenticating any subscriber associated with the domain map. To override the password:

• Specify the override password for PAP authentication.

• Specify the override password for CHAP authentication.