Previous Page
Next Page

Case Studies

This section contains issues and solutions that may be considered slightly more uncommon than those contained within the preceding section of the chapter.

Case Study 1: Remote AAA

This case study examines some of the issues that can arise in a configuration that involves remote AAA.

All remote AAA issues are examined with reference to the topology in Figure 2-38. There is one NAS, LODI_NAS1, and one Home Gateway, PERRIS_HGW1. The remote access client is dialing in to the LODI_NAS1.

Figure 2-38. Remote AAA Scenario Topology

[View full size image]


Issue 1: Misconfigured L2F Tunnel Definition on the AAA Server

Storing tunnel definitions and configuration on a AAA server can be a convenient way of managing your L2F VPDNs. If the tunnel definition is misconfigured, however, tunnel setup will fail.

Tunnel definitions can be configured using either Cisco AV-pairs or standard IETF attributes. In this scenario, Cisco AV-pairs are used.

When troubleshooting this issue, the first thing to do is to confirm that the tunnel definition is being correctly downloaded from the AAA server. To do this, the command debug aaa authorization can be useful, as demonstrated in Example 2-98.

Example 2-98. Incomplete Tunnel Definition Downloaded
LODI_NAS1#debug aaa authorization
AAA Authorization debugging is on
LODI_NAS1#
Jan 28 18:02:57.815 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
   1111
Jan 28 18:03:26.263 GMT: As38 AAA/AUTHOR/FSM: (0): LCP succeeds trivially
Jan 28 18:03:26.267 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up
Jan 28 18:03:26.547 GMT: AAA: parse name=Async38 idb type=10 tty=38
Jan 28 18:03:26.547 GMT: AAA: name=Async38 flags=0x11 type=4 shelf=0 slot=0 adapter=0
   port=38 channel=0
Jan 28 18:03:26.551 GMT: AAA: parse name=Serial0/0:0 idb type=13 tty=-1
Jan 28 18:03:26.551 GMT: AAA: name=Serial0/0:0 flags=0x55 type=1 shelf=0 slot=0
   adapter=0 port=0 channel=0
Jan 28 18:03:26.551 GMT: AAA/MEMORY: create_user (0x623B38A0) user='mjlnet.com'
   ruser='' port='Async38' rem_addr='1111/7777' authen_type=NONE service=LOGIN priv=0

In highlighted lines 1 and 2, interface serial 0/0:0 is connected to 1111, and interface async 38 changes state to up. The remote access client has connected.

Then in highlighted line 3, user mjlnet.com is created. This is the domain name supplied in the remote access client's authentication response.

Note that the tunnel definition is stored on the AAA server under the username that corresponds to the client's domain name.

Authorization for user mjlnet.com now begins (see Example 2-99).

Example 2-99. Authorization for User mjlnet.com Begins
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): Port='Async38'
   list='default' service=NET
Jan 28 18:03:26.551 GMT: AAA/AUTHOR/VPDN: Async38 (4199196954) user='mjlnet.com'
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): send AV service=ppp
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): send AV protocol=vpdn
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): found list "default"
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): Method=radius (radius)

Highlighted line 1 shows that authorization for the network service (NET) is sought by LODI_NAS1. Note that the network service includes PPP. Specifically, authorization is sought for the PPP service (highlighted line 2), and the VPDN protocol (highlighted line 3).

Highlighted line 4 shows that the default method list will be used, and highlighted line 5 indicates that authorization will be sought from a RADIUS server.

In Example 2-100, authorization succeeds.

Example 2-100. Authorization Succeeds
Jan 28 18:03:26.687 GMT: AAA/AUTHOR (4199196954): Post authorization
  status = PASS_REPL
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV gw-password=cisco
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV nas-password=cisco
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV tunnel-id=LODI_NAS1
Jan 28 18:03:26.691 GMT: AAA/MEMORY: free_user (0x623B38A0) user='mjlnet.com' ruser=''
   port='Async38' rem_addr='1111/7777' authen_type=NONE service=LOGIN priv=0
Jan 28 18:03:26.931 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected from
   1111 , call lasted 29 seconds
Jan 28 18:03:28.763 GMT: %LINK-5-CHANGED: Interface Async38, changed state to reset
Jan 28 18:03:35.183 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down
LODI_NAS1#

Highlighted line 1 in Example 2-100 shows that authorization has succeeded (PASS_REPL). A number of attribute-value (AV) pairs are downloaded from the RADIUS server, and these are shown in highlighted lines 2 to 4.

Everything is looking good, and then in highlighted line 5, interface serial 0/0:0 is disconnected from 1111. Furthermore, in highlighted line 6, interface async 38 changes state to down. The remote access client has been disconnected.

More clarity can be obtained using the debug radius command, as demonstrated in Example 2-101.

Example 2-101. Output of debug radius
LODI_NAS1#debug radius
Radius protocol debugging is on
LODI_NAS1#
Jan 28 18:04:14.627 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
   1111
Jan 28 18:04:45.055 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to up
Jan 28 18:04:45.343 GMT: RADIUS: authenticating to get author data
Jan 28 18:04:45.343 GMT: RADIUS: ustruct sharecount=2
Jan 28 18:04:45.343 GMT: RADIUS: Initial Transmit Async33 id 22 172.16.5.1:1645,
   Access-Request, len 85
