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

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barrie Jones Cook wrote:
> 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.
> 

A quick test showed that without the access-list existing, all packets seem
to match the route map and are policy routed.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE7fjfE1XcgMgrtyYRAh0gAKDjW9Ue/FKgdIxjmD7MBkdIjsD/QgCfSKJ8
ny3qVJNXSbFyMLejXNRBOrg=
=9CVG
-----END PGP SIGNATURE-----