08-20-2012 01:02 PM - edited 03-04-2019 05:19 PM
I have a Cisco Live PfR Lab Book from 2009 that describes the use of an ACL in a PFR Map to define the Networks in the MTC. The format in the lab is :
ip access-list ext matchEF
permit ip any 100.1.1.0 0.0.0.255 dscp ef (these match the destination prefix being managed or monitored)
permit ip any 100.1.2.0 0.0.0.255 dscp ef
permit ip any 100.1.2.0 0.0.0.255 dscp ef
In my lab, this does not work
ip access-list ext Voice
permit ip any 10.223.9.0 0.0.0.255 dscp ef (phones vlan in my lab network)
But this does work
ip access-list ext Voice
permit ip any any dscp ef
(but it also pick up and manages the Probes coming from the remote end and forces both probes over the same WAN connection)
ATRLAB-CC1WR1#sh pfr master tr
OER Prefix Statistics:
Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),
P - Percentage below threshold, Jit - Jitter (ms),
MOS - Mean Opinion Score
Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),
E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable
U - unknown, * - uncontrolled, + - control more specific, @ - active probe all
# - Prefix monitor mode is Special, & - Blackholed Prefix
% - Force Next-Hop, ^ - Prefix is denied
DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos ActLLos
--------------------------------------------------------------------------------
10.223.9.0/24 N ef 256 N N 0.0.0.0/0
INPOLICY @54 10.223.31.2 Fa1/0 PBR
U U 0 0 0 0 0 65
12 12 0 0 1 0 5333 0
10.223.254.0/30 N ef 256 N N 0.0.0.0/0 (this is a probe from the remote WAN router)
DEFAULT* @3 10.223.31.2 U U
10.223.255.0/30 N ef 256 N N 0.0.0.0/0 (this is a probe from the remote WAN router)
DEFAULT* @3 10.223.31.2 U U
ATRLAB-CC1WR1#
any thoughts on why the more specific list does not work?
Thanks
08-21-2012 04:33 AM
Hi There,
if you have a couple of hours you will find the exact answer here:
Alessio
08-21-2012 10:44 AM
Alessio
I have watched these video's, actually watched them before I started developing a PFR solution for my network. This is not the solution to my problem. I am running 15.1 code in one scenario and 15.2 in another. The ACL no longer has to match the specific route. In my case, from above, I have learned 10.223.9.0. That route does not exist in the routing table. The routing table has 10.223.0.0/20 and the ACL is using IP any any. So in my case pfr works when the acl entry does not match the network and does not work when I do match the network. BTW, PFR conditions are met in both configurations.
Thanks anyway!
Mark
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide