[c-nsp] route-map behavior with policy routing

[Barrie Jones Cook]

Hi all,

I'm helping out on a network that has Cisco 3750s as
core and distribution routers/switches.  For various
reasons, policy routing is used to direct traffic to
different interfaces on the core routers.  I'm not too
familiar with policy routing, so this may turn out to
be a silly question, but I can't find an answer no
matter how many google queries I come up with, so
please bear with me.  

Anyway, it's a pretty standard architecture of:

     core1---core2
       | \   / |
       |  \ /  |
       |   X   |
       |  / \  |
     dist1   dist2
     / | \     | \
    a1 a2 a3   a4 a5   

On the dist routers, "ip policy route-map PBR" is
applied to the access switch, or a[n], interfaces like
this:

interface Vlan16
 description a2
 ip address X.X.X.X 255.255.255.252
 ip policy route-map PBR

route-map PBR permit 10
 match ip address 90
 set ip next-hop Y.Y.Y.Y Z.Z.Z.Z

where Y.Y.Y.Y is the other end of the link to core1,
and Z.Z.Z.Z is the other end of the link to core2.

On core1 and core2, it's very similar; the same
route-map is applied to the incoming vlan interfaces
for dist1, dist2 and the opposite core.  On core1, the
set ip next hop addresses are first the far end IP of
the desired outbound connection, and then a backup in
case the primary is down, and finally the IP of the
other end of the link to core2.  On core2, the next
hop is set to the ip of the other end of the core1
link, and then the ip of a backup interface on core2.

Unfortunately, I have no console access to this
network (yet) and when I make a change, I log in from
a server off of a2.  I lose my connection when I try
to change access-list 90 on core2 as follows:

core2#conf t
Enter configuration commands, one per line.  End with
CNTL/Z.
core2(config)#no access-list 90
core2(config)#access-list 90 denyRead from remote host
core2: Connection timed out

I still have my connection to core1, but core1 cannot
ssh to core2, and customers start complaining about
network problems at this point.  Then, I get someone
who has a connection to a server somewhere else inside
the network to log onto core2, he pastes the new
access-list 90 in for me (which includes that first
deny and then several permits), and voila, we're back
in business.

Now, if a route-map permit statement matches an
access-list and there is no access-list (which I had
always assumed meant that the implicit deny any came
into effect), shouldn't the route-map just move on and
not match anything, meaning that the next-hop is
unchanged on *all* traffic, and it's all routed
normally?  I'm sure it would be interesting to see
exactly what interfaces are unreachable during this
issue, but unfortunately with customers complaining,
there is little time to do so.

Thanks,
Barrie