Re: Oer/PfR GRE tunnel

From: Jay McMickle <jay.mcmickle_at_yahoo.com>
Date: Mon, 23 Apr 2012 18:49:45 -0700 (PDT)

I agree with Marc. 12.4.24T gave me dramatic different results in my Mock
Labs. I downgraded to 12.4.15(T10) on my 2811's and had to re-learn the
technology.
 
The Link-groups work differently on the lower IOS a well. I had
trouble using link groups (stayed DEFAULT*), but when I used next-hop, it went
into policy. However, it wouldn't remain stable.
 
I'm taking my lab next
week and was hoping that Brian from INE was going to get this topic going
prior, but I might miss that mark. I'm taking 3 points with me to the lab to
see I can exchange them on game day. OER has my number at this point. But no
worries, there another 70'something for me to bring back home on config. ;)
 
Cheers, labbers!

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

 
________________________________
From: Ben Hughes <bhughes_at_imc.net.au>
To:
marc abel <marcabel_at_gmail.com>
Cc: Jay McMickle <jay.mcmickle_at_yahoo.com>;
"ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>
Sent: Monday, April 23,
2012 7:01 PM
Subject: Re: Oer/PfR GRE tunnel

Hi Marc,

That could be it.
I'm running 12.4(15)T. I thought I would start out with just static and then
move to BGP. I'll add BGP and let you know if that fixes it. I did try it on
12.4(24)T before but I don't think I was using the tunnel interfaces as local
interfaces at that stage.

cheers,
Ben.

From: marc abel
<marcabel_at_gmail.com<mailto:marcabel_at_gmail.com>>
Date: Tuesday, 24 April 2012
9:49 AM
To: Ben Hughes <bhughes_at_imc.net.au<mailto:bhughes_at_imc.net.au>>
Cc: Jay
McMickle <jay.mcmickle_at_yahoo.com<mailto:jay.mcmickle_at_yahoo.com>>,
"ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>"
<ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>>
Subject: Re: Oer/PfR
GRE tunnel

What version of IOS are you using? Some older ones including
12.4(15)T require that you know the route through BGP. Newer IOS don't have
this requirement.

On Mon, Apr 23, 2012 at 6:35 PM, Ben Hughes
<bhughes_at_imc.net.au<mailto:bhughes_at_imc.net.au>> wrote:
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><mailto:jay.mcmickle_at_ya
hoo.com<mailto:jay.mcmickle_at_yahoo.com>>>
Reply-To: Jay McMickle
<jay.mcmickle_at_yahoo.com<mailto:jay.mcmickle_at_yahoo.com><mailto:jay.mcmickle_at_ya
hoo.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><mailto:bhughes_at_imc.net.au<mail
to:bhughes_at_imc.net.au>>>,
"ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com><mailto:ccielab_at_groupst
udy.com<mailto:ccielab_at_groupstudy.com>>"
<ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com><mailto:ccielab_at_groupst
udy.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><mailto:bhughes_at_imc.net.au<mail
to:bhughes_at_imc.net.au>>>
To:
"ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com><mailto:ccielab_at_groupst
udy.com<mailto:ccielab_at_groupstudy.com>>"
<ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com><mailto:ccielab_at_groupst
udy.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 - 18:49:45 ART

This archive was generated by hypermail 2.2.0 : Tue May 01 2012 - 08:20:46 ART