Jan 28 18:04:45.343 GMT:         Attribute 4 6 AC100101
Jan 28 18:04:45.347 GMT:         Attribute 5 6 00000021
Jan 28 18:04:45.347 GMT:         Attribute 61 6 00000000
Jan 28 18:04:45.347 GMT:         Attribute 1 11 63697363
Jan 28 18:04:45.347 GMT:         Attribute 30 6 37373737
Jan 28 18:04:45.347 GMT:         Attribute 31 6 31313131
Jan 28 18:04:45.347 GMT:         Attribute 2 18 C73FDAE1
Jan 28 18:04:45.347 GMT:         Attribute 6 6 00000005
Jan 28 18:04:45.363 GMT: RADIUS: Received from id 22 172.16.5.1:1645, Access-Accept,
   len 119
Jan 28 18:04:45.363 GMT:         Attribute 26 30 0000000901187670
Jan 28 18:04:45.363 GMT:         Attribute 26 31 0000000901197670
Jan 28 18:04:45.363 GMT:         Attribute 26 32 00000009011A7670
Jan 28 18:04:45.363 GMT:         Attribute 6 6 00000005
Jan 28 18:04:45.363 GMT: RADIUS: saved authorization data for user 623B3924
  at 623B3B5C
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:gw-password=cisco"
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:nas-password=cisco"
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:tunnel-id=LODI_NAS1"
Jan 28 18:04:45.367 GMT: RADIUS: authenticating to get author data
Jan 28 18:04:45.371 GMT: RADIUS: ustruct sharecount=2
Jan 28 18:04:45.599 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected from
   1111 , call lasted 30 seconds
Jan 28 18:04:47.439 GMT: %LINK-5-CHANGED: Interface Async33, changed state to reset
Jan 28 18:04:54.191 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to down
LODI_NAS1#

In highlighted line 1, interface serial 0/0:0 is connected to 1111, and in highlighted line 2, interface async 33 changes state to up. The remote access client is connected to the NAS.

Then in highlighted line 3, an Access-Request message is sent to the RADIUS server. A number of attributes are included in this Access-Request, which are listed directly below highlighted line 3.

In highlighted line 4, the RADIUS server responds with an Access-Accept message, indicating that authentication has been successful. Again, a number of attributes are included in the Access-Accept message, which are shown in highlighted lines 5 to 7.

The downloaded attributes make up the tunnel definition.

Shortly thereafter, in highlighted lines 8 and 9, interface serial 0/0:0 is disconnected from 1111, and interface async 33 changes state to down. The client has been disconnected.

The NAS downloads a tunnel definition from the RADIUS server and then almost immediately disconnects the client. This might indicate a problem with the tunnel definition itself. The tunnel definition is then examined on the RADIUS server. In this case a Cisco Secure Access Control Server (Cisco Secure ACS).

Figure 2-39 shows the tunnel definition on the RADIUS server.

Figure 2-39. Tunnel Definition on the RADIUS Server

[View full size image]


If you look closely at the tunnel definition, you can see that one crucial attribute is missingthe IP address of the Home Gateway.

The IP address of the Home Gateway is defined using the Cisco AV pair (009/001) vpdn:ip-addresses=ip_address. This attribute is then added to the tunnel definition on the RADIUS server.

Note that the tunnel definition in Figure 2-39 does not include the Cisco AV pair vpdn:tunnel-type=tunnel_protocol. This is OK because the default tunnel protocol on Cisco routers is L2F.

Figure 2-40 shows the reconfiguration of the tunnel definition.

Figure 2-40. Reconfiguration of Tunnel Definition

[View full size image]


Once the tunnel definition has been reconfigured, the client reconnects, and tunnel establishment succeeds.

Successful tunnel establishment is verified using the show vpdn tunnel all command, as demonstrated in Example 2-102.

Example 2-102. Tunnel Establishment Now Succeeds
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 8
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 5
Gateway IP address 172.16.2.2
State: open
Packets out: 286
Bytes out: 7850
Packets in: 283
Bytes in: 7196
LODI_NAS1#

Highlighted line 1 shows that one tunnel and one session have been established. Highlighted lines 2 through 4 show the Home Gateway's name (PERRIS_HGW1), CLID (5), and IP address (172.16.2.2).

The client session is then examined using the show vpdn session command. Example 2-103 shows the output of the show vpdn session command.

Example 2-103. Client Session Information
LODI_NAS1#show vpdn session

% No active L2TP tunnels

L2F Session Information Total tunnels 1 sessions 1

 CLID   MID    Username                   Intf          State
 6      5      joebloggs@mjlnet.com        As36          open
LODI_NAS1#

In highlighted line 1, you can see that a session has been established for client joebloggs@mjlnet.com. The issue is resolved.

When troubleshooting the tunnel definition, there are a number of other issues for which to look out. Ensure that the user (domain) associated with the tunnel definition on the RADIUS server is configured with the password cisco. This password is hard-coded for tunnel definitions on Cisco routers. Also, make sure that the Service-Type (attribute 6) is configured as outbound or dialout framed. These attributes can be found under Group setup on the Cisco Secure ACS. Lastly, make sure that No IP Assignment (attribute 8) is configured within the User or Group setup if you are configuring a Cisco Secure ACS.

Note that if you see the message No response from server in the output of the debug radius command, this indicates that the server is unreachable. You should, therefore, troubleshoot connectivity issues.

NOTE

