In the IPv4 world you could very easily do the following on a BRAS/BNG, find the subscriber's IPv4 address and ping it.
bbras#sh users | i test Vi4 test PPPoVPDN 00:01:42 10.11.12.13 bbras#p 10.11.12.13 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.11.12.13, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/24 ms
Although ping wouldn't always work, in many cases (especially under a managed CPE environment), ping was an easy way to verify subscriber's connectivity, something that is useful for the call-center or 1st level support. Besides checking basic connectivity, using just a single command (as the one shown above, or the ones shown below) you could easily (or with a little bit of text searching) find the IPv4 address of a subscriber.
bbras#sh caller user test User: test, line Vi4, service PPPoVPDN Connected for 1d05h, Idle for 00:01:54 Timeouts: Limit Remaining Timer Type 01:00:00 00:58:05 PPP idle PPP: LCP Open, multilink Closed, PAP (<-), IPCP, IPV6CP IP: Local 10.10.10.10, remote 10.11.12.13 Access list (I/O) is 120/not set Counts: 27378 packets input, 534558 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 13703 packets output, 280432 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets
bbras#sh ip int virtual-access 4 Virtual-Access4 is up, line protocol is up Interface is unnumbered. Using address of Loopback0 (10.10.10.10) Broadcast address is 255.255.255.255 Peer address is 10.11.12.13
bbras#sh ppp int virtual-Access 4 PPP Serial Context Info ------------------- Interface : Vi4 PPP Serial Handle: 0x0 PPP Handle : 0x0 SSS Handle : 0x0 AAA ID : 0 Access IE : 0x0 SHDB Handle : 0x0 State : Down Last State : Init Last Event : None PPP Session Info ---------------- Interface : Vi4 PPP ID : 0xC600001D Phase : UP Stage : Local Termination Peer Name : test Peer Address : 10.11.12.13 Control Protocols: LCP[Open] PAP+ IPCP[Open] Session ID : 29 AAA Unique ID : 59 SSS Manager ID : 0x3B SIP ID : 0x4F00003A PPP_IN_USE : 0x11 Vi4 LCP: [Open] Our Negotiated Options Vi4 LCP: AuthProto PAP (0x0304C023) Vi4 LCP: MagicNumber 0x547CCD04 (0x0506547CCD04) Vi4 LCP: EndpointDisc 1 bbras Vi4 LCP: (0x13130162627261732D6C6C752D6B6C6E) Vi4 LCP: (0x2D3331) Our Rejected options MRRU Peer's Negotiated Options Vi4 LCP: MagicNumber 0x3DB09C3A (0x05063DB09C3A) Vi4 IPCP: [Open] Our Negotiated Options Vi4 IPCP: Address 10.10.10.10 (0x0306C2DBE763) Peer's Negotiated Options Vi4 IPCP: Address 10.11.12.13 (0x0306C2DB711D) Vi4 IPCP: PrimaryDNS 10.1.1.1 (0x8106C15C9603) Vi4 IPCP: SecondaryDNS 10.2.2.2 (0x8306C15C030B)
Now, in the IPv6 world, you can have quite a few of IPv6 "addresses" on the CPE (link-local address, SLAAC/DHCPv6 prefix/addresses for the WAN, DHCPv6-PD prefix/addresses for the LAN) and very limited info on the BRAS/BNG, that actually there is no easy way to do something similar.
First of all, there isn't any "show ipv6 users" command. And if there was one, which IPv6 address should it display there?
Secondly, although in 99% of the cases you can set the Framed-Interface-Id per user, this doesn't mean it will be honored. The problem with Framed-Interface-Id is that it is used as a hint to the peer, so you cannot always depend on your own being used at the end. Btw, Broadband Forum TR-187 R-32 proposes to have the BRAS/BNG decline the tentative Interface-Id received from CPE in case a Framed-Interface-Id from Radius is being used.
In any case, a manual concatenation of the prefix + Id would produce the asked IPv6 addresses.
So if you want to find the IPv6 address of a subscriber, you have to do some of the following steps:
bbras#sh ipv6 int virtual-access 4 Virtual-Access4 is up, line protocol is up IPv6 is enabled, link-local address is FE80::EE44:76FF:FEC8:5C1B No Virtual link-local address(es): Interface is unnumbered. Using address of Loopback0 No global unicast address is configured
Note: peer IPv6 address is not included as probably expected in the "show ipv6 int" output. The one shown above, is the link-local IPv6 address on the BRAS/BNG side.
Adding the "prefix" keyword at the end of the previous command, reveals the Framed-IPv6-Prefix being used on this interface:
bbras#sh ipv6 int virtual-access 4 prefix IPv6 Prefix Advertisements Virtual-Access4 Codes: A - Address, P - Prefix-Advertisement, O - Pool U - Per-user prefix, D - Default N - Not advertised, C - Calendar PD default [LA] Valid lifetime 2592000, preferred lifetime 604800 OD 2999:2148:100:300::/64 [LA] Valid lifetime 2592000, preferred lifetime 604800
Under PPP you can find IPv6CP and the corresponding Framed-Interface-Id:
bbras#sh ppp int virtual-Access 4 | b IPV6CP: Vi4 IPV6CP: [Open] Our Negotiated Options Vi4 IPV6CP: Interface-Id EE44:76FF:FEC8:5C1B (0x010AEE4476FFFEC85C1B) Peer's Negotiated Options Vi4 IPV6CP: Interface-Id 3131:3131:3A31:3131 (0x010A313131313A313131)
So, now you have the following info:
Link Local prefix: FE80::/10
Based on these strings, you can create the following IPv6 addresses:
Peer global address: 2999:2148:100:300:3131:3131:3A31:3131
Peer link-local address: FE80::3131:3131:3A31:3131
And you can verify connectivity to them accordingly:
bbras#p 2999:2148:100:300:3131:3131:3A31:3131 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2999:2148:100:300:3131:3131:3A31:3131, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms
bbras#p FE80::3131:3131:3A31:3131%Virtual-Access4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::3131:3131:3A31:3131, timeout is 2 seconds: Packet sent with a source address of FE80::EE44:76FF:FEC8:5C1B%Virtual-Access4 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
Many thanks to Ole Troan for sharing the "%interface" trick with me ("%interface" is usually used to define the zone index on UNIX systems). I hope our talk about an IPv6 output similar to "show users" will have a positive end inside IOS code.