Introduction
Understanding how to debug PPPoE in IOS-XR for the ASR9K
Problem Description
Detailed step through guide for debugging PPPoE sessions.
Understanding BNG Architecture
Before we start troubleshooting sessions it is important to understand the architecture of how things link together. This overview below shows the different components as it related to PPP(oE).
In the next modules the various debugs will be elaborated on and some common things that generally go wrong.
1) 1) A session is initiated in PPPoE by the reception of a PADI packet in PPPoE. This PADI is a broadcast packet hitting the control plane. If the session is terminating on a physical (sub)interface, the PPPoE is handled on the linecard, if the session terminates as part of a bundle (sub)interface, PPPoE is handled by the RSP.
2) 2) The reception of a PADI triggers a “session-start” event in the control policy, during the session-start event we need to apply the dynamic template that holds at least the LCP specific parameters for when the session continues to PPP phase. Also we could do “pre-authentication” here based on PPPoE tag information in the session-start event.
3) 3) After we have sent the PADO to the client, and the client selected us as BNG, a PADR will be received which triggers the session-activate event. In this event we need a template, either provided during session start with NCP parameters (like unnumbered info), or more specific template info can be provided during this session-activate event. At this time the subscriber interface is created when we transmit the PADS and are now commited for 3 mins to that subscriber session (in IOS, the ncp timeout).
4) 4) The session moves now to the PPP LCP phase and will try to complete the LCP based on the LCP parameters defined in the dynamic-template provided during the session-start event.
5) 5) During LCP we generally negotiate some sort of authentication protocol and when we do, we enter the authentication phase. While the control policy is still in session-activate state we are starting our CHAP or PAP exchange to retrieve user credentials.
6) 6) Even if CHAP/PAP is not negotiated we can still do an authorization request, but probably not on line username/password in the absence of identity retrieval by PPP/Auth. This authen action is defined in the session-start event of the control policy
7) 7) In XR, in the absence of local authentication capabilities, we need to use radius (or tacacs/less common) to initiate the access-request
8) 8) The radius interaction will give us a response, or not when it times out. Either case, an event is triggered in the policy-plane again that we can trigger on to provide further directives or we “can live” with the response radius has given us.
9) 9) Events triggered are authen-failure (access-reject) or authen-no-response (timeout from our radius-server/list). If the response is a success/accept, we are continuing the session and start NCP.
10) 10) IPCP is started and when completed the route is installed.
This document will focus on debugging and understanding each of these components in in-depth level.
PPPoE
This picture above shows the 4 important packets from PPPoE.
The PADI is a broadcast packet, the PADO is a packet with SMAC of the BNG and the DMAC of the subscriber.
The subscriber will send a unicast PADR packet with the DMAC of the BNG it wants to establish a session with, followed by a PADS from the BNG with the pppoe session id.
This session id is unique for the segment and is to be used for EVERY packet that is sent forward from this session.
Note: The BNG will verify the SMAC, arriving access interface and pppoe session ID to prevent spoofing
The session ID is part of the 8 byte pppoe header that is slapped on to the packet (hence the 1492 maximum MTU size when pppoe encap is used.
PPPoE header explained:
MAC header | PPPoE header | Data ::: |
MAC header: This is a standard ethernet II header with ethertype 0x8863 for PPPoE control (PADx messages) and 0x8864 for PPPoE data packets, including PPP/LCP.
PPPoE header:
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Data ::: | |||||||||||||||||||||||||||||||
Version. 4 bits.
Protocol version. Must be set to 1.
Type. 4 bits.
Must be set to 1.
Code. 8 bits.
Session ID. 16 bits, unsigned.
Length. 16 bits.
Size of the Data field in bytes.
Data. Variable length.
Debugging PPPoE
First step in debugging is to evaluate the PPPoE protocol and packets.
Command: Debug pppoe protocol
Provides Basic packet level debugging from a pppoe protocol point of view
RP/0/RSP0/CPU0:Sep 1 15:27:09.632 : pppoe_ma[346]: [PADI-Recv]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
0019.2f43.9a38: this is the subscriber mac-address
RP/0/RSP0/CPU0:Sep 1 15:27:09.632 : pppoe_ma[346]: [PADI-Recv]: vlan-id-outer 100
RP/0/RSP0/CPU0:Sep 1 15:27:09.632 : pppoe_ma[346]: [PADI-Recv]: Service-name:
RP/0/RSP0/CPU0:Sep 1 15:27:09.633 : pppoe_ma[346]: [PADO-Sent]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
RP/0/RSP0/CPU0:Sep 1 15:27:09.633 : pppoe_ma[346]: [PADO-Sent]: vlan-id-outer 100
RP/0/RSP0/CPU0:Sep 1 15:27:09.634 : pppoe_ma[346]: [PADR-Recv]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
RP/0/RSP0/CPU0:Sep 1 15:27:09.634 : pppoe_ma[346]: [PADR-Recv]: vlan-id-outer 100
RP/0/RSP0/CPU0:Sep 1 15:27:09.634 : pppoe_ma[346]: [PADR-Recv]: Service-name:
RP/0/RSP0/CPU0:Sep 1 15:27:09.853 : pppoe_ma[346]: [PADS-Sent]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
RP/0/RSP0/CPU0:Sep 1 15:27:09.853 : pppoe_ma[346]: [PADS-Sent]: vlan-id-outer 100
The format of the debug is:
NODE : Time : <process>[pid] : [PACKET-direction] Interface mac-addr
RP/0/RSP0/CPU0:Sep 1 15:27:09.632 : pppoe_ma[346]: [PADI-Recv]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
In this example the PPPoE session completed perfect, though little information on the packet contents are provided.
Things to look for are:
Is pppoe completing properly to a PADS
Is the interface shown expected
Is the mac address expected
Is the vlan (stack) what we’d expect?
Command: Debug pppoe packet
Provides detailed packet contents from pppoe
PADI
RP/0/RSP0/CPU0:Sep 1 15:37:36.372 : pppoe_ma[346]: Bundle-Ether100.100: I dst ffff.ffff.ffff src 0019.2f43.9a38: len 46 0x1109
0000000401010000000000000000000000000000000000000000000000000000000000000000000000000000
Although the protocol is not provided here because debug pppoe protocol is off, we can tell that this is a PADI because the packet is a broadcast destination on L2 and also the packet starts with 1109 the “09” being the PADI packet
The added 0’s are expected here also because the PADx packets are very small and we need to add padding to them.
The LEN provided (46) is the Ether header length.
The PPPoE length is highlighted in ORANGE
PADO
RP/0/RSP0/CPU0:Sep 1 15:37:36.372 : pppoe_ma[346]: Bundle-Ether100.100: O dst 0019.2f43.9a38 src b4a4.e392.208b: len 21 0x11070000000f010100000102000
741394b2d424e47
PADR
RP/0/RSP0/CPU0:Sep 1 15:37:36.374 : pppoe_ma[346]: Bundle-Ether100.100: I dst b4a4.e392.208b src 0019.2f43.9a38: len 46 0x11190000000f0102000741394b2
d424e470101000000000000000000000000000000000000000000000000000000
PADS
RP/0/RSP0/CPU0:Sep 1 15:37:36.591 : pppoe_ma[346]: Bundle-Ether100.100: O dst 0019.2f43.9a38 src b4a4.e392.208b: len 10 0x11651ed0000401010000
In RED is the assigned pppoe session ID. When the subscriber interface is created that should match this number in decimal, in this case bundle-ether100.100.pppoe7888
Packet type list:
Type Code Direction
PADI 0x09 In only
PADO 0x07 Out only
PADR 0x19 In only
PADS 0x65 Out only
PADT 0xa7 In and Out
Things to look for are:
Are the packet types expected
Are the lengths matching up for the packet to the actual content
Are we expecting the packets in the direction they are meant to be send
Is the mac address expected
Is the vlan (stack) what we’d expect?
Command: debug pppoe session detail
RP/0/RSP0/CPU0:Sep 1 15:51:22.917 : pppoe_ma[346]: Session: Bundle-Ether100.100: Initializing new session
RP/0/RSP0/CPU0:Sep 1 15:51:22.917 : pppoe_ma[346]: Session: Creating and inserting a new session idb on parent interface Bundle-Ether100.100, with se
ssion id 7889
RP/0/RSP0/CPU0:Sep 1 15:51:22.917 : pppoe_ma[346]: Session: Successfully added new session idb to database of parent Bundle-Ether100.100. Parent sess
ion IDB count = 3
RP/0/RSP0/CPU0:Sep 1 15:51:22.918 : pppoe_ma[346]: Session: Queuing interface create on parent interface Bundle-Ether100.100, with session id 7889
LC/0/0/CPU0:Sep 1 15:51:23.038 : pppoe_ea[288]: Interface: 0x0007b920: Creating and inserting a new intf idb
LC/0/1/CPU0:Sep 1 15:51:23.039 : pppoe_ea[288]: Interface: 0x0007b920: Creating and inserting a new intf idb
LC/0/0/CPU0:Sep 1 15:51:23.039 : pppoe_ea[288]: Interface: 0x0007b920: Successfully added new intf idb to database
LC/0/0/CPU0:Sep 1 15:51:23.039 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE received
LC/0/0/CPU0:Sep 1 15:51:23.039 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(1), idb lookups/creates completed successfully
LC/0/1/CPU0:Sep 1 15:51:23.040 : pppoe_ea[288]: Interface: 0x0007b920: Successfully added new intf idb to database
LC/0/1/CPU0:Sep 1 15:51:23.040 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE received
LC/0/1/CPU0:Sep 1 15:51:23.040 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(1), idb lookups/creates completed successfully
LC/0/0/CPU0:Sep 1 15:51:23.044 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(2), Hardware programming completed successfully
LC/0/1/CPU0:Sep 1 15:51:23.045 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(2), Hardware programming completed successfully
LC/0/0/CPU0:Sep 1 15:51:23.045 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(3), IMP interface create completed successfully
LC/0/1/CPU0:Sep 1 15:51:23.046 : pppoe_ea[288]: Interface: 0x0007b920: INTF CREATE(3), IMP interface create completed successfully
RP/0/RSP0/CPU0:Sep 1 15:51:23.050 : pppoe_ma[346]: Session: 0x00000000: Received interface create cb: No error
RP/0/RSP0/CPU0:Sep 1 15:51:23.052 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Inserting a session idb into global database
RP/0/RSP0/CPU0:Sep 1 15:51:23.053 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Successfully added new session idb to global database. Ses
sion IDB count = 3
RP/0/RSP0/CPU0:Sep 1 15:51:23.053 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Received MTU notification, with MTU actual 1500
RP/0/RSP0/CPU0:Sep 1 15:51:23.057 : pppoe_ma[346]: Session: Received AAA batch start notication
RP/0/RSP0/CPU0:Sep 1 15:51:23.057 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Received AAA Session Create cb: No error
RP/0/RSP0/CPU0:Sep 1 15:51:23.058 : pppoe_ma[346]: Session: Received AAA batch end notication
RP/0/RSP0/CPU0:Sep 1 15:51:23.075 : pppoe_ma[346]: Session: Received SubDB batch start notication
RP/0/RSP0/CPU0:Sep 1 15:51:23.075 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Received Activate Config cb: No error
RP/0/RSP0/CPU0:Sep 1 15:51:23.076 : pppoe_ma[346]: Session: Received SubDB batch end notication
RP/0/RSP0/CPU0:Sep 1 15:51:23.159 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Interface ready call succeeded
RP/0/RSP0/CPU0:Sep 1 15:51:23.188 : pppoe_ma[346]: Session: Received AAA batch start notication
RP/0/RSP0/CPU0:Sep 1 15:51:23.188 : pppoe_ma[346]: Session: Bundle-Ether100.100.pppoe7889: Received AAA Session Up Complete cb
RP/0/RSP0/CPU0:Sep 1 15:51:23.189 : pppoe_ma[346]: Session: Received AAA batch end notication
This command is not necessarily that useful for normal troubleshooting, but it does signify the MTU being set on the interface and the session creation from PPPoE internally.
Common things to watch out for:
PPPoE session generally won’t establish for various reasons, here are some gotcha’s that I have ran into many many times
- Service name matching: is the pppoe service name matching what the BBA group is configured for?
- PPPoE throttling
- Control plane policing
- Incorrect vlan (combo)
- Malformed tags
PPP
PPP consists of 3 phases, LCP, Authentication and NCP in order to establish a session allowing the transport of L3 protocols over it.
During LCP initial link parameters are agreed on such as MRU (like MTU), authentication protocol. If an Authentication protocol is agreed on, then we enter the Auth phase in which credentials are exchanged that likely are being handed off to radius for verification.
After that the NCP phase start which allows us to establish an L3 protocol connection such as IPCP for ipv4 or OSICP for CLNS etc. A9K supports only IPCP and soon IPV6CP (with xr430).
During LCP and NCP the exchange of options is done via the following packets. Each of these packets contains options.
CONFIGURE-REQUEST
A packet sent with options that a side of the ppp connection likes to propose
CONFIGURE-ACK
A response to a request indicating that all options in the request are acceptable
CONFIGURE-REJECT
A response to a request indicating that an option can’t be honoured (eg one side does MLP the other side does not, we reject the option
CONFIGURE-NAK
A response to a request indicating that the options in the NAK packet can be fulfilled, but the option value is not desirable. Eg one side proposes CHAP authentication and the other side can only do PAP.
Requests and responses are linked together by a field in the packet called the “ID”.
After the sessions is completed, LCP echo requests, a keepalive mechanism, are exchanged and have to be acknowledged.
Keepalives from the peer are responded by the 9k in hardware. The 9k also originates keepalives which have to be responded by the peer.
Debugging PPP
Some helpful hints explaining the debugs from the component
Command: Debug ppp negotiation
RP/0/RSP0/CPU0:Sep 15 12:43:18.244 : PPP-MA[343]: LCP: Bundle-Ether100.100.pppoe1: [Initial]: Up Event
RP/0/RSP0/CPU0:Sep 15 12:43:18.248 : PPP-MA[343]: LCP: Bundle-Ether100.100.pppoe1: [Initial]: Change to state Closed
In this debug start, the location is RSP0 because PPP for bundle sessions as indicated by the interface are terminated by the RSP. Sessions terminating on a phy interface are terminated on the linecard.
I’ll remove the node and interface moving forward for space issues in the debug.
LCP debug
.244 LCP: [Initial]: Up Event
.248 LCP: [Initial]: Change to state Closed
.249 LCP: [Closed]: Down Event
.250 LCP: [Closed]: Change to state Initial
.250 LCP: [Initial]: Up Event
.251 LCP: [Initial]: Change to state Closed
.358 LCP: [Closed]: Open Event
.358 LCP: [Closed]: Initialize-Restart-Counter
.358 LCP: [Closed]: O CONFREQ id 1 len 19
.359 LCP: [Closed]: MRU 1492 (0x010405d4)
.359 LCP: [Closed]: AuthProto CHAP (0x0305c22305)
.359 LCP: [Closed]: MagicNumber 0x1e7824c4 (0x05061e7824c4)
Identify the protocol state LCP, the LCP state itself in brackets [ ], the direction of the packet O output, I input the packet type (confreq) and the ID. At this point we expect a response from the peer on our ID 1.
.360 LCP: [Closed]: Change to state Req-Sent
.360 LCP: [Req-Sent]: Open Event
.361 LCP: [Req-Sent]: I CONFREQ id 1 len 25
.361 LCP: [Req-Sent]: MRU 1492 (0x010405d4)
.362 LCP: [Req-Sent]: MagicNumber 0x659ff390 (0x0506659ff390)
.362 LCP: [Req-Sent]: MRRU 1524 (0x110405f4)
.362 LCP: [Req-Sent]: EndpointDisc 1 Local (0x13070174657374)
We have move to state request sent, and we are getting an incoming configure request, also with ID 1, we are expected to send a response to ID1 now as well. Note that I deliberately let the client request options for MRRU and EndpointDisc, used for multilink that we don’t support on the 9k.
.363 LCP: Peer's MRRU: Option received on non-MP interface (reject)
.363 LCP: Peer's ED: Option received on non-MP interface (reject)
PPP identifies already the unsupported option
.363 LCP: [Req-Sent]: O CONFREJ id 1 len 15
.364 LCP: [Req-Sent]: MRRU 1524 (0x110405f4)
.364 LCP: [Req-Sent]: EndpointDisc 1 Local (0x13070174657374)
Here we are sending a REJECT on ID1,which is a response to the peers request ID1 in BLUE
We are rejecting the options for MLP. We should expect a new request to come in from the peer with a new offer. Hopefully, the peer is not persistent in its multilink request. If it is, and requests it again, we reject it again. How long that can go on? That will be the ppp max-configure configuration knob, default is 3.
After 3 attempts to configure the link we will terminate the ppp session.
.373 LCP: [Req-Sent]: I CONFACK id 1 len 19
.373 LCP: [Req-Sent]: MRU 1492 (0x010405d4)
.373 LCP: [Req-Sent]: AuthProto CHAP (0x0305c22305)
.374 LCP: [Req-Sent]: MagicNumber 0x1e7824c4 (0x05061e7824c4)
The peer did like out proposal and acknowledged it. If the peer didn’t like our CHAP authentication protocol but can do PAP, it would have sent us a PPP CONFNAK packet with authproto option in there. This would indicate to us to switch auth protocols IF we are configured for that.
If not, and we are persistent on CHAP, we end up in a dead lock also and after default of 3 attempts to configure we drop the session
.374 LCP: [Req-Sent]: Initialize-Restart-Counter
.374 LCP: [Req-Sent]: Change to state Ack-Rcvd
.374 LCP: [Ack-Rcvd]: I CONFREQ id 2 len 14
.374 LCP: [Ack-Rcvd]: MRU 1492 (0x010405d4)
.375 LCP: [Ack-Rcvd]: MagicNumber 0x659ff390 (0x0506659ff390)
We are getting a new proposal in from the peer, it retracted the mlp options, note that the ID has changed to 2. The ID MUST increase on every cycle sent.
.375 LCP: [Ack-Rcvd]: O CONFACK id 2 len 14
.375 LCP: [Ack-Rcvd]: MRU 1492 (0x010405d4)
.375 LCP: [Ack-Rcvd]: MagicNumber 0x659ff390 (0x0506659ff390)
.375 LCP: [Ack-Rcvd]: Change to state Open
That we can honor, so we send an ack on that proposal id2. At this point in time we have sent an ACK and received an ACK.
.376 LCP: [Open]: Report This-Layer-Up
IPCP debug
This handshake is the same as LCP, with the same packet types, just for a different protocol. IPCP instead of LCP.
.397 IPCP: [Initial]: I CONFREQ id 1 len 22
.398 IPCP: [Initial]: Address 0.0.0.0 (0x030600000000)
.398 IPCP: [Initial]: PrimaryDNS 0.0.0.0 (0x810600000000)
.398 IPCP: [Initial]: SecondaryDNS 0.0.0.0 (0x830600000000)
.398 IPCP: [Initial]: Conf-Req packet stalled
.400 IPCP: [Initial]: Open Event
.400 IPCP: [Initial]: Change to state Starting
.402 IPCP: [Starting]: Report This-Layer-Started
.402 IPCP: [Starting]: Up Event
.402 IPCP: [Starting]: Initialize-Restart-Counter
.403 IPCP: [Starting]: O CONFREQ id 1 len 10
.403 IPCP: [Starting]: Address 101.101.1.1 (0x030665650101)
Our address is the interface we are unnumbered to from the session, derived from the dynamic template or radius.
.404 IPCP: [Starting]: Change to state Req-Sent
.404 IPCP: [Req-Sent]: Restarting stalled Conf-Req packet
.405 IPCP: [Req-Sent]: I CONFREQ id 1 len 22
.405 IPCP: [Req-Sent]: Address 0.0.0.0 (0x030600000000)
.405 IPCP: [Req-Sent]: PrimaryDNS 0.0.0.0 (0x810600000000)
.405 IPCP: [Req-Sent]: SecondaryDNS 0.0.0.0 (0x830600000000)
.406 IPCP: [Req-Sent]: I CONFACK id 1 len 10
.406 IPCP: [Req-Sent]: Address 101.101.1.1 (0x030665650101)
.406 IPCP: [Req-Sent]: Initialize-Restart-Counter
.406 IPCP: [Req-Sent]: Change to state Ack-Rcvd
.408 IPCP: Peer's Primary DNS address: 0.0.0.0 (reject)
.408 IPCP: Peer's Secondary DNS address: 0.0.0.0 (reject)
.408 IPCP: [Ack-Rcvd]: O CONFREJ id 1 len 16
.408 IPCP: [Ack-Rcvd]: PrimaryDNS 0.0.0.0 (0x810600000000)
.408 IPCP: [Ack-Rcvd]: SecondaryDNS 0.0.0.0 (0x830600000000)
Client requested dns servers and we don’t have any info for them.
.409 IPCP: [Ack-Rcvd]: I CONFREQ id 2 len 10
.409 IPCP: [Ack-Rcvd]: Address 0.0.0.0 (0x030600000000)
Client requests an ip address
.410 IPCP: [Ack-Rcvd]: O CONFNAK id 2 len 10
.410 IPCP: [Ack-Rcvd]: Address 199.1.1.1 (0x0306c7010101)
We provide a pool address.
The client can also request a real address, but that if we ack that be a semi static ip address, so many providers prefer to renegotiate the address and send a nak always on the address option and provide a new pool address.
.411 IPCP: [Ack-Rcvd]: I CONFREQ id 3 len 10
.411 IPCP: [Ack-Rcvd]: Address 199.1.1.1 (0x0306c7010101)
.411 IPCP: [Ack-Rcvd]: O CONFACK id 3 len 10
.411 IPCP: [Ack-Rcvd]: Address 199.1.1.1 (0x0306c7010101)
.411 IPCP: [Ack-Rcvd]: Change to state Open
.412 IPCP: [Open]: Report This-Layer-Up
LCP echos debug
RP/0/RSP0/CPU0:Sep 15 12:43:19.405 LCP: [Open]: I ECHOREQ id 1 len 12 magic 0x659ff390
RP/0/RSP0/CPU0:Sep 15 12:43:19.405 LCP: [Open]: O ECHOREP id 1 len 12 magic 0x1e7824c4
Incoming echo requests and replies, note that the ID is incrementing every time.
Also note the magic numbers in this packet which are the Magics negotiated during LCP.
A9K does NOT do magic number validation.
RP/0/RSP0/CPU0:Sep 15 12:43:29.646 LCP: [Open]: I ECHOREQ id 2 len 12 magic 0x659ff390
RP/0/RSP0/CPU0:Sep 15 12:43:29.646 LCP: [Open]: O ECHOREP id 2 len 12 magic 0x1e7824c4
Note: I requested the lcp echo debug to be moved over to a different debug command. At the time of writing this article it is part of the debug ppp negotiation
AAA
When the control policy determines that user authentication is in order, an access-request with several attributes is sent to the RADIUS server.
The radius server can check these attributes and reply back with either an ACCESS-ACCEPT or an ACCESS-REJECT.
The Reject can have a reply message stating the reason for reject, but that is optional.
An ACCEPT can come with reply attributes that will instruct the BNG to apply features or session parameters on the session
Debugging AAA
Some helpful hints explaining the debugs from the component
Command: Debug radius
Command: Debug aaa authentication/authorization/accounting
Common things to watch out for:
Some things that can go wrong with RADIUS are:
- When the secret key is misconfigured, the authenticator of the radius header will be wrong. Some radius-servers reply then always with a reject, some radius-servers will silently discard the message.
- Radius packets are sent with an 8 bit ID, which is not enough for large scale, we extend that with the source port, is show radius showing bad authenticators? Likely you have ID overload. Make sure your radius server supports extended source ports
- Are the reply items properly set for based on the session type? For instance IP sessions do not come up when the service-type is set to framed or outbound.
- When a feature is attempted to be applied, such as an ACL that doesn’t exist, should we reject the session or keep it alive unrestricted.
NOTE: The radius-profile for an IPoE session should NOT include any service-type. Having Framed-User as service type in an access accept for an IP subscriber will cause the session to fail.
PPP/PPPoE Control Policy Events
The format of the debug is:
NODE : Time : <process>[pid] : [PACKET-direction] Interface mac-addr
RP/0/RSP0/CPU0:Sep 1 15:27:09.632 : pppoe_ma[346]: [PADI-Recv]: Bundle-Ether100.100 peer-mac 0019.2f43.9a38