For more information on IETF tunnel attributes, see RFC 2868. Additionally, see the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a00800879eb.html

For more information on RADIUS attributes in general, see the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/scdradat.htm

Note that you can get a quick explanation of the output of the debug radius command by pasting the output into the Output Interpreter on the Cisco Web site (https://https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl). Login is required for the Output Interpreter.

From Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the debug radius command.


Before finishing this case study, it worth also taking a look at an L2F tunnel definition (using Cisco AV pairs) in Merit format.

A correctly configured L2F tunnel definition for a Merit RADIUS server is shown in Example 2-104.

Example 2-104. Merit RADIUS L2F Tunnel Definition
mjlnet.com Password = "cisco"
Service-Type = Outbound-User,
cisco-avpair = "vpdn:tunnel-id=LODI_NAS1",
cisco-avpair = "vpdn:ip-addresses=172.16.2.2",
cisco-avpair = "vpdn:nas-password=cisco",
cisco-avpair = "vpdn:gw-password=cisco"

The tunnel definition is pretty self-explanatory. In line 1, the domain name is specified (mjlnet.com); this is the domain name supplied by remote access clients connecting to the NAS. You can also see the hard-coded password for Cisco routers specified here (cisco). In line 2, the service type (Outbound-User) is shown.

The remainder of the tunnel definition consists of the tunnel ID (LODI_NAS1), the IP address of the Home Gateway (172.16.2.2), and the tunnel secrets (both cisco, in this example).

Issue 2: Remote AAA (RADIUS) Authentication Fails for the Remote Access Client

A more scalable solution for supporting a large number of remote access clients is to store their usernames and passwords on a AAA server.

If you need to troubleshoot client authentication in this scenario, the first command to use is debug aaa authentication.

Example 2-105 shows the output of the debug aaa authentication command.

Example 2-105. Output of debug aaa authentication
PERRIS_HGW1#debug aaa authentication
AAA Authentication debugging is on
PERRIS_HGW1#
*Mar  1 01:16:45.995 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   up
*Mar  1 01:16:45.999 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar  1 01:16:45.999 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
   adapter=0 port=1 channel=0
*Mar  1 01:16:45.999 UTC: AAA/MEMORY: create_user (0x6249B848)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='172.16.1.1'
   authen_type=CHAP service=PPP priv=1
*Mar  1 01:16:45.999 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar  1 01:16:45.999 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
   adapter=0 port=1 channel=0
*Mar  1 01:16:45.999 UTC: AAA/MEMORY: create_user (0x6249B958)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
   authen_type=CHAP service=PPP priv=1

In highlighted line 1, interface virtual-access 1 changes state to up. The client has connected to the Home Gateway over the L2F tunnel. Then in highlighted line 2, user joebloggs@mjlnet.com is created.

Authentication is about to begin (see Example 2-106).

Example 2-106. Authentication Begins
*Mar  1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): port='Virtual-Access1'
   list='' action=LOGIN service=PPP
*Mar  1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): using "default" list
*Mar  1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): Method=LOCAL
*Mar  1 01:16:45.999 UTC: AAA/AUTHEN (3951084872): status = ERROR
*Mar  1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): Method=radius (radius)
*Mar  1 01:16:46.007 UTC: AAA/AUTHEN (3951084872): status = FAIL
*Mar  1 01:16:46.007 UTC: AAA/MEMORY: free_user (0x6249B958)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
   authen_type=CHAP service=PPP priv=1
*Mar  1 01:16:49.659 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   down
*Mar  1 01:16:49.659 UTC: AAA/MEMORY: free_user (0x6249B848)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='172.16.1.1'
   authen_type=CHAP service=PPP priv=1
PERRIS_HGW1#

In highlighted line 1, login authentication for service PPP begins. Highlighted lines 2 and 3 show that the first method of authentication in the default method list is local authentication.

In highlighted line 4, local authentication results in an error. Authentication using RADIUS (the second method in the default method list) begins in highlighted line 5. Highlighted line 6 shows that authentication using RADIUS has failed.

Interface virtual-access 1 now changes state to down (highlighted line 7), and the client is disconnected.

A bit more insight can be gained using the debug radius command. Example 2-107 shows the output of the debug radius command.

Example 2-107. Output of debug radius
PERRIS_HGW1#debug radius
Radius protocol debugging is on
PERRIS_HGW1#
*Mar  1 01:18:43.455 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   up
*Mar  1 01:18:43.459 UTC: RADIUS: ustruct sharecount=1
*Mar  1 01:18:43.459 UTC: RADIUS: Initial Transmit Virtual-Access1 id 10
   172.16.5.1:1645, Access-Request, len 102
*Mar  1 01:18:43.459 UTC:         Attribute 4 6 AC100202
*Mar  1 01:18:43.459 UTC:         Attribute 5 6 00000001
*Mar  1 01:18:43.459 UTC:         Attribute 61 6 00000005
*Mar  1 01:18:43.459 UTC:         Attribute 1 21 6A6F6562
*Mar  1 01:18:43.459 UTC:         Attribute 30 6 37373737
*Mar  1 01:18:43.459 UTC:         Attribute 31 6 31313131
*Mar  1 01:18:43.459 UTC:         Attribute 3 19 02EB11EF
*Mar  1 01:18:43.459 UTC:         Attribute 6 6 00000002
*Mar  1 01:18:43.459 UTC:         Attribute 7 6 00000001
*Mar  1 01:18:43.463 UTC: RADIUS: Received from id 10 172.16.5.1:1645, Access-Reject,
   len 32
