On Sun, 23 Jan 2000, Philipp Buehler wrote:

> > For instance if your "normal" network is 10.10.10.0/24, and the other
> > devices on the network are 192.168.10.0/24, and the FastEthernet 0
> > interface is 10.10.10.1, then "ip route 192.168.10.0 255.255.255.0 fastether 0"
> giving the interface an IP from that 192-net too would help :)
> Like: "ip address 192.168.10.1 255.255.255.0 secondary"

It doesn't really "help", AFAICT you'll still have the same size ARP table
for that interface, the only benefit you'd gain is in having the gateway
statements on the clients "match" the addresses on the host (because
you'll need a similar route on each client)- or if you have a client that
won't route to an interface and needs a gateway address (I haven't met a
client IP implementation yet that wouldn't accept either a device route,
or a route through it's own IP address for a different subnet, and I've
used this trick quite a bit in the past with poorly numbered networks
when bringing them back into sanity in cases where I couldn't supernet.)

Adding a shadow interface definition makes more work for the stack when
it's going down to find the correct MAC address to source the packet as,
unless the shadow interface is the last one in the table.

Device routes function just fine without a shadow interface definition.
Adding a shadow interface either adds an additional interface for the
device to have to manage, or just has the equipment do the same device
routing internally.  In one case it adds latency, in the other it brings
no advantage.

Since I don't have a PIX, I don't even know if it supports shadown
interfaces, but I do know that any reasonable IP implementation supports
routing to devices or its own IP address when it doesn't support device
routing.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
[EMAIL PROTECTED]      which may have no basis whatsoever in fact."
                                                                     PSB#9280

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to