[c-nsp] OSPF on PIX?

[Adam Greene]

Yeah, we would much rather pass the traffic through the PIX than engage PIX
in OSPF. I believe you can do this by configuring neighbor statements on the
routers that need to communicate through the PIX. The neighbor statement
causes updates to be sent unicast, thus overcoming the TTL issue.

Since updates don't happen that frequently between neighbors, I wouldn't
expect that to account for all 15% of the additional CPU usage, but perhaps
for some of it. It seems more like just listening for OSPF packets is what
makes the PIX work so hard.

I'll check on reducing the priority to avoid DR/BDR negotiation. Thanks for
the tip.

The reason we're considering enabling OSPF is that the PIX has 4 interfaces.
We're generating redundant default routes from the two ASBRs on our network,
each with a different metric, so we can have redundant paths to the
Internet. The PIX receives default route metric 110 on Interface 1, and
default route metric 10 on interface 2. We want hosts on Interface 3 of the
PIX to be be able to make use of the primary gateway to the Internet (via
interface 1) and if that fails, for them to use the secondary gateway (via
interface 2). So far we haven't come up with a good way to do this aside
from having the PIX participate in OSPF.

If the 15% load on the PIX will not affect performance, we can live with it.
If it does, we may need to restructure things....

--A

---
[This e-mail was scanned for viruses by Webjogger's AntiVirus Protection System]