*Mar  1 01:18:43.467 UTC:         Attribute 18 12 52656A65
*Mar  1 01:18:47.691 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   down
PERRIS_HGW1#

In highlighted line 1, interface virtual-access 1 changes state to up, and the client is connected to the Home Gateway. In highlighted line 2, the Home Gateway sends an Access-Request message to the RADIUS server to authenticate the client.

Then in highlighted line 3, the RADIUS server sends the Home Gateway an Access-Reject message. Authentication has failed, and in highlighted line 4, interface virtual-access 1 changes state to down. The client is disconnected.

The fact that authentication has failed indicates that the client's username or password may be misconfigured on either the client workstation or the RADIUS server. The client confirms that his username and password are correctly configured. This leaves only the RADIUS server. The username on the RADIUS server is correctly configured. This means that the password must be incorrectly configured. The password is then reconfigured.

Figure 2-41 shows the reconfiguration of the client password in the user setup (or at least the User Setup configuration boxtake my word that the password has been reconfigured).

Figure 2-41. Reconfiguration of the User Password

[View full size image]


As soon as the password has been reconfigured, the client reconnects, and this time, authentication is successful. This is verified using the show user caller command, as demonstrated in Example 2-108.

Example 2-108. Output of the show caller user Command (Continued)
PERRIS_HGW1#show caller user joebloggs@mjlnet.com

  User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
        Active time 00:00:59, Idle time 00:00:04
  Timeouts:            Absolute  Idle
      Limits:          -         -
      Disconnect in:   -         -
  PPP: LCP Open, multilink Closed, CHAP (<- AAA), IPCP
  IP: Local 172.16.2.2, remote 10.10.10.50
  VPDN: NAS LODI_NAS1, MID 9, MID open
        HGW  PERRIS_HGW1, NAS CLID 8, HGW CLID 8, tunnel open
  Counts: 57 packets input, 5626 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          27 packets output, 0 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets

PERRIS_HGW1#

Highlighted line 1 shows that the user is connected to interface virtual-access 1.

In highlighted lines 2 through 4, you can see that LCP, CHAP, and IPCP have been successfully negotiated with the remote access client. Multilink PPP was not negotiated with the client and remains in a Closed state. The issue is resolved.

Note that if you see the message No response from server in the output of the debug radius command, this indicates that the server is unreachable. In this case, you should troubleshoot connectivity issues.

NOTE

For more information on RADIUS attributes, see the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/scdradat.htm

Note that you can get a quick explanation of the output of the debug radius command by pasting the output into the Output Interpreter on the Cisco Web site (https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl).

Note that login is required for the Output Interpreter.

Also, from Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the debug radius command.


Issue 3: Remote AAA (RADIUS) Authorization Fails for the Remote Access Client

When using remote AAA on the Home Gateway, it is important to remember that the RADIUS server must not only authenticate the client but also authorize services used by the client. If authorization is not correctly configured, the client connection may fail.

Use the debug aaa authorization command to debug this issue. Note that Example 2-109 shows only the relevant portion of debug output.

Example 2-109. Authorization Fails for the Remote Access Client
PERRIS_HGW1#debug aaa authorization
AAA Authorization debugging is on
PERRIS_HGW1#
*Mar  1 01:32:52.719 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   up
*Mar  1 01:32:52.723 UTC: Vi1 AAA/AUTHOR/FSM: (0): LCP succeeds trivially
*Mar  1 01:32:52.723 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar  1 01:32:52.723 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
   adapter=0 port=1 channel=0
*Mar  1 01:32:52.723 UTC: AAA/MEMORY: create_user (0x624C2688)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
   authen_type=CHAP service=PPP priv=1
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP: Authorize LCP

In highlighted line 1, interface virtual-access 1 changes state to up. The remote access client has connected to the Home Gateway.

Then in highlighted line 2, user joebloggs@mjlnet.com is created.

Authorization now begins (see Example 2-110).

Example 2-110. Authorization Begins
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): Port='Virtual-Access1'
   list='' service=NET
*Mar  1 01:32:52.743 UTC: AAA/AUTHOR/LCP: Vi1 (2875175667) user='joebloggs@mjlnet.com'
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): send AV service=ppp
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): send AV protocol=lcp
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): found list "default"
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): Method=radius (radius)
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR (2875175667): Post authorization
  status = FAIL
*Mar  1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP: Denied
*Mar  1 01:32:52.743 UTC: AAA/MEMORY: free_user (0x624C2688)
   user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
   authen_type=CHAP service=PPP priv=1
*Mar  1 01:32:57.027 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   down
PERRIS_HGW1#

Highlighted line 1 shows that the Home Gateway is seeking authorization for the Network (NET) service. Note that the Network service includes PPP. Specifically, the Home Gateway is seeking authorization for service PPP and protocol VPDN (see highlighted lines 2 and 3). Highlighted lines 4 and 5 show that the Home Gateway has selected RADIUS for authorization from the default method list. Then in highlighted line 6, authorization fails. Finally, in highlighted line 7, interface virtual-access 1 changes state to down. The debug radius command is then used to gain further insight.

Example 2-111 shows the output of the debug radius command.

Example 2-111. Authorization Sequence with the debug radius Command
PERRIS_HGW1#debug radius
Radius protocol debugging is on
PERRIS_HGW1#
*Mar  1 01:34:26.355 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   up
*Mar  1 01:34:26.359 UTC: RADIUS: ustruct sharecount=1
*Mar  1 01:34:26.359 UTC: RADIUS: Initial Transmit Virtual-Access1 id 16
   172.16.5.1:1645, Access-Request, len 102
*Mar  1 01:34:26.359 UTC:         Attribute 4 6 AC100202
*Mar  1 01:34:26.359 UTC:         Attribute 5 6 00000001
*Mar  1 01:34:26.359 UTC:         Attribute 61 6 00000005
*Mar  1 01:34:26.359 UTC:         Attribute 1 21 6A6F6562
*Mar  1 01:34:26.359 UTC:         Attribute 30 6 37373737
*Mar  1 01:34:26.359 UTC:         Attribute 31 6 31313131
*Mar  1 01:34:26.359 UTC:         Attribute 3 19 038C5703
*Mar  1 01:34:26.359 UTC:         Attribute 6 6 00000002
*Mar  1 01:34:26.359 UTC:         Attribute 7 6 00000001
*Mar  1 01:34:26.379 UTC: RADIUS: Received from id 16 172.16.5.1:1645, Access-Accept,
   len 38
*Mar  1 01:34:26.379 UTC:         Attribute 6 6 00000001
*Mar  1 01:34:26.379 UTC:         Attribute 7 6 00000001
*Mar  1 01:34:26.379 UTC:         Attribute 8 6 FFFFFFFF
*Mar  1 01:34:26.379 UTC: RADIUS: no appropriate authorization type for user.
*Mar  1 01:34:30.067 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
   down
PERRIS_HGW1#

Interface virtual-access 1 changes state to up in highlighted line 1. The client is now connected to the Home Gateway. Highlighted line 2 shows that the Home Gateway has sent an Access-Request to the RADIUS server. Then in highlighted line 3, the Home Gateway receives an Accept-Accept from the RADIUS server. Highlighted line 4 indicates that the Home Gateway has not received appropriate authorization for the client. Finally, interface virtual-access 1 changes state to down, and the client is disconnected. Authorization occurs but not the right type.

The next step is to examine the client's user amd group setup on the RADIUS server.

Figure 2-42 shows the client's group setup on the RADIUS server.

Figure 2-42. Client's User Setup

[View full size image]


As you can see, in the IETF RADIUS Attributes configuration, the Service-Type (attribute 6) is configured as Login, and the Framed-Protocol (attribute 7) is configured as PPP.

The Framed-Protocol is correctly configured, but the Service-Type is misconfigured. Instead of Login, the Service-Type should be configured as Framed.

The Service-Type is then reconfigured as Framed, as shown in Figure 2-43.

Figure 2-43. Reconfiguration of the Service-Type

[View full size image]


Once the Service-Type has been reconfigured, the client reconnects, and authorization succeeds. This is verified using the show caller user command.

Example 2-112 shows the output of the show caller user command.

Example 2-112. Output of the show caller user Command
PERRIS_HGW1#show caller user joebloggs@mjlnet.com

  User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
        Active time 00:01:14, Idle time 00:00:08
  Timeouts:            Absolute  Idle
      Limits:          -         -
      Disconnect in:   -         -
  PPP: LCP Open, multilink Closed, CHAP (<- AAA), IPCP
  IP: Local 172.16.2.2, remote 10.10.10.50
  VPDN: NAS LODI_NAS1, MID 15, MID open
        HGW  PERRIS_HGW1, NAS CLID 14, HGW CLID 14, tunnel open
  Counts: 46 packets input, 4286 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          31 packets output, 0 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets

PERRIS_HGW1#

Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to the Home Gateway over an L2F tunnel.

In highlighted line 2, you can see that LCP, authentication, and IPCP have been successfully negotiated with the client. Multilink PPP (MP) has not been negotiated with the client and so remains in a Closed state. The issue is now resolved.

Note that if you see the message No response from server in the output of the debug radius command, the server is unreachable. If this is the case, you should troubleshoot connectivity issues between the Home Gateway and the RADIUS server.

NOTE

For more information on RADIUS attributes, see the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/scdradat.htm

You can also get an explanation of the output of the debug radius command by pasting the output into the Output Interpreter on the Cisco Web site (https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl).

A CCO account is required for the Output Interpreter.

From Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the debug radius command.


Case Study 2: Cannot Complete an L2F Tunnel from an Offload Server to the Home Gateway

When configuring an L2F tunnel from an offload server in a Multichassis Multilink PPP (MMP) environment, the tunnel from the offload server (NAS) to the Home Gateway will fail unless multihop VPDN is used.

It is important to remember that when using a Stack Group Bidding Protocol (SGBP) group in a MMP environment, Multilink PPP (MP) and possibly regular PPP connections (if you are using the command sgbp ppp-forward), are tunneled to the bid winner or offload server using L2F tunnels (or L2TP in more recent versions of Cisco IOS software).

Note that the tunnel protocol used can be changed using the sgbp protocol {any | l2f | l2tp} command. If you want to tunnel the PPP traffic arriving in these MMP L2F tunnels from the offload server to a Home Gateway, you are in effect connecting inbound tunnels from SGBP members to the outbound tunnel to the Home Gateway. This interconnection of tunnels requires careful configuration.

