[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