ISR4451 Session creation failed virtual-access

[katrin1701]

I'm trying to get a Virtual Interface running on an ISR4451

vi3 is being created, but no data seems to be sent to that interface.

I assume this log message is the reason.

: %FMANRP_ESS-4-FULLVAI: Session creation failed due to Full Virtual-Access Interfaces not being supported. Check that all applied Virtual-Template and RADIUS features support Virtual-Access sub-interfaces. swidb= 0x80007F082B7E3868, ifnum= 17

So I found I can test the sub-interface creation:

test virtual-Template 1 subinterface
Subinterfaces may be created using Virtual-Template1

So my template doesn't seem to cause the problem.

Radius attributes we're using are

 Framed-IP-Address | := | 10.130.1.67 |
Framed-MTU | := | 1300 |
Service-Type | := | 2 |
 Framed-Protocol | := | 1 |
Filter-ID | := | 130 |

They are working on a different platform.

Does ISR4451 maybe not support Full Virtual-Access?

[MHM Cisco World · Accepted solution]

Framed-Compression = Van-Jacobson-TCP-IP <<- this return from Radius is different than what ISR4K use

[katrin1701]

But what does that mean for me? What do I have to change?

I removed default compression from my radius config

DEFAULT Framed-Protocol == PPP
# Framed-Protocol = PPP,
# Framed-Compression = Van-Jacobson-TCP-IP

The log message is gone, the interface used is now vi2.1 instead of vi3 and I still can't reach 10.130.1.67

[MHM Cisco World]

the log is remove. <<- this solved 
there are two virtual-template ? Vi2 and Vi3 ??

[katrin1701]

We are replacing a C3900 and that has nearly the same configuration. I thought when I got the vi up everything would be fine.

There every ppp gets its own interface vixxx, in the end there will be quite a lot of those.

The Radius assigns the filter ID and that access-lists gets hits.

So I expected vi3 is assigned 10.130.1.67 (which it is) and then I can ping 10.130.1.67, or at least I'd get a hit in the access-list 130 (which I don't).

Next connection would get e.g. vi4, address 10.130.1.68 and maybe access-list 131.

[katrin1701]

I've also found this out:

I can receive date from the virtual interface, but replies don't go back.

i.e. 10.130.1.67 can ping something and replies go back to the Cisco, but not out through the vi-interface.

[MHM Cisco World]

I have seen this issue before 
are you config NAT ?
can I see the show ip route ?

[katrin1701]

Here is the route:

#show ip route 10.130.1.67
Routing entry for 10.130.1.67/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via bgp 65146
Advertised by bgp 65146
Routing Descriptor Blocks:
* directly connected, via Virtual-Access2.1
Route metric is 0, traffic share count is 1

The Virtual Template does have a nat outside, but I removed that as test, no change. And even if that nat did something I would still have assumed that the access-list 130 would have gotten a hit.

Extended IP access list 130
10 permit icmp any any .... (no hits)

interface Virtual-Template1
mtu 1300
ip unnumbered Loopback1
ip nat outside
no logging event link-status
peer match aaa-pools
no peer default ip address
ppp mtu adaptive
ppp authentication pap callin
ppp authorization VPDN
ip virtual-reassembly

#show interfaces vi2.1
Virtual-Access2.1 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of Loopback1 (10.130.0.4)
MTU 1300 bytes, BW 28301 Kbit/sec, DLY 100000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP
PPPoVPDN vaccess, cloned from Virtual-Template1
Vaccess status 0x0
Protocol l2tp, tunnel id 50748, session id 14885
Keepalive set (10 sec)
393 packets input, 15836 bytes
246 packets output, 3956 bytes
Last clearing of "show interface" counters never

According to counters bytes go both in and out...

[MHM Cisco World]

Yes I see, let me check note I have

[MHM Cisco World]

two steps here I think you need 
1-ip unnumbered Loopback1
ip nat outside

2- remove ip nat outisde from the Virtual-template  


do these two steps and check again 

[katrin1701]

Did that, but no success... still no reply when I try to ping 10.130.1.67.
While it says outgoing access-list is 130 for ip interface vi2.1
I don't get any hit at all in access-list 130, even though it ends in deny any any log

I've read somewhere about IOS XE16
Per-user Access Control Lists (ACLs) applied through the RADIUS server are not supported.

Is this a per-user ACL? I'm not sure if my VI counts as that kind of user.

[katrin1701]

This has been found out:
#show platform packet-trace summary
Pkt Input Output State Reason
0 INJ.2 Gi0/0/1 FWD
1 Gi0/0/1 EV14 DROP 109 (EssUnsupPktType)
2 INJ.2 Gi0/0/1 FWD
3 Gi0/0/1 EV14 DROP 109 (EssUnsupPktType)

