SPAN

mikearama

Hey techies... got a plan to test some IDS devices (Juniper and TopLayer), using SPAN. This is a first for me.

On one of the switches in question (a 3750 stack), entered these commands:

EAST-SW1(config)#monitor session 1 source int f2/0/10
EAST-SW1(config)#monitor session 1 destination int f2/0/25

And after a wr mem, this:

EAST-SW1#sh monitor
Session 1

---

Type : Local Session
Source Ports :
Both : Fa2/0/10
Destination Ports : Fa2/0/25
Encapsulation : Native
Ingress : Disabled

Can someone offer an opinion on the Ingress being disabled? I can see that if I enter a command using ingress, I'm given the options of:

dot1q ingress forwarding using dot1q encapsulation
isl ingress forwarding using isl encapsulation
untagged ingress forwarding using untagged encapsulation
vlan Set default VLAN for untagged ingress traffic

Are these significant? or is my setup above sufficient? FYI, the port being mirrored belongs to vlan 216... the port acting as destination is in 200. Is that significant? Do they have to match?

Thanks kindly,
Mike

dtlokee

The idea of Ingress was designed for connecting an IDS to the sitch. IDS devices will need a way to communicate with the network to do things like send TCP resets to close session that violate a rule configued on the IDS. Some IDS devices will use an alternate port to send TCP resets so ingress on the span destination port is not needed.

mikearama

Appreciate the info... still worried about the vlan issue.

Am I right that the forwarding takes place at the mac level (on the same switch), before vlan tagging takes place? or do the source / destination ports have to be in the same vlan?

thanks.

dtlokee

Is the source interace a trunk interface?

The encapsulation for ingress is only on the SPAN destination interface, this is where you will be connecting your IDS. If the IDS will need to send TCP resets out this same interface then you will need to configure the SPAN session to allow ingress, if it's not, then don't worry about it.