Configuring Intermediate PfR Feature

Hello everyone, time is just passing so fast, and i couldn't believe its already in the middle of July. We are going to meet the Ramadhan, where everybody will have fasting in that month.

today I will write about the topic that is getting hotter nowadays, especially for you who is studying for the R/S Lab, that is the PfR. Last year I've blogged this technology, using the static route as the prefix aggregation using 12.4T train. Today we will get a little deeper with this, Interesting, PfR technology.

Before I continue, let see the topology here:

Hei, wait a minute, these topology looks familiar#!? Yes, indeed, I took the topology from the vSeminar which was held by the INE, and I did a little modification which were including add the 2 Computers (Client and servers) and also change the IOS for all the routers using 15.1M train. Why I changed the IOS, because the PfR is getting better in IOS 15.X.

The Major Network Using 173.1.x.y/24 & 150.1.y.y/32 for the loopbback

these are the scenario:

• ·         Configuring PfR Using aggregation-type BGP
• ·         Try when the PfR doesn't have a parent route, and see it
• ·         Try using 'traffic-class filter' to filter Only TCP traffic that PfR Will take care of it, any other traffic will not be notified by the PfR

Answer and Verification

·         1 - Configuring PfR Using aggregation-type BGP

R2 ! pfr master  port 29281  logging  !  border 150.1.2.2 key-chain KC_PFR   interface FastEthernet0/0 internal   interface Serial1/0.23 external   interface Serial1/0.12 external  !  learn   throughput   periodic-interval 0   monitor-period 1   prefixes 100 applications 0   aggregation-type bgp  backoff 90 90  mode route control  no resolve delay  no resolve range ! pfr border  logging  local Loopback0  port 29281  master 150.1.2.2 key-chain KC_PFR !

Verification

Rack01R2#show pfr border OER BR 150.1.2.2 ACTIVE, MC 150.1.2.2 UP/DOWN: UP 00:02:35,   Auth Failures: 0   Conn Status: SUCCESS   OER Netflow Status: ENABLED, PORT: 29281   Version: 3.0  MC Version: 3.0   Exits   Fa0/0           INTERNAL   Se1/0.12        EXTERNAL   Se1/0.23        EXTERNAL

Rack01R2#show pfr master OER state: ENABLED and ACTIVE   Conn Status: SUCCESS, PORT: 29281   Version: 3.0   Number of Border routers: 1   Number of Exits: 2   Number of monitored prefixes: 0 (max 5000)   Max prefixes: total 5000 learn 2500   Prefix count: total 0, learn 0, cfg 0   PBR Requirements met   Nbar Status: Inactive Border           Status   UP/DOWN             AuthFail  Version 150.1.2.2        ACTIVE   UP       00:02:40          0  3.0 Global Settings:   max-range-utilization percent 20 recv 0   mode route metric bgp local-pref 5000   mode route metric static tag 5000   trace probe delay 1000   logging   exit holddown time 60 secs, time remaining 0 Default Policy Settings:   backoff 90 90 90   delay relative 50   holddown 300   periodic 0   probe frequency 56   number of jitter probe packets 100   mode route control   mode monitor both   mode select-exit good   loss relative 10   jitter threshold 20   mos threshold 3.60 percent 30   unreachable relative 50   resolve utilization priority 13 variance 20 Learn Settings:   current state : STARTED   time remaining in current state : 86 seconds   throughput   no delay   no inside bgp   monitor-period 1   periodic-interval 0   aggregation-type bgp   prefixes 100 appls 0   expire after time 720

Now, I will try to create an FTP Traffic from SRV (173.1.69.100) to PC (192.168.1.200), then I also create a big ICMP Traffic from SRV to 150.1.8.8, Initially both traffic will use R1 as a next-hop, based on these BGP Table on R2

Rack01R2#show bgp ipv4 unicast 192.168.1.0 BGP routing table entry for 192.168.1.0/24, version 22 Paths: (2 available, best #2, table default)   Advertised to update-groups:      1   13     173.1.23.3 from 173.1.23.3 (150.1.3.3)       Origin incomplete, metric 20514560, localpref 100, valid, external   13     173.1.12.1 from 173.1.12.1 (150.1.1.1)       Origin IGP, metric 0, localpref 100, valid, external, best Rack01R2#show bgp ipv4 unicast 150.1.8.8 BGP routing table entry for 150.1.8.8/32, version 7 Paths: (2 available, best #2, table default)   Advertised to update-groups:      1   13     173.1.23.3 from 173.1.23.3 (150.1.3.3)       Origin incomplete, metric 20642560, localpref 100, valid, external   13     173.1.12.1 from 173.1.12.1 (150.1.1.1)       Origin incomplete, metric 156160, localpref 100, valid, external, best

