logging switches

Depends on your requirements.

For most people, it's just setting up "logging host", set a logging level, and enable logging; the result will be sent via UDP syslog on the designated host, which would write the entry to a file. Sophisticated syslog daemons can choose output filenames based upon various parameters in the message, and possibly even trigger actions (e.g., page someone) if a serious problem is detected. Along these lines, "logging facility" can make it easier to distinguish between various hosts.

For some people, UDP syslog is not sufficient, under the theory that an event that goes unlogged might well be the attacking event, if the attacker has provoked turning off the logs. Turning off the logs can often be provoked by flooding the device with innocent-looking requests, probably all with forged addresses: when the disk fills up, it stops logging. Or if events come in too quickly (fast attacker) then UDP syslog might get lost in the network traffic, or UDP syslog writes might get throttled by the device to prevent internal network congestion.

For such people, some devices allow logging via TCP syslog: a TCP connection is formed to the logger, and no further traffic is permitted through the security boundary until the TCP connection sends back an acknowledgement that the event was logged.

Or some locations dump all the events to a printer, or to a tamper-proof write-once unit, in case court-evidence quality logging is necessary.

For most locations, the difficulty is not in getting events logged: the difficulty is in making sense of what got logged, especially correlating events and detecting intrusion attempt patterns. Even just post facto policy violation analysis requires some good data mining if you are logging hundreds of thousands of events per day per security gateway...