RE: PfR - BR internal interfaces on different subnets

I guess no one likes my "hard" question :(

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Gavin Schokman
Sent: 19 April 2010 00:22
To: ccielab_at_groupstudy.com
Subject: RE: PfR - BR internal interfaces on different subnets

Thoughts anyone?

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Gavin Schokman
Sent: 17 April 2010 14:23
To: ccielab_at_groupstudy.com
Subject: 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 Wed Apr 21 2010 - 18:11:41 ART