PfR eventually will start the learn process

Rack01R2#show pfr master border detail Border           Status   UP/DOWN             AuthFail  Version 150.1.2.2        ACTIVE   UP       00:10:03          0  3.0  Fa0/0           INTERNAL UP  Se1/0.23        EXTERNAL UP  Se1/0.12        EXTERNAL UP  External            Capacity      Max BW   BW Used    Load Status          Exit Id  Interface            (kbps)       (kbps)    (kbps)    (%)                       ---------           --------      ------   ------- ------- ------           ------  Se1/0.23        Tx        64          48         0       0 UP                    2                  Rx                    64         0       0  Se1/0.12        Tx       128          96       128     100 UP                    1                  Rx                   128        11       8

Because PfR Detected the bandwidth was overwhelm, hit above 75%, then it will conduct the active probing

Rack01R2#show pfr master traffic-class 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 -------------------------------------------------------------------------------- 192.168.1.0/24            N    N    N           N           N N                           DEFAULT*      @59         150.1.2.2 U               U 150.1.8.8/32              N    N    N           N           N N                           DEFAULT*      @59         150.1.2.2 Se1/0.12        U                U        U        0        0        0        0        5        4                U        U        0        0        N        N        N        N Rack01R2#show pfr border active-probes         OER Border active-probes Type      = Probe Type Target    = Target IP Address TPort     = Target Port Source    = Send From Source IP Address Interface = Exit interface Att       = Number of Attempts Comps   = Number of completions N - Not applicable Type     Target          TPort Source          Interface           Att   Comps DSCP echo     150.1.8.8           N 173.1.12.2      Se1/0.12              1       1 0 echo     150.1.8.8           N 173.1.23.2      Se1/0.23              1       1 0 echo     192.168.1.200       N 173.1.12.2      Se1/0.12              1       1 0 echo     192.168.1.200       N 173.1.23.2      Se1/0.23              1       1 0 Rack01R2#show pfr master OER state: ENABLED and ACTIVE   Conn Status: SUCCESS, PORT: 29281   Version: 3.0   Number of Border routers: 1   Number of Exits: 2   Number of monitored prefixes: 2 (max 5000)   Max prefixes: total 5000 learn 2500   Prefix count: total 2, learn 2, cfg 0   PBR Requirements met   Nbar Status: Inactive

After a while, 3-7 Minutes time frame, finally the PfR do its job, by notified me the following log message:

%OER_MC-5-NOTICE: Route changed Prefix 150.1.8.8/32, BR 150.1.2.2, i/f Se1/0.23, Reason Utilization, OOP Reason Utilization

Based on the show output, we could see that the Router is do the Performance Routing

Rack01R2#show pfr master traffic-class 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 -------------------------------------------------------------------------------- 192.168.1.0/24            N    N    N           N           N N                           INPOLICY        0         150.1.2.2 Se1/0.12        BGP                U        U        0        0    20247    22711      514        9                U       48        0        0        N        N        N        N 150.1.8.8/32              N    N    N           N           N N                           HOLDDOWN      133         150.1.2.2 Se1/0.23        BGP                U        U        0        0        0        0        7        9                U        U        0        0        N        N        N        N

And the Router try to Load-Balancing, by doing distribute the traffic to the other Link, which is eBGP Connection to R3.

Rack01R2#show pfr master border detail Border           Status   UP/DOWN             AuthFail  Version 150.1.2.2        ACTIVE   UP       00:21:26          0  3.0  Fa0/0           INTERNAL UP  Se1/0.23        EXTERNAL UP  Se1/0.12        EXTERNAL UP  External            Capacity      Max BW   BW Used    Load Status          Exit Id  Interface            (kbps)       (kbps)    (kbps)    (%)                       ---------           --------      ------   ------- ------- ------           ------  Se1/0.23        Tx        64          48        18      28 UP                    2                  Rx                    64         0       0  Se1/0.12        Tx       128          96       128     100 UP                    1                  Rx                   128        25      19 Rack01R2#show pfr border routes bgp BGP table version is 39, local router ID is 150.1.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete OER Flags: C - Controlled, X - Excluded, E - Exact, N - Non-exact, I - Injected    Network          Next Hop        OER    LocPrf Weight Path *> 150.1.8.8/32     173.1.23.3      CE                0 13 ? *> 192.168.1.0      173.1.12.1      CE                0 13 i

PfR will only work, if the Router have a parent route (Backup Route) in its RIB. The parent route can be from Static, IGP, or BGP route. So this is the most important concept of the PfR.