In the following scenario, two front-end NASsLODI_NAS1 and LODI_NAS2are configured to forward PPP traffic to an offload server, LODI_OFFLOAD. LODI_OFFLOAD is then configured to tunnel the PPP connections onward to the Home Gateway, PERRIS_HGW1, as illustrated in Figure 2-44.

Figure 2-44. LODI_OFFLOAD Tunnels MP Links to PERRIS_HGW1

[View full size image]


It is apparent, however, that although PPP traffic is being tunneled successfully from LODI_NAS1 and LODI_NAS2 to the offload server, LODI_OFFLOAD, the L2F tunnel from there to the PERRIS_HGW1 is not functioning correctly.

The show user command on LODI_OFFLOAD shows that two MP sessions have been successfully tunneled from the front-end NASs, LODI_NAS1 and LODI_NAS2 (see Example 2-113).

Example 2-113. MP Links Are Being Tunneled to the Offload Server
LODI_OFFLOAD#show user
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00
  Interface      User        Mode                     Idle     Peer Address
  Vi1          joebloggs@ Virtual PPP (L2F   )        -
  Vi3          joebloggs@ Virtual PPP (L2F   )        -
  Vi4          joebloggs@ Virtual PPP (Bundle) 00:00:54 172.16.2.7
LODI_OFFLOAD#

As you can see, one MP session for user joebloggs@mjlnet.com is being terminated on interface virtual-access1, another on interface virtual-access3, and the two are bundled together on interface virtual-access4. You can also see that both MP connections are tunneled to LODI_OFFLOAD via L2F tunnels (see highlighted lines 1 and 2). A look at the output of the show ppp multilink command even shows you from where each MP session is tunneled.

Example 2-114 shows the output of the show ppp multilink on LODI_OFFLOAD.

Example 2-114. show ppp multilink Reveals the Origin of Each MP Session
LODI_OFFLOAD#show ppp multilink
Virtual-Access4, bundle name is joebloggs@mjlnet.com
  Bundle up for 00:01:05
  Using relaxed lost fragment detection algorithm.
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
  0x0 received sequence, 0x0 sent sequence
  Member links: 2 (max not set, min not set)
    LODI_NAS1:Virtual-Access1  (172.16.1.1), since 00:01:05, no frags rcvd,
      unsequenced
    LODI_NAS2:Virtual-Access3  (172.16.1.3), since 00:00:14, no frags rcvd,
      unsequenced

LODI_OFFLOAD#

Highlighted lines 2 and 3 show that the MP connection terminated on interface virtual-access 1 is coming from LODI_NAS1 (172.16.1.1), and the MP session terminating on interface virtual-access 3 is coming from LODI_NAS2.

In highlighted line 1, there is confirmation that these two MP sessions are bundled together on interface virtual-access 4.

At this stage all looks good, but the output of the command show vpdn tunnel in Example 2-115 reveals that not all of the expected L2F tunnels are, in fact, in place.

Example 2-115. Not All the L2F Tunnels Have Been Established
LODI_OFFLOAD#show vpdn tunnel
%No active L2TP tunnels
L2F Tunnel Information Total tunnels 2 sessions 2
 NAS CLID HGW CLID NAS Name        HGW Name        State
 38       5        LODI_STACK        LODI_STACK        open
                   172.16.1.3      172.16.1.4
 37       21       LODI_STACK        LODI_STACK        open
                   172.16.1.1      172.16.1.4
%No active PPTP tunnels
%No active PPPoE tunnels
LODI_OFFLOAD#

In highlighted line 1 in Example 2-115, you can see that there are a total of two L2F tunnels, with a total of two active sessions. If you look at highlighted line 2, you can see that one tunnel is from 172.16.1.3 (LODI_NAS2) to 172.16.1.4 (LODI_OFFLOAD), and in highlighted line 3, one tunnel is from 172.16.1.1 (LODI_NAS1) to 172.16.1.4 (LODI_OFFLOAD).

Notice that the Home Gateway and NAS names for both tunnels is LODI_STACK. This is because LODI_NAS1, LODI_NAS2, and LODI_OFFLOAD are all configured in SGBP group LODI_STACK and are authenticated with each other as such.

One problem is evident in the output in Example 2-113, however. The expected tunnel from LODI_OFFLOAD to the Home Gateway, PERRIS_HGW1, is not present.

To begin with, regular L2F troubleshooting is the way to go. In this case, call reception consists of the successful tunneling of PPP frames from LODI_NAS1 and LODI_NAS2 to LODI_OFFLOAD. You know that this is successful from the output of the previous show commands.

The next step is to troubleshoot the building of the tunnel from LODI_OFFLOAD to PERRIS_HGW1. For this particular tunnel, LODI_OFFLOAD is functioning as the L2F NAS device, and PERRIS_HGW1 is the L2F Home Gateway.

Because call reception has been verified already, the next thing to do is check that there is basic IP connectivity between the NAS (LODI_OFFLOAD) and the Home Gateway (PERRIS_HGW1) using the ping command, as shown in Example 2-116.

Example 2-116. Testing IP Connectivity to the Home Gateway
LODI_OFFLOAD#ping 172.16.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
LODI_OFFLOAD#

You can see from the output in Example 2-116 that the IP connectivity seems to be OK. Do not forget, however, that ping only tests whether ICMP Echo Request and Reply messages can be sent between the two devices.

