PfR: BR internal interfaces on different subnets

Hi group,
 
Has anyone got PfR with 2 or more border routers working where the internal
interfaces
of the Border Routers are not on the same subnet?
 
I've been playing with PfR the last week and fairly happy with it in
general. One question
I can't seem to answer relates to one case of the topology setup.
 
The topology I'm trying to setup is Setup 1 below where there are 2x BR's
and 1x MC.
The BR's are both directly connected to the MC, but they are on different
subnets
from each other. i.e. the BR's are NOT directly connected.
 
       Please view in a fixed-width font such as Courier.
 
 Setup 1: BR's on different subnet, i.e. not directly connected
 
                           BR1
                          +----+
                       int| |ext
                 +--------+ R2 +---------------------+
    MC | | | |
  +----+ | +----+ |
  | +---------+ |
  | R1 | +-+--+
  | +------+ | |
  +----+ | | R4 |
              | | |
              | +-+--+
              | +----+ |
              | int| |ext |
              +-----------+ R3 +---------------------+
                          | |
                          +----+
                           BR2
 
When I try to enable my PfR policy, I get the following error:
*Mar 1 00:31:21.615: %OER_MC-5-NOTICE: PBR Requirements not met;
Applications will
not be controlled
 
This makes sense since my configs are optimising applications rather than
prefixes and hence we need to use PBR. There is a note in the DocCD
saying the following:
 
--quote
This device specific control is implemented by OER using policy-based
routing
(PBR) functionality. If the traffic in this scenario has to be routed out to
a
different device, the remote border router should be a single hop away or a
tunnel interface that makes the remote border router look like a single hop.

--end-quote
 
So I have altered my topology to add a tunnel interface between R2 & R3, but
I get
the same error and all the traffic-class entries just stay in the "Default"
state,
i.e. PfR is not controlling them.
I also get a second error now:
 
*Mar 1 03:16:07.975: %OER_MC-5-NOTICE: Uncontrol Appl Prefix 150.1.99.0/27
defa 6
[1, 65535] [19, 19], Inconsistent view
 
 
 Setup 2: BR's on different subnet, i.e. not directly connected,
          but tunnel interface config'd between them
 
                           BR1
                          +----+
                       int| |ext
                 +--------+ R2 +---------------------+
    MC | | | |
  +----+ | +-+--+ |
  | +---------+ | |
  | R1 | | +-+--+
  | +------+ |Tun23 | |
  +----+ | | | R4 |
              | | | |
              | | +-+--+
              | +-+--+ |
              | int| |ext |
              +-----------+ R3 +---------------------+
                          | |
                          +----+
                           BR2
 
 
Just for the record, when I put the Border Routers internal interfaces on
the same
subnet, as in setup 3 below, PfR works perfectly!
 
 
 Setup 3: Both BR's on same subnet
 
                          +----+
                       int| |ext
                 +--------+ R2 +---------------------+
    MC | | | |
  +----+ | +----+ |
  | | | BR1 |
  | R1 +---------+ +-+--+
  | | | | |
  +----+ | | R4 |
                 | | |
                 | +-+--+
                 | +----+ |
                 | int| |ext |
                 +--------+ R3 +---------------------+
                          | |
                          +----+
                           BR2

 
 
Below are my configs for Setup #2:

! R1
 
oer master
 policy-rules POLICY1
 port 6767
 traceroute probe-delay 10000
 logging
 !
 border 192.168.23.2 key-chain R2
  interface FastEthernet2/0 internal
  interface Serial1/0 external
 !
 border 192.168.23.3 key-chain R3
  interface FastEthernet2/0 internal
  interface Serial1/1 external
 !
 learn
  throughput
  delay
  periodic-interval 2
  monitor-period 1
  list seq 1 refname TELNET
   traffic-class access-list TELNET
   aggregation-type prefix-length 32
   delay
 no max range receive
 holddown 90
 backoff 90 90
 mode route control
 !
 active-probe tcp-conn 150.1.99.9 target-port 23
 active-probe tcp-conn 150.1.199.9 target-port 23
!
 
ip access-list extended CHARGEN
 permit tcp any eq chargen 150.1.9.0 0.0.0.31
 permit tcp any eq chargen 150.1.99.0 0.0.0.31
 permit tcp any eq chargen 150.1.199.0 0.0.0.31
 permit tcp any 150.1.9.0 0.0.0.31 eq chargen
 permit tcp any 150.1.99.0 0.0.0.31 eq chargen
 permit tcp any 150.1.199.0 0.0.0.31 eq chargen
 

ip access-list extended TELNET
 permit tcp any eq telnet any
 permit tcp any any eq telnet
!
ip prefix-list HTTP seq 5 permit 150.1.9.0/25
ip prefix-list HTTP seq 10 permit 150.1.99.0/25
ip prefix-list HTTP seq 15 permit 150.1.199.0/25
!
!
oer-map POLICY1 10
 match oer learn list TELNET
 set mode select-exit best
 set delay threshold 800
 set mode monitor fast
 set resolve delay priority 1 variance 5
 no set resolve utilization
 set traceroute reporting
 set probe frequency 5
!
oer-map POLICY1 20
 match traffic-class application http prefix-list HTTP
 set mode select-exit good
 set mode monitor active
 set resolve delay priority 1 variance 5
 set resolve loss priority 2 variance 5
 no set resolve utilization
 set delay threshold 1000
 set loss threshold 300
!
oer-map POLICY1 30
 match traffic-class access-list CHARGEN
 set mode monitor passive
 set resolve utilization priority 1 variance 5
 no set resolve delay
!
 
 
 
! R2
 
oer border
 local Tunnel23
 port 6767
 master 150.1.1.1 key-chain R1
 
! R3
 
oer border
 local Tunnel23
 port 6767
 master 150.1.1.1 key-chain R1
 
 
Looking forward to some guidance on this one!
 
Cheers,
Gavin

Blogs and organic groups at http://www.ccie.net
Received on Sat Apr 17 2010 - 14:23:10 ART