Ethernet Switching
Highlighted
Ethernet Switching

sflow issue observed with lower MTU - EX4300 virtual-chassis

a month ago

The next-hop interface towards collector is set to MTU 1280.

# run show interfaces ge-0/0/9 | grep mtu
Link-level type: Ethernet, MTU: 1280, LAN-PHY mode, Link-mode: Full-duplex,
Protocol inet, MTU: 1266

 

tcpdump on server:

# tcpdump -i ens160f0 -vv 'port 4739'
tcpdump: listening on ens160f0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:41:27.748069 IP (tos 0x0, ttl 255, id 65358, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1324 > 1232
11:41:27.748176 IP (tos 0x0, ttl 255, id 65359, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1260 > 1232
11:41:27.765084 IP (tos 0x0, ttl 255, id 65360, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1284 > 1232
11:41:27.766550 IP (tos 0x0, ttl 255, id 65361, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1252 > 1232
11:41:27.766609 IP (tos 0x0, ttl 255, id 65362, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1324 > 1232
11:41:27.847790 IP (tos 0x0, ttl 255, id 65363, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1324 > 1232

 

It appears the switch is trying to pack upto 1324 bytes of UDP payload and requires a minimum inet mtu of 1352. Interestingly there was no fragment after the first packet.

 

So after setting the mtu to 1366:

# run show interfaces ge-0/0/9 | grep mtu
Link-level type: Ethernet, MTU: 1366, LAN-PHY mode, Link-mode: Full-duplex,
Protocol inet, MTU: 1352

 

# tcpdump -i ens160f0 -vv 'port 4739'
tcpdump: listening on ens160f0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:42:42.444032 IP (tos 0x0, ttl 255, id 3395, offset 0, flags [none], proto UDP (17), length 1352)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1324
11:42:42.444269 IP (tos 0x0, ttl 255, id 3396, offset 0, flags [none], proto UDP (17), length 1352)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1324
11:42:42.444326 IP (tos 0x0, ttl 255, id 3397, offset 0, flags [none], proto UDP (17), length 1296)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1268
11:42:42.513998 IP (tos 0x0, ttl 255, id 3398, offset 0, flags [none], proto UDP (17), length 1348)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1320
11:42:42.514479 IP (tos 0x0, ttl 255, id 3399, offset 0, flags [none], proto UDP (17), length 1352)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1324
11:42:42.545967 IP (tos 0x0, ttl 255, id 3400, offset 0, flags [none], proto UDP (17), length 1352)
10.233.32.1.64865 > 192.192.1.1.4739: [udp sum ok] UDP, length 1324

 

Is the switch ignoring its outgoing interface's mtu? 

 

regards,

Krish

 

4 REPLIES 4
Highlighted
Ethernet Switching

Re: sflow issue observed with lower MTU - EX4300 virtual-chassis

a month ago

Hi kpkrish,

 

Could you please provide the o/p of the below commands for the switch in both cases ?

 

monitor traffic interface <output interface> extensive no-resolve

 

If this solves your problem, please consider to mark this post as "Accepted Solution".

Best Regards,

Mohamed

Highlighted
Ethernet Switching

Re: sflow issue observed with lower MTU - EX4300 virtual-chassis

[ Edited ]
a month ago

The switch is indeed fragmenting and sending the packets. Sorry I kept the 'port 4739' with tcpdump. So the switch is doing the right thing. Maybe the sflow collector is not handling it. 

 

# tcpdump -vv -i ens160f0 'udp'
tcpdump: listening on ens160f0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:22:43.968552 IP (tos 0x0, ttl 255, id 54872, offset 0, flags [+], proto UDP (17), length 1260)
10.233.32.1.64865 > 192.192.1.1.4739: UDP, bad length 1324 > 1232
12:22:43.968647 IP (tos 0x0, ttl 255, id 54872, offset 1240, flags [none], proto UDP (17), length 112)
10.233.32.1 > 192.192.1.1: udp

 

Is there an option to set max size of sflow packet sent from the switch to avoid fragmentation? 

Highlighted
Ethernet Switching

Re: sflow issue observed with lower MTU - EX4300 virtual-chassis

a month ago

Hi kpkrish,

 

I don`t think that is possible. Here is explanation of sflow and configuration example, I did not find a way to limit the packet size based on this.

 

https://www.juniper.net/documentation/en_US/junos/topics/concept/sflow-qfx-series-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/sflow-mx-series.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/sflow-ex-series.html

https://www.juniper.net/documentation/en_US/junos/topics/example/sflow-configuring-ex-series.html

 

If this solves your problem, please consider to mark this post as "Accepted Solution".

Best Regards,

Mohamed

 

 

Bes

Highlighted
Ethernet Switching

Re: sflow issue observed with lower MTU - EX4300 virtual-chassis

a month ago

Hi,

 

 

For QFX series, Regardless of the rate of traffic or the configured sampling interval, a datagram is sent whenever its size reaches the maximum Ethernet transmission unit (MTU) of 1500 bytes, or whenever a 250-ms timer expires, whichever occurs first. The timer ensures that a collector receives regularly sampled data.

 

https://www.juniper.net/documentation/en_US/junos/topics/concept/sflow-qfx-series-understanding.html

so sending sflow packet will be when 1500 bytes of flows and counters are packed or every 250ms , In case the traffic is really slow and the configured polling interval/sampling rate is really large, then the rate at which flow samples are generated might not fill up the max datagram size  in time.   you can try manipulate polling interval / sampling rate as delay in sending of samples might render them useless to the collector .

 

If this solves your problem, please mark this post as "Accepted Solution."

Regards,
A.A.
Feedback