Having established IP connectivity between the two devices, it is time to verify L2F tunnel establishment. To do this, you can use debug vpdn l2x-events, as demonstrated in Example 2-117.

Example 2-117. debug vpdn l2x-events Shows L2F Tunnel Setup
LODI_OFFLOAD#debug vpdn l2x-events
Jan 27 02:05:32.489 UTC: L2X: L2F_CONF received
Jan 27 02:05:32.489 UTC: Tnl 41 L2F: Received L2F-CONF from LODI_STACK
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Opened UDP socket to 172.16.1.1 using
  source 172.16.1.4
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Tunnel LODI_STACK state change from closed
  state opening
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Sending L2F-CONF to peer
Jan 27 02:05:32.509 UTC: Tnl 41 L2F: L2F_OPEN received
Jan 27 02:05:32.513 UTC: Tnl 41 L2F: OPEN from LODI_STACK received for tunnel in
  state opening

Jan 27 02:05:32.513 UTC: Tnl 41 L2F: Tunnel LODI_STACK state change from opening
  state open

Jan 27 02:05:32.513 UTC: Tnl 41 L2F: Replying to LODI_STACK with L2F-OPEN

In highlighted line 1, an L2F_CONF is received from LODI_STACK. At this stage, it is not clear which member of SGBP group LODI_STACK has sent this L2F_CONF.

Then in highlighted line 2, LODI_OFFLOAD opens a UDP socket to 172.16.1.1 (LODI_NAS1), and in highlighted line 3 sends a L2F_CONF to LODI_NAS1. Therefore, the L2F_CONF in highlighted line 1 was from LODI_NAS1.

An L2F_OPEN is now received from LODI_NAS1 in highlighted line 4. LODI_OFFLOAD responds with an L2F_OPEN, and L2F tunnel establishment is complete.

L2F client session establishment now begins, as shown in Example 2-118.

Example 2-118. L2F Session Establishment Begins
Jan 27 02:05:32.525 UTC: Tnl 41 L2F: L2F_OPEN received
Jan 27 02:05:32.529 UTC: Tnl 41 L2F: New OPEN received for Session 27
Jan 27 02:05:32.529 UTC: joebloggs@mjlnet.com Tnl/Cl 41/27 L2F: Session state
  change from closed to opening
Jan 27 02:05:32.565 UTC: %LINK-3-UPDOWN: Interface Virtual-Access3, changed
  state to up

Jan 27 02:05:32.569 UTC: Vi3 Tnl/Cl 41/27 L2F: Transfer NAS-Rate L2F/0/0 to LCP
Jan 27 02:05:32.573 UTC: Vi3 Tnl/Cl 41/27 L2F: Created VA for Mid, Replying with
   OPEN
Jan 27 02:05:32.573 UTC: Vi3 Tnl/Cl 41/27 L2F: Session state change from opening
   to open
Jan 27 02:05:32.757 UTC: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
  state to up
Jan 27 02:05:33.575 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access3, changed state to up

Jan 27 02:05:33.763 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access2, changed state to up

In highlighted line 1, a L2F_OPEN is received from LODI_NAS1. This initiates L2F session establishment. L2F_OFFLOAD replies with an L2F_OPEN in highlighted line 2. Then in highlighted lines 3 and 4, the line protocol on virtual access interfaces 3 and 2 changes state to up.

LODI_OFFLOAD is terminating the MP link from LODI_NAS1 on interface virtual-access 3. Interface virtual-access 4 is used to bundle the MP links (including the one from LODI_NAS1).

Next, L2F tunnel setup from LODI_NAS2 begins (see Example 2-119).

Example 2-119. L2F Tunnel Setup from LODI_NAS2 Begins
Jan 27 02:05:46.060 UTC: L2X: L2F_CONF received
Jan 27 02:05:46.064 UTC: Tnl 42 L2F: Received L2F-CONF from LODI_STACK
Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Opened UDP socket to 172.16.1.3 using
  source 172.16.1.4

Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Tunnel LODI_STACK state change from closed
  state opening
Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Sending L2F-CONF to peer
Jan 27 02:05:46.084 UTC: Tnl 42 L2F: L2F_OPEN received
Jan 27 02:05:46.084 UTC: Tnl 42 L2F: OPEN from LODI_STACK received for tunnel in
  state opening
Jan 27 02:05:46.088 UTC: Tnl 42 L2F: Tunnel LODI_STACK state change from opening
  state open
Jan 27 02:05:46.088 UTC: Tnl 42 L2F: Replying to LODI_STACK with L2F-OPEN

L2F tunnel establishment from LODI_NAS2 (172.16.1.3, highlighted line 2) begins with the receipt of an L2F_CONF in highlighted line 1. LODI_OFFLOAD responds with an L2F_CONF in highlighted line 3. LODI_NAS2 and LODI_OFFLOAD then exchange L2F_OPEN messages in highlighted lines 4 and 5, and the L2F tunnel is set up.

L2F client session setup from LODI_NAS2 now begins (see Example 2-120).

Example 2-120. L2F Session Setup from LODI_NAS2 Begins
Jan 27 02:05:46.100 UTC: Tnl 42 L2F: L2F_OPEN received
Jan 27 02:05:46.100 UTC: Tnl 42 L2F: New OPEN received for Session 8
Jan 27 02:05:46.104 UTC: joebloggs@mjlnet.com Tnl/Cl 42/8 L2F: Session state
  change from closed to opening
Jan 27 02:05:46.136 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
  state to up

Jan 27 02:05:46.140 UTC: Vi1 Tnl/Cl 42/8 L2F: Transfer NAS-Rate L2F/0/0 to LCP
Jan 27 02:05:46.144 UTC: Vi1 Tnl/Cl 42/8 L2F: Created VA for Mid, Replying with
  OPEN
Jan 27 02:05:46.144 UTC: Vi1 Tnl/Cl 42/8 L2F: Session state change from opening
  to open
Jan 27 02:05:47.149 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to up

LODI_OFFLOAD#

In highlighted lines 1 and 2, LODI_NAS2 and LODI_OFFLOAD exchange L2F_OPEN messages, and the L2F session is established. Finally, the line protocol on interface virtual-access 1 changes state to up. This interface terminates the MP link from LODI_NAS2.

L2F tunnel and session setup is operating correctly between both LODI_NAS1 and LODI_NAS2 and LODI_OFFLOAD. Unfortunately, there is no evidence of L2F tunnel setup from LODI_OFFLOAD to the Home Gateway (PERRIS_HGW1). This points to a possible configuration error on LODI_OFFLOAD. Example 2-121 shows the relevant portion of LODI_OFFLOAD's configuration.

Example 2-121 shows the VPDN configuration on LODI_OFFLOAD.

Example 2-121. LODI_OFFLOAD's VPDN Configuration
PERRIS_HGW1#show running-config
Building configuration...
vpdn enable
!
vpdn-group 1
 request-dialin
  protocol l2f
  domain mjlnet.com
 initiate-to ip 172.16.5.1
!

At first glance, this configuration looks good. One crucial command is missing, however. This command would allow LODI_OFFLOAD to pass packets from the two incoming tunnels from LODI_NAS1 and LODI_NAS2 to the tunnel that it should establish to PERRIS_HGW1. The command is vpdn multihop.

The configuration is corrected in Example 2-122.

Example 2-122. vpdn multihop Is Added to the VPDN Configuration
LODI_OFFLOAD#conf t
Enter configuration commands, one per line.  End with CNTL/Z
LODI_OFFLOAD(config)#vpdn multihop
LODI_OFFLOAD(config)#exit
LODI_OFFLOAD#

One further action is required: Both existing tunnels must now be cleared and reinitiated from LODI_NAS1 and LODI_NAS2 to ensure forwarding over the new tunnel to PERRIS_HGW1.

Use the clear vpdn tunnel command to clear and reinitiate L2F tunnels from LODI_NAS1 and LODI_NAS2 (see Example 2-123).

Example 2-123. L2F Tunnels from LODI_NAS1 and LODI_NAS2 Are Cleared
LODI_OFFLOAD#clear vpdn tunnel l2f LODI_STACK LODI_STACK
Clearing all MIDs and dropping the tunnel

L2F tunnel establishment is then verified again using the show vpdn tunnel command. Example 2-124 shows the output of the show vpdn tunnel command after the L2F tunnel from LODI_NAS1 and LODI_NAS2 have been re-established.

Example 2-124. L2F Tunnel from LODI_OFFLOAD Is Now Established to PERRIS_HGW1
LODI_OFFLOAD#show vpdn tunnel
%No active L2TP tunnels
L2F Tunnel Information Total tunnels 3 sessions 4
 NAS CLID HGW CLID NAS Name        HGW Name        State
 44       8        LODI_STACK        LODI_STACK        open
                   172.16.1.3      172.16.1.4
 43       24       LODI_STACK        LODI_STACK        open
                   172.16.1.1      172.16.1.4
 9        45       LODI_OFFLOAD    PERRIS_HGW1     open
                   172.16.1.4      172.16.5.1
%No active PPTP tunnels
%No active PPPoE tunnels
LODI_OFFLOAD#

Both of the original tunnels are back, but now there is an additional tunnel from LODI_OFFLOAD to PERRIS_HGW1 (172.16.5.1).

The final step is to verify that the MP sessions are being correctly terminated on PERRIS_HGW1. This is done using the show ppp multilink command, as demonstrated in Example 2-125.

Example 2-125. Output of the show ppp multilink Command
PERRIS_HGW1#show ppp multilink
Virtual-Access3, bundle name is joebloggs@mjlnet.com
  Bundle up for 00:03:13
  Using relaxed lost fragment detection algorithm.
  0 lost fragments, 0 reordered, 0 unassigned
  0 discarded, 0 lost received, 1/255 load
  0x0 received sequence, 0x0 sent sequence
  Member links: 2 (max not set, min not set)
    LODI_OFFLOAD:Virtual-Access1  (172.16.2.1), since 00:03:13, no frags rcvd,
      unsequenced
    LODI_OFFLOAD:Virtual-Access2  (172.16.2.1), since 00:03:13, no frags rcvd,
      unsequenced

PERRIS_HGW1#

You can see that there are two MP sessions tunneled from LODI_OFFLOAD (172.16.2.1) and terminating on interfaces virtual-access 1 and 2 (highlighted lines 2 and 3).

These two sessions are then bundled together on interface virtual-access 3 (highlighted line 1). The issue is resolved.

NOTE

For more information about configuring MMP, see the article entitled "Multichassis Multilink PPP (MMP)" on the Cisco Web site (www.cisco.com).

For more information on the VPDN multihop feature, see the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/multih2.htm



Previous Page
Next Page