This article explains about one of the troubleshooting scenario where the subscriber is not coming online.
We might notice some subscribers are not coming up on BNG.
The subscriber which is not coming UP could be from any specific vendor.
Same subscriber will come online if they try to login from a different CPE.
You will see the Interaction between CPE & BNG stops at PADR.
<client-mac> > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq UTF8] [Vendor-Specific UTF8]
<BNG-mac> > <client-mac>, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 6, ethertype PPPoE D, PPPoE PADO [AC-Name "<AC-NAME>"] [Host-Uniq UTF8] [Service-Name "<service-name>"] [Service-Name] [AC-Cookie UTF8]
<client-mac> > <BNG-mac>, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 0, ethertype PPPoE D, PPPoE PADR [AC-Name "<AC-NAME>"] [Host-Uniq UTF8] [Service-Name "<service-name>"] [Service-Name] [AC-Cookie UTF8] [Vendor-Specific UTF8]
Above messages captured at the incoming interface of BNG where the subscriber hits. We could see that the client send the PADR 6 times and restarts the login process.
We don’t see any error logs in trace files, We could only see a message that the PAD have multiple serviceName tags.
Discovery Input: PADR packet UIFL:demux0.3221332670 (110747)
processPADR: Multiple ServiceName Tags
We could see the last messages logged on the PADR is saying that the packet has multiple service-name tags.
If you check the RFC you could see that CP is sending PADO not following the RFC.
The PPPoE Active Discovery Initiation (PADI) packet
The Host sends the PADI packet with the DESTINATION_ADDR set to the broadcast address. The CODE field is set to 0x09 and the SESSION_ID MUST be set to 0x0000.
The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types. An entire PADI packet (including the PPPoE header) MUST NOT exceed 1484 octets so as to leave sufficient room for a relay agent to add a Relay-Session-Id TAG.
Here is the initial PADI message from CPE to BNG.
<client-mac>> ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq UTF8] [Vendor-Specific UTF8]
Here CPE sends the PADI with an empty Service-name tag
BNG responds to the PADI message with the PADO message by adding a Service name “<service-name>”
<BNG-mac> > <client-mac>, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 6, ethertype PPPoE D, PPPoE PADO [AC-Name "<AC-name>"] [Host-Uniq UTF8] [Service-Name "<service-name>"] [Service-Name] [AC-Cookie UTF8]
As per RFC The PADO packet MUST contain one AC-Name TAG containing the Access Concentrator's name, a Service-Name TAG identical to the one in the PADI, and any number of other Service-Name TAGs indicating other services that the Access Concentrator offers
Here MX BNG is following RFC as it is sending the PADO with the same service-name tag and added service-name tag “<service-name>”
Then the CPE send the PADR messages to MX with two Service name tags.
<client-mac>> <BNG-mac>, ethertype 802.1Q (0x8100), length 4294967292: vlan 2088, p 0, ethertype PPPoE D, PPPoE PADR [AC-Name "<AC-name>"] [Host-Uniq UTF8] [Service-Name "<service-name>"] [Service-Name] [AC-Cookie UTF8] [Vendor-Specific UTF8]
This is against RFC, The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types.
CPE is sending multiple Service-name tags in PADR which is causing the BNG to drop the PADR and not processing further.
This need to be fixed further from CPE side.
Please refer the RFC2516 for more details.