At 11:06 AM 4/15/2002, Paul Robertson wrote: > > Your interface should be able to handle maximum traffic load. > >Maximum traffic load changes based on what traffic you must handle.
It can also vary greatly on packet size and "load" metric, e.g. packets per second vs. megabits per second. >The firewall generally has one interface, if it's on the same segment as >60 clients, and it's in bridged mode, it must look at every packet on the >wire- even when that traffic is client<->client rather than >client<-through->firewall. <Disclaimer><Speculation> In a task-specific bridging firewall a vendor could have a per-port CAM table which included the local MAC addresses. That way each port could filter the local traffic (based on dst MAC address) before forwarding it to the firewall core, which would greatly reduce the amount of processing power required by the firewall. Granted, it would also result in a really bad worst-case scenario, but it would not surprise me if a vendor were to use this design. </Speculation> >If it's a real bridge, it'll inspect the traffic, look at its ruleset and >pass or drop the traffic. Which begs the question whether any "bridged" firewalls are more correctly described as "switches" with extensive use of port-specific hardware before the switch core / firewall process. > > If a machine does not respond to ARP's, where is the switch going to > > send the traffic? Default gateway, correct? Same for > >Switches don't send to gateways- they either send to a specific MAC or to >a promiscuous ports, in the case of a >(spanned/promiscuos/monitor/trunk...) port (maybe this is what you mena >by gateway?), it gets *all* traffic on every switch I've ever used, not >just unknown traffic, hence the collision issue. Maybe I'm missing a >switch configuration parameter though? There was a "workgroup" switch (forget which one, sorry) a few years back which used the technique of an "uplink" port for flooding behavior (aka what to do with unknown traffic). It was built on the design stipulation that there would only be a single ethernet host connected to each local port, so it was possible to have an exhaustive list of all locally-attached devices. Any addresses not local would therefore have to be connected to the uplink port. The benefit of this design was to eliminate port-flooding of frames to all ports for unknown addresses. The downside is of course that it didn't support more than 1 attached device per local port. This makes for bad situations if you don't have control over whether someone decides to cascade another switch in their cubical... In either case it didn't understand such non-layer-2 concepts as "default gateway". Whether to use a gateway was, as always, a decision of each IP host based on local routing table, subnet mask, destination address, etc. Regards, -Jim _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
