Never got this figured out and we actually disabled PfR altogether. The TAC resources were less than helpful in our case.
Just seems like nobody knows anything about PfR at TAC and just ended up blaming another team or feature, like DMVPN, for the problems.
Having the connections bounce back and forth made performance worse than just using CoS policies with single, but redundant paths. So we opted for the latter.
... View more
Can someone explain to me how I can have byte loss that is crossing a PfR policy threshold (causing a TCA), but zero packet loss? I tried to search for documentation, but just found 1000 configuration guides instead.
When defining a custom policy or using a built-in template, packet loss and byte loss share the same threshold (defined by the "loss" keyword). So I can't modify just one side of the "loss" thresholds. Kind of stupid, but it is what it is. Is it possible to shut off the byte loss rate portion?
Output from "sh domain default master channels summary"
Channel Id: 47520 Dst Site-Id: 10.x.x.72 Link Name: mpls DSCP: af21  pfr-label: 0:0 | 0:1 [0x1] TCs: 0 BackupTCs: 5 Channel Created: 20:30:52 ago Provisional State: Initiated and open Operational state: Available Channel to hub: FALSE Interface Id: 14 Supports Zero-SLA: Yes Muted by Zero-SLA: No Estimated Channel Egress Bandwidth: 0 Kbps Immitigable Events Summary: Total Performance Count: 0, Total BW Count: 0 ODE Statistics: Received: 3 ODE Stats Bucket Number: 1 Last Updated : 00:18:52 ago Packet Count : 498 Byte Count : 64717 One Way Delay : 52 msec* Loss Rate Pkts: 0.0 % Loss Rate Byte: 66.27 % Jitter Mean : 193 usec Unreachable : FALSE ODE Stats Bucket Number: 2 Last Updated : 00:19:22 ago Packet Count : 575 Byte Count : 203188 One Way Delay : 52 msec* Loss Rate Pkts: 0.0 % Loss Rate Byte: 89.49 % Jitter Mean : 194 usec Unreachable : FALSE TCA Statistics: Received: 4 ; Processed: 2 ; Unreach_rcvd: 0 ; Local Unreach_rcvd: 0 TCA lost byte rate: 4 TCA lost packet rate: 0 TCA one-way-delay: 0 TCA network-delay: 0 TCA jitter mean: 0 Latest TCA Bucket Last Updated : 00:18:52 ago One Way Delay : NA Loss Rate Pkts: NA Loss Rate Byte: 66.27 % Jitter Mean : NA Unreachability: FALSE
... View more
Let me preface by saying I'm not an expert. The post-8.3 (on 9.1) code is definitely brand new to me. Right now, we have an ASA 5510 on 9.1 that is an RA VPN termination device using AnyConnect. Pre-8.3, I thought I had to explicitly create no-nat statements for every network the RA VPN DHCP network would connect with on the "inside" interface. Per my configuration below, I have one class B object defined (EDPR-Site, 10.60.0.0/16) in what I believe is the correct way to NAT exempt from the AnyConnect-Network. This source/destination works as expected. The weird thing is, when I'm connected to the AnyConnect I have no problems accessing ANY "inside" networks (192.168.x.x, other 10.x.x.x/16, etc.)! Can somebody tell my why every network "works" in this case and I don't run into NAT translation or exemption problems? same-security-traffic permit inter-interface same-security-traffic permit intra-interface object network AnyConnect-Network subnet 10.60.32.0 255.255.254.0 object network EDPR-Site subnet 10.60.0.0 255.255.0.0 nat (inside,outside) source static EDPR-Site EDPR-Site destination static AnyConnect-Network AnyConnect-Network ! object network AnyConnect-Network nat (outside,outside) dynamic interface object network EDPR-Site nat (inside,outside) dynamic interface sh nat output: Manual NAT Policies (Section 1) 1 (inside) to (outside) source static EDPR-Site EDPR-Site destination static AnyConnect-Network AnyConnect-Network translate_hits = 6545, untranslate_hits = 6948 Auto NAT Policies (Section 2) 1 (outside) to (outside) source dynamic AnyConnect-Network interface translate_hits = 3169, untranslate_hits = 1362 2 (inside) to (outside) source dynamic EDPR-Site interface translate_hits = 0, untranslate_hits = 0
... View more
Hello, Currently, my company has the need to support a legacy PSK authenticated DMVPN tunnel and a new PKI authenticated DMVPN tunnel. Ideally, both tunnels will terminate on the same Cisco 2951 router. Since the router is a termination point for the VPN spokes, I would need 2 "default routes". The source IP addresses of the spokes will be dynamic (personal grade ISP connections). Both interfaces (and underlying tunnel interfaces) work when I switch the default route from one conncted interface, to the other. Is it possible to use PBR to force traffic that entered on one interface to exit only on that same interface? ======================================================================================= Example: All spoke configs have ISAKMP/IPSec settings to terminate PSK tunnel on 220.127.116.11 and terminate PKI tunnel on 18.104.22.168 22.214.171.124 - NAT'd to 172.25.0.25 by ASA 126.96.36.199 - NAT'd to 172.25.25.20 by ASA interface Port-channel1.172 description ** PSK Interface ** encapsulation dot1Q 172 ip address 172.25.0.25 255.255.255.0 interface Port-channel1.225 description ** PKI Interface ** encapsulation dot1Q 225 ip address 172.25.25.20 255.255.255.0 Below, only one route is entered at a time. Interface and underlying tunnel work depending on which default route is added. ip route 0.0.0.0 0.0.0.0 172.25.0.1 <==== When configured, only the PSK interface accepts VPN tunnel connections (ip route 0.0.0.0 0.0.0.0 172.25.25.1) <==== When configured, only the PKI interface accepts VPN tunnel connections ========================================================================================= - Ideally, all traffic that ingressed on Po1.172 and was destined for an unknown IP (0.0.0.0 0.0.0.0) would forcefully have it's next hop set to 172.25.0.1 - Then, all traffic that ingressed on Po1.225 and was destined for an unknown IP would forcefully have it's next hop set to 172.25.25.1 Is this possible with PBR?
... View more