Using RPM to generate traffic on a Junos device

RPM (Realtime Probe Monitoring) on a Junos device (similar to IP SLA feature on IOS) is used to monitor network performance between the two end points in a network. In a lab environment, we can use this feature to generate “real” traffic for testing QoS, or security policies, without having to have a real traffic generator, which is very handy. RPM can generate TCP and UDP traffic, in addition to ICMP (which can be easily done with the ping command.

The following are config to simulate ICMP/UDP/TCP traffic from R1 (simulating a Client machine) to R2 (Server).

Configuration

lab@R1> show configuration services   
rpm {
    probe ICMP_Probe {
        test Generate_ICMP_Ping {
            probe-type icmp-ping;
            target address 2.2.2.2;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            source-address 1.1.1.1;
            dscp-code-points cs1;
            data-size 100;
        }
    }
    probe IP_Phone {
        test Voice_RTP {
            probe-type udp-ping;
            target address 100.1.2.3;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            destination-port 51000;
            source-address 100.1.1.1;
            dscp-code-points ef;
            data-size 100;
        }
    }
    probe TCP_Probe {
        test Generate_TCP_Ping {
            probe-type tcp-ping;
            target address 2.2.2.2;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            destination-port 50000;
            source-address 1.1.1.1;
            dscp-code-points be;
            data-size 100;
        }
    }                                   
    probe-limit 500;                    
} 


lab@R2> show configuration services 
rpm {
    probe-server {
        tcp {
            port 50000;
            # destination-interface lo0.0;
        }
        udp {
            port 51000;
            # destination-interface ge-0/0/1.0;
        }
    }
}

Verification

lab@R1> show services rpm probe-results 
 Owner: IP_Phone, Test: Voice_RTP
 Target address: 100.1.2.3, Source address: 100.1.1.1, Probe type: udp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:56 2014, No hardware timestamps
 Rtt: 2593 usec
 Results over current test:
 Probes sent: 7, Probes received: 7, Loss percentage: 0
 Measurement: Round trip time
 Samples: 7, Minimum: 666 usec, Maximum: 4624 usec, Average: 3008 usec, Peak to peak: 3958 usec, Stddev: 1370 usec,
 Sum: 21053 usec
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 623 usec, Maximum: 4110 usec, Average: 1485 usec, Peak to peak: 3487 usec, Stddev: 1156 usec,
 Sum: 14846 usec
 Results over all tests:
 Probes sent: 107, Probes received: 107, Loss percentage: 0
 Measurement: Round trip time
 Samples: 107, Minimum: 422 usec, Maximum: 4684 usec, Average: 1019 usec, Peak to peak: 4262 usec, Stddev: 981 usec,
 Sum: 109060 usec

 Owner: TCP_Probe, Test: Generate_TCP_Ping
 Target address: 2.2.2.2, Source address: 1.1.1.1, Probe type: tcp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:55 2014
 Rtt: 940 usec
 Results over current test:
 Probes sent: 6, Probes received: 6, Loss percentage: 0
 Measurement: Round trip time
 Samples: 6, Minimum: 940 usec, Maximum: 1153 usec, Average: 1053 usec, Peak to peak: 213 usec, Stddev: 65 usec,
 Sum: 6318 usec 
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 952 usec, Maximum: 1179 usec, Average: 1044 usec, Peak to peak: 227 usec, Stddev: 72 usec,
 Sum: 10444 usec
 Results over all tests:
 Probes sent: 106, Probes received: 106, Loss percentage: 0
 Measurement: Round trip time
 Samples: 106, Minimum: 762 usec, Maximum: 1803 usec, Average: 1039 usec, Peak to peak: 1041 usec, Stddev: 134 usec,
 Sum: 110160 usec

 Owner: ICMP_Probe, Test: Generate_ICMP_Ping
 Target address: 2.2.2.2, Source address: 1.1.1.1, Probe type: icmp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:56 2014, No hardware timestamps
 Rtt: 449 usec
 Results over current test:
 Probes sent: 7, Probes received: 7, Loss percentage: 0
 Measurement: Round trip time
 Samples: 7, Minimum: 360 usec, Maximum: 449 usec, Average: 401 usec, Peak to peak: 89 usec, Stddev: 33 usec, Sum: 2810 usec
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 306 usec, Maximum: 454 usec, Average: 381 usec, Peak to peak: 148 usec, Stddev: 37 usec,
 Sum: 3805 usec
 Results over all tests:
 Probes sent: 117, Probes received: 117, Loss percentage: 0
 Measurement: Round trip time
 Samples: 117, Minimum: 214 usec, Maximum: 531 usec, Average: 357 usec, Peak to peak: 317 usec, Stddev: 72 usec,
 Sum: 41719 usec


lab@R2# run show services rpm active-servers 
 Protocol: TCP, Port: 50000

 Protocol: UDP, Port: 51000

Encapsulated Remote SPAN (ERSPAN)

There are three types of Switch Port Analyser (SPAN) supported on Cisco routers and switches:

Local SPAN: Mirrors traffic from one or more interface on the switch to one or more interfaces on the same switch.

Remote SPAN (RSPAN): An extension of SPAN called remote SPAN or RSPAN which allows to capture traffic and send it to a remote switch via a Layer 2 network.

Encapsulated Remote SPAN (ERSPAN): as the name indicates, ERSPAN encapsulates capture traffic in GRE and allows it to be transported to a remote port across a Layer 3 network.

ERSPAN is a Cisco proprietary feature and is available only to Catalyst 6500, 7600, Nexus, and ASR 1000 platforms to date. The ASR 1000 supports ERSPAN source (monitoring) only on Fast Ethernet, Gigabit Ethernet, and port-channel interfaces.

Firstly we will go through a typical scenario, in which traffic on port Gi1.23 of Router R2 is captured, and sent to interface Gi2 of R1 traffic using ERSPAN.

Topology

ERSPAN Topology

Configuration

ERSPAN Source Router

CSR2# 

monitor session 10 type erspan-source
 source interface GigabitEthernet1
 filter vlan 23    ! Specify Sub-interface
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 2.2.2.2
 no shutdown   !   Default is shutdown

ERSPAN Destination Router

CSR1#
 
monitor session 10 type erspan-destination
 destination interface GigabitEthernet2
 source
  erspan-id 100
  ip address 1.1.1.1
 no shutdown   !   Default is shutdown

Verification

CSR2#show monitor session all
Session 10
----------
Type                   : ERSPAN Source Session
Status                 : Admin Enabled
Source Ports           : 
    Both               : Gi1
Filter VLANs           : 23
Destination IP Address : 1.1.1.1
MTU                    : 1464
Destination ERSPAN ID  : 100
Origin IP Address      : 2.2.2.2


CSR1#show monitor session all
Session 10
----------
Type                   : ERSPAN Destination Session
Status                 : Admin Enabled
Destination Ports      : Gi2
Source IP Address      : 1.1.1.1
Source ERSPAN ID       : 100

CSR1#show interface gi2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          1         77          4        308
             Route cache          0          0          0          0
       Distributed cache         47       7745        112      31780
                   Total         48       7822        116      32088

Capture files:

ERSPAN transport traffic, encapsulated within a GRE tunnel, as seen on R1 interface Gi1.12
https://www.cloudshark.org/captures/19b7c6b1c70b

ERSPAN capture result – on R1 Gi2
https://www.cloudshark.org/captures/00c5e863ecfe

ERSPAN without the destination router

Since ERSPAN is a Cisco proprietary protocol supported on a limited number of platforms, one may ask if we can capture traffic and send it via GRE to a remote laptop without having a destination ERSPAN router. We might run into this situation if the destination router does not support ERSPAN, or the PC is not connected directly to a physical port of the ERSPAN destination router (e.g. via a LAN switch, or via an Wireless AP).

The answer is, yes we can do this without the ERSPAN destination router!

The ERSPAN destination router is not a critical requirement. GRE/ERSPAN protocol in this case is not equipped with a reliable transmission mechanism. Nor it has a mechanism to verify the status of the ERSPAN session destination, before sending the capture traffic. Unlike ERSPAN, in the general GRE tunnel interface configuration on IOS (similarly in Juniper JUNOS) we can enable the “keep-alive” function under the GRE tunnel interface, and routers at both ends of the tunnel can check the status of the other end, and can bring down the interface if the keep-alive is not received within a configurable period, and can bring the interface up once the keep-alive messages are received again. The ERSPAN implementation of GRE does not have this feature.

ERSPAN destination router is needed if we want the traffic send to the destination interface appear in the same format as the one captured from the source, i.e. without it being encapsulated in GRE/ERSPAN headers.

If the remote PC is reachable via an IP address (connected to the network via a LAN switch or Wireless AP) the ERSPAN source router can send encapsulated traffic directly to this IP address. The PC does not need to have an GRE tunnel nor ERSPAN session configured . PC can not run ERSPAN anyway, because it is a Cisco proprietary protocol, and there is no “ERSPAN client” software released for PC.

If the remote PC does not have a reachable IP address (quite typical usage case) but connect physically to a router interface, we can still force the ERSPAN traffic to the interface assigned to this PC, by implementing a static route and static ARP. In this example below, 1.1.1.1 is the destination ERSPAN address (configured on R2), and R1 does not support ERSPAN.

ERSPAN without Dest Router

Configuration

ERSPAN Source router (2.2.2.2)
CRS2#
! Configuration is unchanged from the previous case
monitor session 10 type erspan-source
 source interface GigabitEthernet1
 filter vlan 23    ! Specify Sub-interface
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 2.2.2.2
 no shutdown   !   Default is shutdown



CSR1#
! Destination router does not support ERSPAN. 
! The destination IP address 1.1.1.1 is now NOT a real IP "behind" the monitoring PC.

! Remove ERSPAN session
no monitor session 10

! Remove 1.1.1.1 from Loopback interface.
no interface Loopback0

! Configure a dummy "transit" IP address on Gi2 
! And add a static route for destination 1.1.1.1 to force ERSPAN traffic out this way.

interface GigabitEthernet2
 ip address 10.1.1.1 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 10.1.1.2 name Force_Traffic_Out_Gi2

! Note that we need static ARP for the dummy next hop IP. 
! Otherwise, router will keep ARPing, without sending the actual ERSPAN traffic out Gi2
 
arp 10.1.1.2 6400.f1e2.0112 ARPA

Capture file:

ERSPAN capture result – as seen on on R1 Gi2. Note that the captured traffic is now encapsulated within GRE/ERSPAN header, similar to the transit traffic captured on R1 Gi1.12 in the previous example.

https://www.cloudshark.org/captures/76ce4261df29

Local ERSPAN

In this example, we’d like to mirror traffic from interface Gi1 to Gi2 on a local router R1. As traffic is copied from one interface to other on the same router, we wont be able to capture the actual transport traffic encapsulated within GRE/ERSPAN.

Below is the configuration & verification steps.

CSR1#

monitor session 10 type erspan-source
 source interface GigabitEthernet1
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 1.1.1.1
 shutdown   !   Default
 
monitor session 20 type erspan-destination
 destination interface GigabitEthernet2
 source
  erspan-id 100
  ip address 1.1.1.1
 shutdown   !   Default
 

CSR1#! Before turning montor session ON
CSR1#
CSR1#
CSR1#show interfaces gigabitEthernet 1 stats 
GigabitEthernet1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache         17       1540         15       1268
                   Total         17       1540         15       1268
CSR1#show interfaces gigabitEthernet 2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache          0          0          0          0
                   Total          0          0          0          0
                   
                   
Note that there is no traffic sent to Gi2  


CSR1#
config t
monitor session 10
 no shutdown
monitor session 20
 no shutdown


CSR1#! After turning montor session ON


CSR1#show interfaces gigabitEthernet 1 stats 
GigabitEthernet1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache         48       4264         45       3782
                   Total         48       4264         45       3782
CSR1#show interfaces gigabitEthernet 2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache          0          0         14       1192
                   Total          0          0         14       1192

References

Configuring ERSPAN

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-conf-erspan.html#GUID-152D9875-169B-461F-A34B-ABAABD0C1FF8

Understanding SPAN, RSPAN, and ERSPAN

https://supportforums.cisco.com/document/139236/understanding-spanrspanand-erspan