In this Example, R2 has a parent and child route from both the eBGP Peers, so the PfR would choose the path.

·        

       2-Try when the PfR doesn't have a parent route, and see it

In this section, I would stop advertising 150.1.8.8/32 from R3 to R2.

Rack01R2#show bgp ipv4 unicast 150.1.8.8 BGP routing table entry for 150.1.8.8/32, version 34 Paths: (1 available, best #1, table default)   Advertised to update-groups:      1   13     173.1.12.1 from 173.1.12.1 (150.1.1.1)       Origin incomplete, metric 156160, localpref 100, valid, external, best Rack01R2#show ip cef 150.1.8.8 150.1.8.8/32   nexthop 173.1.12.1 Serial1/0.12

I just clear the PfR [clear pfr master *], to restart the PfR Process, and after a while PfR do the Learn and find out that the link is heavily utilized, so the R2 would do the Active probe, because it didn’t have a parent route for the prefix 150.1.8.8/32, R2 just use Single Link to do the probing.

Rack01R2#show pfr master traffic-class 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 -------------------------------------------------------------------------------- 192.168.1.0/24            N    N    N           N           N N                           DEFAULT*      @21         150.1.2.2 Se1/0.12        U                U        U        0        0    30224    30224      496        5               25       25        0        0        N        N        N        N 150.1.8.8/32              N    N    N           N           N N                           DEFAULT*      @21         150.1.2.2 Se1/0.12        U                U        U        0        0        0        0       10       10               28       28        0        0        N        N        N        N Rack01R2#show pfr border active-probes         OER Border active-probes Type      = Probe Type Target    = Target IP Address TPort     = Target Port Source    = Send From Source IP Address Interface = Exit interface Att       = Number of Attempts Comps   = Number of completions N - Not applicable Type     Target          TPort Source          Interface           Att   Comps DSCP echo     150.1.8.8           N 173.1.12.2      Se1/0.12              2       2 0 echo     192.168.1.200       N 173.1.12.2      Se1/0.12              2       2 0 echo     192.168.1.200       N 173.1.23.2      Se1/0.23              2       2 0

So the summary was, R2 cannot resolve the other route in order to reach 150.1.8.8/32, because R2 didn’t have the parent route.

Let say that R2 will resolve the traffic to other Interface, in this case move from Se1/0.12 to Se1/0.23, and the Upstream router doesn’t have the route to 150.1.8.8, this case will be end up as a black-hole traffic right?. So, based on this reason, the PfR won’t redirect the traffic if it doesn’t have parent route in its RIB.

·         

·         3 - Try using 'traffic-class filter' to filter Only TCP traffic that PfR Will take care of it, any other traffic will not be notified by the PfR.

R2 ! ip access-list extended ACL_TCP_ONLY  permit tcp any any ! ! pfr master learn   traffic-class filter access-list ACL_TCP_ONLY !

The previous two traffic flows were still in action, where in the previous lab we would see those two traffic will be categorized in the PfR Learn traffic-class, but in this task the PfR Process will only take the TCP traffic, FTP from 173.1.69.100 to 192.168.1.200, other traffic, which is ICMP from 173.1.69.100 to 150.1.8.8, will not be processed by the PfR

Rack01R2#show pfr master traffic-class 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 -------------------------------------------------------------------------------- 192.168.1.0/24            N    N    N           N           N N                           INPOLICY        0         150.1.2.2 Se1/0.12        BGP                U        U        0        0    17630    21755      619       11                U       70        0        0        N        N        N        N

I will create two additional traffic, that is consist of:

·         HTTP Traffic from 173.1.69.100 to 150.1.1.1 (SRV to R1)

·         ICMP Traffic from 173.1.69.100 to 150.1.4.4 (SRV to R4)

From those two additional traffic, we wanna see that only HTTP Traffic is being processed by the PfR, let see:

Rack01R2#show pfr master traffic-class 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 -------------------------------------------------------------------------------- 192.168.1.0/24            N    N    N           N           N N                           INPOLICY        0         150.1.2.2 Se1/0.12        BGP                U        U        0        0    14657    18111      612       11                U       70        0        0        N        N        N        N 150.1.1.1/32              N    N    N           N           N N                           HOLDDOWN      264         150.1.2.2 Se1/0.23        BGP                U        U        0        0        0        0        1        1                U        U        0        0        N        N        N        N

I just so excited that the PfR Working perfectly as we tought \(^0^)/. Well I hope that this blog can help you a little to understand the concept of the PfR.

You could also refer to the documentation for more information about the feature available at :
http://www.cisco.com/en/US/docs/ios-xml/ios/pfr/configuration/15-1mt/pfr-basic.html

Happy Studying \(^0^)/