[nsp] Routing decisions on a PIX?
John Dorsey
dorsey at colquitt.org
Tue Jun 10 16:40:58 EDT 2003
All,
Comments below.
> > PIX will do most specific matching, but on equal matches, it will go by
> > metric value to decide one interface over another.
>
> That's not my experience. I had:
>
> route inside 172.16.0.0 255.255.0.0
>
> and several LANtoLAN VPN's connecting with numbers like 172.16.1.0
> 255.255.255.0 and 172.16.2.0 255.255.255.0. These did not work until I
> removed the "route inside" and replaced it with specific routes to the
> inside networks, like:
>
> route inside 172.16.10.0 255.255.255.0
> route inside 172.16.11.0 255.255.255.0
> route inside 172.16.12.0 255.255.255.0
The PIX does do most-specific matches for routing. The problem
is, VPN encapsulation isn't a routing decision, and the PIX doesn't
treat tunnel endpoints as virtual interfaces.
AFAICT, it uses this (simplified) path:
(1) Packet is received
(2) Packet is filtered and munged (NAT, fixup, ...)
(3) Packet is routed by longest (most specific) match. The 'metric' is
used as a tie-breaker.
(4) *If* some 'crypto map' is enabled on the outbound interface, and
matches the packet, then the packet is sent over the tunnel.
Cisco probably has a document somewhere with all the detail I've
left obscured in (2) above. And there may be some configurations that
invalidate my observations.
Cheers,
John Dorsey
More information about the cisco-nsp
mailing list