Re: Oer/PfR GRE tunnel

Hi Jay,

Yes, I've been using tunnel interfaces between border routers. I'm basically trying to test out using link-groups. I find that if I am just trying to control a standard prefix then I can get things to work. If I try to control specific application traffic where PBR needs to be used then I run into trouble.

Initially I was using BR loop backs as local interfaces but when I did a show oer master traffic-class I would see the state as DEFAULT* and the Protocol as U. Last night I found that if I changed the local interface to be the tunnel interface instead of the loopback, the protocol changed from U to PBR. This seems like a step in the right direction. However I still can't control the traffic.

During debugging I see a couple of interesting messages on the MC. One tells me that one of the BRs is more than one hop away ( I can't fathom what might be causing this), and I also see an "Uncontrol Prefix, Inconsistent View" message.

While debugging on the BR's I notice that a PBR policy is applied with an "nh" which I assume is next hop of 0.0.0.0. This policy is then immediately removed.

I can tell you that the GRE tunnel is working fine (no looping issues). I have 2 internal interfaces (tunnel and inside) on each BR as well as an external interface on each. All oer communication is working fine between MC and BRs. I'm using an oer-map referencing an ACL that looks like:

ip access-l ex R7DSCP
 permit udp any host 10.7.7.7 dscp af11

Active probes are all working and my policy looks like this:

oer-map MAN 10
  sequence no. 8444249301975040, provider id 1, provider priority 30
    host priority 0, policy priority 10, Session id 0
  match ip access-lists: R7DSCP
  backoff 300 3000 300
  delay relative 50
 *holddown 90
 *periodic 90
  probe frequency 56
 *mode route control
 *mode monitor fast
  mode select-exit good
  loss relative 10
  jitter threshold 20
  mos threshold 3.60 percent 30
  unreachable relative 50
  next-hop not set
  forwarding interface not set
  resolve delay priority 11 variance 20
  resolve utilization priority 12 variance 20

  Forced Assigned Target List:
   active-probe udp-echo 10.7.7.7 target-port 60000
 *link-group F00

Any light you or anyone else can shed is very much appreciated.

cheers,
Ben.

From: Jay McMickle <jay.mcmickle_at_yahoo.com<mailto:jay.mcmickle_at_yahoo.com>>
Reply-To: Jay McMickle <jay.mcmickle_at_yahoo.com<mailto:jay.mcmickle_at_yahoo.com>>
Date: Tuesday, 24 April 2012 3:56 AM
To: Ben Hughes <bhughes_at_imc.net.au<mailto:bhughes_at_imc.net.au>>, "ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>" <ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>>
Subject: Re: Oer/PfR GRE tunnel

Have you tried using tunnel interfaces between the border-routers? You would need to specify them as internal interfaces on the master controller as well.

HTH.

Regards,
Jay McMickle- CCNP, CCSP, CCDP, MCSE

From: Ben Hughes <bhughes_at_imc.net.au<mailto:bhughes_at_imc.net.au>>
To: "ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>" <ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>>
Sent: Monday, April 23, 2012 7:24 AM
Subject: Oer/PfR GRE tunnel

Guys,

Has anyone managed to successfully lab up a PfR scenario requiring a GRE tunnel in order to use PBR to direct traffic (ie BRs are not directly connected)? If so are you able to share some configs? I've been trying for ages to get this to work and it's driving me round the bend!!

cheers,
Ben.

Blogs and organic groups at http://www.ccie.net
Received on Mon Apr 23 2012 - 23:35:34 ART