Knowledge Search


×
 

[EX] Exporting the sFlow-sampled Records via 'me0' or 'vme0' on EX switches

  [KB24460] Show Article Properties


Summary:
In the EX-series switch implementation, sFlow-sampled records will not be exported out of management interfaces (me0 or vme0) to avoid the possibility of overwhelming the CPU. In certain situations, the need to export sFlow data to a remote collector via the management network path still exists.

To accommodate this requirement, it is possible to use the virtual routing instance feature on the EX-series Ethernet switch and utilize one of the network ports as a dedicated management port for sFlow to be exported via the management network.
Symptoms:
  • In the lab network that is used in this example (refer to image 5 below), the ge-0/0/0 network port on the EX4200-1 device is used as a dedicated management interface, which is connected to the management network.

  • To isolate the ge-0/0/0 interface from other network interfaces on the switch, it is placed in a separate virtual routing instance, known as mgnt_net.

  • In this example, two sFlow collectors are sitting in the management network data center; whereas the third sFlow collector is connected to EX4200-1 device via the regular network port.

Topology:

Cause:

Solution:
The three sFlow collectors are configured under the sFlow protocol on the EX4200-1 device:

user@switch# show protocols
sflow {
    polling-interval 20;
    sample-rate 100;
    collector 1.0.0.10;
    collector 8.0.0.10;
    collector 7.0.0.10;
    interfaces ge-0/0/12.0;
}

The following configuration places ge-0/0/0 on the EX4200-switch into the separate mgnt_net virtual routing instance to isolate it from other network interfaces on the switch. Static routes are also configured for out-of-band management for the EX4200-1 switch:

user@switch# show routing-instances 
mgnt_net { 
    instance-type virtual-router; 
    interface ge-0/0/0.0; 
    routing-options { 
        static {
            route 0.0.0.0/0 next-hop 30.0.0.13; 
            route 1.0.0.10/32 next-hop 30.0.0.13; 
            route 8.0.0.10/32 next-hop 30.0.0.13; 
        }
    }
}

The routing table on the EX4200-1 switch displays the following information:

user@switch# run show route 
inet.0:7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.0.0.0/24 		   *[Direct/0] 23:23:22  
            > via ge-0/0/5.0
5.0.0.15/32 		   *[Local/0] 1d 03:20:14 
      Local via ge-0/0/5.0
6.0.0.0/24 		   *[Static/5] 1d 03:17:49 
            > to 20.0.0.16 via ge-0/0/12.0
7.0.0.0/24 		   *[Direct/0] 00:26:17 
    > via ge-0/0/7.0
7.0.0.15/32 		   *[Local/0] 00:26:17 
   	     Local via ge-0/0/7.0
mgnt_net.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 		   *[Static/5] 00:26:17 
     > to 30.0.0.13 via ge-0/0/0.0
1.0.0.10/32 		   *[Static/5] 00:26:17 
                           > to 30.0.0.13 via ge-0/0/0.0
8.0.0.10/32 		   *[Static/5] 00:26:17 
    > to 30.0.0.13 via ge-0/0/0.0
30.0.0.0/24 	           *[Direct/0] 00:26:17 
    > via ge-0/0/0.0
30.0.0.15/32 	           *[Local/0] 00:26:17 
      Local via ge-0/0/0.0

The sFlow agent on EX4200-1 needs the routing information in its default routing table to reach the sFlow collectors; so that it can export the sFlow data records to the collectors via the network interfaces. As shown above, EX4200-1 can reach the 7.0.0.10 collector, as this collector is connected to EX4200-1 via the ge-0/0/7 interface, which belongs to the default global routing instance. So, a route is pointing to 7.0.0.0/24 subnets in its default global routing table.

The other collectors, 8.0.0.10 and 1.0.0.10, are connected to EX4200-1 via the pseudo ge-0/0/0 management interface, which belongs to the separate mgnt_net virtual routing instance. So, EX4200-1 does not have routes to reach these two collectors in the default global routing table and the routes show up only in the mgnt_net virtual routing table.

For EX4200-1 to export sFlow data records to the 8.0.0.10 and 1.0.0.10 collectors via the pseudo ge-0/0/0 management interface, the routes (8.0.0.10/32 and 1.0.0.10/32) must be advertised from the mgnt_net virtual routing instance to the default global routing instance.

First, the policy statement must be set up, so that the sflow_collector policy statement will advertise two routes, 1.0.0.10/32 and 8.0.0.10/32, from the mgnt_net virtual routing instance to the default global routing instance:

user@switch# show policy-options 
    policy-statement sflow_collector { 
        term t1 { 
            from { 
                instance mgnt_net; 
                route-filter 1.0.0.10/32 exact; 
            } 
               then accept; 
        } 
        term t2 { 
            from { 
            instance mgnt_net; 
            route-filter 8.0.0.10/32 exact; 
            } 
               then accept; 
        } 
        term default { 
            then reject; 
         }                
  }

Next, the policy statement must be attached to the default global instance:

userswitch# show routing-options
instance-import sflow_collector;

A quick review of the routing table indicates that two more routes (1.0.0.10/32 and 8.0.0.10/32) have been redistributed from the mgnt_net routing instance and the outgoing interface is ge-0/0/0. The forwarding table also indicates that the next hop is 30.0.0.13:

user@switch# run show route 
inet.0:9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.10/32 	*[Static/5] 00:01:08 
> to 30.0.0.13 via ge-0/0/0.0
5.0.0.0/24 	*[Direct/0] 23:23:22 
> via ge-0/0/5.0
5.0.0.15/32 	*[Local/0] 1d 03:20:14 
Local via ge-0/0/5.0
6.0.0.0/24 	*[Static/5] 1d 03:17:49 
> to 20.0.0.16 via ge-0/0/12.0
7.0.0.0/24 	*[Direct/0] 00:26:17 
> via ge-0/0/7.0
7.0.0.15/32 	*[Local/0] 00:26:17
                Local via ge-0/0/7.0
8.0.0.10/32 	*[Static/5] 00:01:08 
> to 30.0.0.13 via ge-0/0/0.0
20.0.0.0/24 	*[Direct/0] 1d 03:23:07 
> via ge-0/0/12.0
20.0.0.15/32 	*[Local/0] 1d 03:23:07 
  Local via ge-0/0/12.0
mgnt_net.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 	*[Static/5] 00:26:17 
> to 30.0.0.13 via ge-0/0/0.0
1.0.0.10/32 	*[Static/5] 00:26:17 
> to 30.0.0.13 via ge-0/0/0.0
8.0.0.10/32 	*[Static/5] 00:26:17 
> to 30.0.0.13 via ge-0/0/0.0
30.0.0.0/24 	*[Direct/0] 00:26:17 
> via ge-0/0/0.0
30.0.0.15/32 	*[Local/0] 00:26:17 
Local via ge-0/0/0.0

user@switch # run show route forwarding-table destination 1.0.0.10 
Routing table: default.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
1.0.0.10/32 	user 	0 	30.0.0.13 	ucst 	1315 	7 	ge-0/0/0.0

Routing table: __juniper_private1__.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
default 	perm 	  0 			rjct 	116       1

Routing table: __juniper_private2__.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
default 	perm 	0 			rjct 	196 	1

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

Routing table: mgnt_net.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
1.0.0.10/32 	user 	 0 	30.0.0.13 	ucst 	1315 	  7   ge-0/0/0.0
user@switch # run show route forwarding-table destination 8.0.0.10 
Routing table: default.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
8.0.0.10/32 	user 	  0 	30.0.0.13 	ucst 	1315 	  7 	ge-0/0/0.0

Routing table: __juniper_private1__.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
default 	perm 	  0 			rjct 	 116 	  1

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

Routing table: mgnt_net.inet
Internet:
Destination 	Type 	RtRef 	Next hop 	Type 	Index 	NhRef 	Netif
8.0.0.10/32 	user 	  0 	30.0.0.13 	ucst 	1315 	   7   ge-0/0/0.0

After starting the traffic between EX4200-1 and EX4200-2, sFlow sampled records are being sent to all three collectors, which are actually in different virtual routing instances. The following image illustrates the captures on the 7.0.0.10 collector:



The following image illustrates the capturs on the 1.0.0.10 collector:



The following image illustrates the captures on the 8.0.0.10 collector:



A closer look at the sFlow sampled data records, which were exported to the 8.0.0.10 collector, indicate that the network traffic stream that enters the sFlow-enabled interface - ge-0/0/12 on EX4200-1 switch has the following patterns:

  • The stream’s IP source address is 6.0.0.10.

  • The stream’s IP destination address is 5.0.0.10.

  • The DSCP value of the packets in the stream is 0x28(EF).

  • The traffic is the FTP UDP traffic type with the 21 destination port.

Related Links: