Hi "P",
Thanks for taking the time to respond to my email. The way the network is
setup (right now) is that PBR is setup on the incoming interface into RtrA
which will only get network traffic from a.a.a.a and never see any traffic
from the incoming interface belonging to b.b.b.b.
a.a.a.a is our lab traffic and I would like for it to use a different T1
(through RtrA) than what our real network is using which is a T1 on RtrB.
I thought about implementing VRFs but I want to make sure that I cant do it
any other way.
In regards to the example you gave:
route-map dink permit 10
match ip address 10 ! match the target src IPs
set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1.
!
route-map dink permit 20
set ip next-hop 10.100.0.1 ! for all other traffic, route
! to loopback interface
I went ahead and tried this. I setup a second route-map and pointed the
next-hop to the internal loopback interface. I then shut down the T1 on the
router and enabled debug to see what happend. The "failover" failed. Here
is what the debug is showing:
1d01h: IP: s=a.a.a.a (FastEthernet0/0), d=198.6.1.1, len 92, FIB policy
match
1d01h: CEF-IP-POLICY: fib for addr 10.0.0.2 is default; Nexthop rejected
So as you can see, the second route-map failed to be used. When the packet
came in, it matched the first route-map regardless of whether the next-hop
was reachable or not.
What about using the command "ip next-hop verify-availability". I was
reading up on this feature but I am not sure if I understand its use.
Perhaps someone can fill me in.
Thanks,
Mario Puras
SoluNet Technical Support
Mailto: [EMAIL PROTECTED]
Direct: (321) 309-1410
888.449.5766 (USA) / 888.SOLUNET (Canada)
-----Original Message-----
From: p b [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: RE: policy based routing and backup [7:71482]
I'm not sure I understand completely why you want to do
this, and it's been a while since I've dinked with PBR,
but here's some thoughts on one might get this to work.
I've done something similar, but not exactly what's below,
so YMMV. Note, VRFs might fit better and I've listed some
details on a VRF approach below.
As I recall, one of the issues with PBR is that once
you enable policy routing on an interface, normal L3
forwarding is completely bypassed. Thus, you can
perform policy for the identified packets, but for any
packets that you want handled "normally", you're hosed
or have to use the hack below.
Also, the approach below requires that normal L3 forwarding
is applied to the IP provided in the "next-hop" statement.
I think some earlier IOS revs (12.0) would not perform a L3
lookup on the next-hop IP. Instead, it was assumed that
the "next-hop" was an end-point to a locally connected
interface.
Config background:
Assume that the subnet for the T1 between router A and
the ISP's router is 10.0.0.0/30. Assume your router
has the .1 address and the remote has the .2 address
(10.0.0.2).
Assume that you have a loopback define and its IP
address is 10.100.0.1.
Config snipets:
On all of A's internal interfaces, you'll need to configured
"ip policy route-map dink".
The route-map would look something like this:
route-map dink permit 10
match ip address 10 ! match the target src IPs
set ip next-hop 10.0.0.2 ! set next-hop to ISP's side of T1.
!
route-map dink permit 20
set ip next-hop 10.100.0.1 ! for all other traffic, route
! to loopback interface
Discussion:
Ok, how does this work. Assume a packet arrives on an
interface with PBR enabled and processed by the "dink"
route-map. If the packet's source is in the target range,
set the next-hop to 10.0.0.2. The router then does a L3
lookup on 10.0.0.2. If the T1 is up, 10.0.0.0/30 will be
in the route table pointing to the T1 and thus the packet
gets sent out the local T1. When this T1 is down, there
won't be a route entry for 10.0.0.0/30. So when the router
does the L3 lookup on 10.0.0.2, it matches the default
and the packet is sent to router B. (Recall that the poster
indicate defaults were sent from both ISPs). Note that
this approach requires the router to perform a L3 lookup
on the next-hop. This is required in order to get the
failure scenario to work correctly. You'll need to confirm
whether your IOS supports this functionality.
Now, what about packets whose sources don't match the
first part of the route-map and drop to the route-map's
second stage? Presumably we want this packet to follow the
standard L3 routing policy defined via LOCAL_PREF, etc.
To do this, we need to get the packet processed by L3 as if
it just arrived on an interface. One way to do this is to
set the "next-hop" to the local loopback interface IP. The
packet is queueed on that logical interface, and then gets
processed via normal L3 forwarding. So the router forwards
the packet to itself, L3 processes the packet, and then
sends it out the desired interface.
Note, I think all packets L3 forwarded by the loopback
are process switched (you'll need to confirm if this is
the case and whether the router has the horsepower to
handle this.) In order to deal with the process switching
overhead, one could instead forward the packet to a "lollipop" interface.
This is basically a port which is wired back
to another port on the same router. Suppose you have two
FE ports free. You wire them together with a crossed cable,
configure the interface as unnumbered, and then set the
second stage of the "dink" route-map to set the next-hop
the the FE interface. This eliminates the process switching
problem, but leaves you with another single point of
failure. I've never tried this lollipop interface stuff, but
had heard it proposed a few times.
You might want to look at VRFs instead and map packets with
those certain sources into one VRF and all other packets into
the global routing table.
In the VRF, define two static defaults with different metrics.
The lower metric default points to the local T1 and the second
default with higher metric points to router B's enet IP. When
the T1 is up, the lower metric default is in the VRF routing table
and traffic goes over the T1. If the T1 fails, only the higher
metric default pointing to B is in the VRF. Probably cleaner to
do it this way...
Hopefully, this will give ya some options to consider....
[EMAIL PROTECTED] wrote:
>
> Hi all. I have a question that I would like your opinion on.
> I have 2
> routers each with a T1 to the upstream provider. Both routers
> are running
> eBGP to each provider only accepting partial routes and a
> default from each.
> In additon, each router is peering with each other via iBGP
> through a
> directly connected ethernet link which is also running ospf.
>
>
> ISPA ISPB
> | |
> | |
> RtrA---ibgp---RtrB
>
>
> Router A advertisements:
> a.a.a.a
> b.b.b.b w/prepend
>
>
> Router B advertisements:
> b.b.b.b
> a.a.a.a w/prepend
>
>
>
> Everything is working as I would expect it. I have access into
> the network
> if either one of the T1 goes down. If I ping or traceroute
> sourcing it from
> any interface from within RtrA to an IP address on the net, the
> packets goes
> out based on longest match and preferred route based on
> local-pref. This
> results in almost always going through RtrB. This used to be
> acceptable.
>
> I would like to set up a policy on RtrA to match on source
> address of
> a.a.a.a to always (as long as RtrA T1 is up) go out RtrA T1
> instead of RtrB.
> So how do I set it up such that IF RtrA T1 goes down the
> traffic from
> a.a.a.a (source) goes out RtrB T1? Does anyone have an example
> on how to do
> this?
>
>
>
>
>
> Thanks,
>
> Mario Puras
> SoluNet Technical Support
> Mailto: [EMAIL PROTECTED]
> Direct: (321) 309-1410
> 888.449.5766 (USA) / 888.SOLUNET (Canada)
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=71569&t=71482
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
