[nsp] policy routing / CEF-IP-POLICY: fib for address10.209.254.254 is with flag 0

[Kinczli Zoltán]

Hello,

  Some time ago, i met the same problem. A TAC engineer told me, that 'set ip next-hop' was there
to manipulate the BGP attribute, not the 'forwarding address' while policy routing.

  I think the reason behind is that it would require recursive resolution of the non-adjacent next hop, so all the policy-routing would have to be revised when there is a topo change/adjacency change.

  I don't know if it has changed or not... i was begging than to reflect that restriction in the documentation.

regards
  -z.

-----Original Message-----
From: Gert Doering [mailto:gert at greenie.muc.de]
Sent: Wednesday, January 21, 2004 4:50 PM
To: cisco-nsp at puck.nether.net
Subject: [nsp] policy routing / CEF-IP-POLICY: fib for
address10.209.254.254 is with flag 0


Hi,

another interesting challenge...

The problem:

Policy-Routing doesn't want to policy-route if the "set ip next-hop"
address is not directly adjacent.

interface FastEthernet0/1
 ip address 10.209.3.254 255.255.252.0
 ip route-cache policy
 ip policy route-map labor-policy
!
access-list 130 permit ip 10.209.1.0 0.0.0.255 135.80.0.0 0.0.255.255
access-list 130 permit ip 10.209.1.0 0.0.0.255 192.168.254.0 0.0.0.255
!
route-map labor-policy permit 10
 match ip address 130
 set ip next-hop 10.209.254.254
!

Intention: "Packets from 10.209.1.0/24 towards these destinations should
take whichever path is the best towards 10.209.254.254".

If I do this, and have CEF enabled, "debug ip policy" prints:

CEF-IP-POLICY: fib for address 10.209.254.254 is with flag 0
IP: s=10.209.1.1 (FastEthernet0/1), d=135.80.82.138, len 84, FIB policy rejected - normal forwarding

If CEF is off, I get:

IP: s=10.209.1.1 (FastEthernet0/1), d=135.80.82.138, len 84, policy match
IP: route map labor-policy, item 10, permit
IP: s=10.209.1.1 (FastEthernet0/1), d=135.80.82.138 (Multilink1), len 84, policy rejected -- normal forwarding


Connectivity and adjacencies are there:

Cisco-AVK#sh ip cef 10.209.254.254
10.209.254.254/32, version 21, cached adjacency 10.211.63.254
0 packets, 0 bytes
  via 135.80.82.254, 0 dependencies, recursive
    next hop 10.211.63.254, FastEthernet0/0 via 135.80.82.254/32
    valid cached adjacency

If I change the policy to read:

route-map labor-policy permit 10
 match ip address 130
 set ip next-hop 10.211.63.254

(which is directly adjacent), everything works as expected.

So my interpretation of this is: "indirect next-hops do not work for
policy routing".  And of course the question is "why?  and is there a
workaround to make it work?".  IOS is 12.2(21a) on a 2621XM.


As for "why would anybody want to do this", here's a bit of motivation.

Subnets A and B need to reliably communicate.

There is a ethernet connection with much bandwidth, but with some delay
issues and with some reliability issues, between them, crossing routes
X, Y, Z.

For timing critical traffic, there is a ISDN leased line, directly
connecting A and B.


  A ---------- small/low RTT ------------- B
  |                                        |
  +-- X --- Y --- Z --- fast/high delay----+


Bulk traffic is coming from 10.209.1.0/24, and should take the route
A->X->Y->Z->B.

Timing sensitive traffic is coming from 10.209.0.0/24, and should take
the direct route A->B.  (So "classic" routing is out).

So far, this could easily be done with a "set ip next-hop X" (direct
adjacency from A).

Unfortunately, it gets worse.  X/Y/Z have reliability issues, *and* are
not under our control.  So there is a BGP session A->X->Y->Z->B which
is used to make sure there is connectivity over that path.

B is announcing a loopback address via B->Z->Y->X->A and via a second
session B->A (with higher MED).  

So the idea was "policy-route towards that loopback IP.  If X/Y/Z work,
packets will travel that way.  If it doesn't work, packets take the
ISDN leased line for backup".

Yes, this is ugly (and I told them that it is, but there's a Telco 
involved in managing X, Y, and Z, so this cannot be fixed quick enough
for their needs).

Any other suggestions to sort this out:

  10.209.0.0/24 -> via ISDN, if available, X/Y/Z otherwise
  10.209.1.0/24 -> via X/Y/Z, if available, ISDN otherwise

are welcome.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Ez az üzenet és a hozzá kapcsolódó fájlok, tervezetek kizárólag a
Címzettnek szólnak, a bennük foglalt információk bizalmasak, melyek
titokban maradásához a Synergon Informatika Rt.-nek jogilag méltányolható
érdeke fuzodik. Amennyiben valamely hiba folytán Ön nem a címzettje ennek a
levélnek, kérjük, semmisítse meg, és értesítse az üzenet küldojét. Az
üzenet az elküldés elott vírusellenorzésen esett át, de a vírusmentességére
nincs semmilyen garancia, ezért kérjük, ellenorizze azt!

DISCLAIMER

This e-mail and any attached files are confidential and may be legally
privileged. The content of this e-mail is subject of efforts by Synergon to
maintain its confidentiality. Also this e-mail is intended for the sole use
of the individual or entity to whom it is addressed. If you are not the
addressee, and received this transmission in error please delete this
e-mail and notify its sender immediately. This e-mail message has been
checked for computer viruses but it could still be infected. Please test it
for viruses before use.