[j-nsp] port mirror to multiple ports on MX80 in inet6

[Paul Vlaar]

Clarke,

thanks for your response.

On 23/10/12 10:59 PM, Clarke Morledge wrote:
> ---------------------------------------------------
> My question for you would be if you have an IRB interface associated
> with the bridge-domain that your mirror source port is in, and if the
> ICMP traffic coming into the router is hitting that IRB.  If that is the
> case, the MX will not treat the traffic coming into your IRB interface
> via your "encapsulation ethernet-bridge" as Layer2 traffic in this
> context, so it will not get mirrored.
> -----------------------------------------------------

There is indeed an IRB associated with the bridge-domain of the port to
be mirrored:

mx80> show configuration bridge-domains VLAN100 routing-interface
routing-interface irb.100;

> show configuration interfaces irb.100
family inet {
    address x.x.158.1/26;
}

A traceroute from another router that is one L3 hop away from the MX80,
to the IP address of the host connected to the interface that we're
doing the port mirror on:

cisco#traceroute x.x.158.13
Type escape sequence to abort.
Tracing the route to 199.115.158.13
VRF info: (vrf in name/id, vrf out name/id)
  1 x.x.158.193 0 msec 0 msec 0 msec
  2 x.x.158.13 0 msec 0 msec 0 msec
cisco#

x.x.158.193 is the address of the point to point link at the MX80, and
x.x.158.13 is the IP address of the mirrored host.

So as far as I can see it's not hitting the irb.100 address, however it
is doing this on the return, as it's the default gateway out of the host
at x.x.158.13. But the return is where we catch the ICMP reply, so that
part works.

To be complete here, this is the L3 interface where the traffic comes in
from the other router:

mx80> show configuration interfaces ge-1/3/11
unit 0 {
    family inet {
        address x.x.158.193/30;
    }
}

And this is the FIB entry for the target host:

mx80> show route forwarding-table destination x.x.158.13
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
x.x.158.13/32  dest     1 0:1b:21:84:d7:a6   ucst   768     4 ge-1/0/2.0

Routing table: default-switch.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    rjct   538     1

Routing table: __master.anon__.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            perm     0                    rjct   529     1


> ------------------------------------------------------
> 
> With respect to the vlan tagging on the port mirror output interface,
> the L2 packet being mirrored will egress with the original vlan tag
> intact, no matter what vlan id you configure on the mirror destination
> interface.
> 
> However, if you insert the "vlan-id" keyword into the "bridge-domain"
> configuration, you can manipulate the vlan tag that gets egressed out of
> your mirror destination port.  But if the "vlan-id" in the bridge domain
> is the same as the vlan-id of the mirror destination port, the original
> packet vlan-id gets preserved on output.

I've tried setting vlan-id on the bridge-domain for the analyzer port:

[edit bridge-domains analyzers]
mx80# show
domain-type bridge;
vlan-id 1000;
interface ge-1/3/2.0;

After I commit, when I ping from the host connected to the same bridge
domain as the mirrored port, where before I could see the ICMP request
go in as well, I now only see the reply:

17:22:26.067209 00:1b:21:84:d7:a6 > 00:1b:21:86:a5:22, ethertype IPv4
(0x0800), length 98: x.x.158.13 > x.x.158.5: ICMP echo reply, id 56599,
seq 2, length 64
17:22:27.067850 00:1b:21:84:d7:a6 > 00:1b:21:86:a5:22, ethertype IPv4
(0x0800), length 98: x.x.158.13 > x.x.158.5: ICMP echo reply, id 56599,
seq 3, length 64

And what's more it is untagged now.

The same for pinging from the cisco router:

17:25:22.720228 00:1b:21:84:d7:a6 > 80:71:1f:c6:34:f0, ethertype IPv4
(0x0800), length 114: x.x.158.13 > x.x.158.194: ICMP echo reply, id 33,
seq 2, length 80

(previously this was tagged as well)

So perhaps a trick can be found here to make this work both ways...

> I have not tested this, but my guess is that this might also apply to
> packets being mirrored that are untagged at the source.
> 
> Port mirroring on this platform is enough to make your head spin.

I unfortunately have to agree on that.

	~paul