s01bg_71546p001#show platform packet-trace packet 3
Packet: 3 CBUG ID: 30
Summary
Input : GigabitEthernet0/0/1
Output : EVSI14
State : DROP 109 (EssUnsupPktType)
Timestamp
Start : 3707267685575597 ns (02/21/2023 12:25:05.724501 UTC)
Stop : 3707267685582851 ns (02/21/2023 12:25:05.724508 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet0/0/1
Output :
Source : 10.0.0.250
Destination : 10.130.1.67
Protocol : 1 (ICMP)

debug platform condition stop
no debug all





Output should be vi2.1

The packet in question is a normal ICMP reply.

[marce1000]

               - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh71668

 M.

[Georg Pauwen]

Hello,

I have not followed the entire thread, so maybe I am missing something, but can you post the full RADIUS config including the 'Cisco AVPair' parameters ?

[katrin1701]

| 509089 | irgendwas@alec.testd | Framed-IP-Address | := | 10.130.1.67 |
| 509090 | irgendwas@alec.testd | Framed-MTU | := | 1492 |
| 509091 | irgendwas@alec.testd | Service-Type | := | 2 |
| 509092 | irgendwas@alec.testd | Framed-Protocol | := | 1 |
| 509093 | irgendwas@alec.testd | Reply-Message | := | Willkommen |
| 509101 | irgendwas@alec.testd | Filter-ID | := | 130
It used to ask for VJ-Compression per default, but I have removed that already.


Interface User Mode Idle Peer Address
Vi2.1 xxxxxxxx PPPoVPDN - 10.130.1.67
I can see data coming from 10.130.1.67 and I can see the reply on the Cisco on GE0/0/1, but I assume it is not going out Vi2.1
It won't use access-list 130 either.

It used to be vi3 before I changed the setting of the Virtual-Template to no logging event link-status.
Don't know if that is important, but with logging event link-status I couldn't create a subinterface.

This is the radius debug:
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 41
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 35 "actual-data-rate-upstream=5824000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 44
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 38 "actual-data-rate-downstream=29176000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 41
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 35 "minimum-data-rate-upstream=768000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 44
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 38 "minimum-data-rate-downstream=1152000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 46
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 40 "attainable-data-rate-upstream=17017000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 48
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 42 "attainable-data-rate-downstream=41271000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 42
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 36 "maximum-data-rate-upstream=5824000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 45
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 39 "maximum-data-rate-downstream=29184000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 50
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 44 "minimum-data-rate-upstream-low-power=32000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 52
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 46 "minimum-data-rate-downstream-low-power=32000"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 46
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 40 "maximum-interleaving-delay-upstream=12"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 48
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 42 "maximum-interleaving-delay-downstream=12"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 18
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 12 "dsl-type=5"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 37
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 31 "access-loop-encapsulation=120"
Feb 15 2023 13:26:50: RADIUS: Framed-Protocol [7] 6 PPP [1]
Feb 15 2023 13:26:50: RADIUS: Framed-IP-Address [8] 6 10.130.1.67
Feb 15 2023 13:26:50: RADIUS: User-Name [1] 22 "xxxxxxxxxxxxxxxx"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 35
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 29 "connect-progress=LAN Ses Up"
Feb 15 2023 13:26:50: RADIUS: Acct-Authentic [45] 6 RADIUS [1]
Feb 15 2023 13:26:50: RADIUS: Acct-Status-Type [40] 6 Start [1]
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 52
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 46 "circuit-id-tag=x.x.x.x/0.0.0.0 eth 1/21"
Feb 15 2023 13:26:50: RADIUS: Vendor, Cisco [26] 36
Feb 15 2023 13:26:50: RADIUS: Cisco AVpair [1] 30 "remote-id-tag=XXX.XXX.XXX"
Feb 15 2023 13:26:50: RADIUS: Connect-Info [77] 18 "28301000/5649000"
Feb 15 2023 13:26:50: RADIUS: NAS-Port-Type [61] 6 ISDN [2]
Feb 15 2023 13:26:50: RADIUS: NAS-Port [5] 6 20037
Feb 15 2023 13:26:50: RADIUS: NAS-Port-Id [87] 16 "Uniq-Sess-ID37"
Feb 15 2023 13:26:50: RADIUS: Service-Type [6] 6 Framed [2]
Feb 15 2023 13:26:50: RADIUS: NAS-IP-Address [4] 6 10.0.137.5
Feb 15 2023 13:26:50: RADIUS: Acct-Delay-Time [41] 6 0


#show interfaces vi2.1
Virtual-Access2.1 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of Loopback1 (10.130.0.3)
MTU 1300 bytes, BW 28301 Kbit/sec, DLY 100000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP
PPPoVPDN vaccess, cloned from Virtual-Template1
Vaccess status 0x0
Protocol l2tp, tunnel id 26053, session id 26751
Keepalive set (10 sec)
65 packets input, 2572 bytes
44 packets output, 724 bytes
Last clearing of "show interface" counters never


#show ip interface vi2.1
Virtual-Access2.1 is up, line protocol is up
Interface is unnumbered. Using address of Loopback1 (10.130.0.3)
Broadcast address is 255.255.255.255
Peer address is 10.130.1.67
MTU is 1300 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing Common access list is not set
Outgoing access list is 130
Inbound Common access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
Associated unicast routing topologies:
Topology "base", operation state is UP
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is enabled, interface in domain outside
BGP Policy Mapping is disabled
Input features: Virtual Fragment Reassembly, NAT Outside, iEdge, MCI Check
Output features: iEdge, Post-routing NAT Outside
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled