Port Mirroring on a Juniper MX
From: http://networkarch.blogspot.com/2012/08/port-mirroring-on-juniper-mx.html
Setting up an analyzer, or SPAN, port on a Juniper EX switch is a pretty straightforward process. Setting up the same thing on an MX80 is a little bit of a pain. On an EX, it’s very similar to a Cisco: one port in, one port out. On an MX, you have to provide a next-hop address to send all of the sampled traffic. This last piece was a little bit of a pain to figure out – even though the end solution is ridiculously simple.
Here’s the configuration for making this happen.
1. Add the following statement under the [forwarding-options] stanza:
port-mirroring {
input {
rate 1;
run-length 1;
}
family inet {
output {
interface ge-1/1/4.0 {
next-hop 10.0.0.2;
}
no-filter-check;
}
}
}
2. Create an input and an output firewall filter for port mirroring:
filter output-pm-test {
term 1 {
then {
count output-pm;
port-mirror;
accept;
}
}
}
filter input-pm-test {
term 1 {
then {
count input-pm;
port-mirror;
accept;
}
}
}
3. Apply the firewall filter to an existing interface:
family inet {
filter {
input input-pm-test;
output output-pm-test;
}
4. Configure the next-hop interface referenced in the port-mirroring configuration in step #1:
description “Test port-mirroring”;
unit 0 {
family inet {
address 10.0.0.1/30 {
arp 10.0.0.2 mac 12:34:56:12:34:56;
}
}
}
5. Commit these above changes.
6. Run the following command:
monitor interface ge-1/1/4
You should see incrementing output traffic as long as the interface is up:
Output bytes: 22526615 (20856 bps)
I tested this by plugging my laptop into ge-1/1/4 and allowing Wireshark to put my NIC into promiscuous mode.
The problem with the above config was in step #4. I was trying to place a next-hop address on a device that had a passive, “tap”, port. There was a eureka moment last night while I was talking to a colleague about setting a static arp entry under the interface. This is the equivalent of forcing traffic out of that interface no matter what. Also, as you can see, the above MAC address is bogus and is used to enable the “10.0.0.2” next-hope address – there’s no need to rely on ARP to pull that off.
My first attempt at the above was a total disaster. I found an article on Juniper’s website that gave me the idea to create a next-hop to a logical tunnel that would be cross-connected to another logical tunnel in a bridge domain… the above is a whole heck of a lot easier to implement!
