Cisco IPS inline mode
Inline Interface Mode
Operating in inline interface pair mode puts the IPS directly into the traffic flow and affects
packet-forwarding rates making them slower by adding latency. This allows the sensor to stop attacks by
dropping malicious traffic before it reaches the intended target, thus providing a protective service. Not
only is the inline device processing information on Layers 3 and 4, but it is also analyzing the contents
and payload of the packets for more sophisticated embedded attacks (Layers 3 to 7). This deeper analysis
lets the system identify and stop and/or block attacks that would normally pass through a traditional
firewall device.
In inline interface pair mode, a packet comes in through the first interface of the pair on the sensor and
out the second interface of the pair. The packet is sent to the second interface of the pair unless that
packet is being denied or modified by a signature.
Inline VLAN Pair Mode
You can associate VLANs in pairs on a physical interface. This is known as inline VLAN pair mode.
Packets received on one of the paired VLANs are analyzed and then forwarded to the other VLAN in the
pair. Inline VLAN pairs are supported on all sensors that are compatible with IPS 6.0 except NM-CIDS,
AIP-SSM-10, and AIP-SSM-20.
Inline VLAN pair mode is an active sensing mode where a sensing interface acts as an 802.1q trunk port,
and the sensor performs VLAN bridging between pairs of VLANs on the trunk. The sensor inspects the
traffic it receives on each VLAN in each pair, and can either forward the packets on the other VLAN in
the pair, or drop the packet if an intrusion attempt is detected. You can configure an IPS sensor to
simultaneously bridge up to 255 VLAN pairs on each sensing interface. The sensor replaces the VLAN
ID field in the 802.1q header of each received packet with the ID of the egress VLAN on which the sensor
forwards the packet. The sensor drops all packets received on any VLANs that are not assigned to inline
VLAN pairs.
VLAN Group Mode
You can divide each physical interface or inline interface into VLAN group subinterfaces, each of which
consists of a group of VLANs on that interface. Analysis Engine supports multiple virtual sensors, each
of which can monitor one or more of these interfaces.
This lets you apply multiple policies to the same sensor. The advantage is that now you can use a sensor
with only a few interfaces as if it had many interfaces.
Note You cannot divide physical interfaces that are in inline VLAN pairs into VLAN groups.
VLAN group subinterfaces associate a set of VLANs with a physical or inline interface. No VLAN can
be a member of more than one VLAN group subinterface. Each VLAN group subinterface is identified
by a number between 1 and 255.
Subinterface 0 is a reserved subinterface number used to represent the entire unvirtualized physical or
logical interface. You cannot create, delete, or modify subinterface 0 and no statistics are reported for it.
An unassigned VLAN group is maintained that contains all VLANs that are not specifically assigned to
another VLAN group. You cannot directly specify the VLANs that are in the unassigned group. When a
VLAN is added to or deleted from another VLAN group subinterface, the unassigned group is updated.
Packets in the native VLAN of an 802.1q trunk do not normally have 802.1q encapsulation headers to
identify the VLAN number to which the packets belong. A default VLAN variable is associated with
each physical interface and you should set this variable to the VLAN number of the native VLAN or to 0.
The value 0 indicates that the native VLAN is either unknown or you do not care if it is specified. If the
default VLAN setting is 0, the following occurs:
? Any alerts triggered by packets without 802.1q encapsulation have a VLAN value of 0 reported in
the alert.
? Non-802.1q encapsulated traffic is associated with the unassigned VLAN group and it is not
possible to assign the native VLAN to any other VLAN group.
Not quite sure what's the last one's application. Need to find out.

Post new comment