[j-nsp] vMX and SR-IOV, VFP xml dump

Chris lists+j-nsp at gbe0.com
Thu Aug 22 01:43:53 EDT 2019


Hi

On 21/08/2019 3:32 pm, adamv0025 at netconsultings.com wrote:
> Thank you, much appreciated.
> Out of curiosity what latency you get when pinging through the vMX please?

It's less than 1/10th of a millisecond (while routing roughly 3gbit of 
traffic and this via a GRE tunnel running over IPSEC terminated on the 
vMX), I haven't done more testing to get exact figures though as this is 
good enough for my needs.

I am actually curious though, why not use the vmx.sh script to 
start/stop it? I don't think JTAC will support more than basic 
troubleshooting with that configuration but I could be wrong.

The only thing that annoys me slightly with vmx.sh is the management 
interface on the host that gets used for OOB on the vFP/vRE loses it's 
IPv6 address when the IP's are moved to the bridge interface it creates. 
It's not a big deal as for the host management I use a different 
interface anyway and IPv6 continues to work fine.

If you are doing a new deployment I strongly recommend you jump to 
19.1R1 or higher. The reason for this is the Juniper supplied drivers 
for i40e (and ixgbe) are no longer required (actually they are 
deprecated). All releases before 19.1R1 I have had constant issues with 
the vFP crashing and the closest to a fix I got was a software package 
that would restart the vFPC automatically. When the crash occured it 
would show in the hosts kernel log file that a PF reset has occured. 
This happened across multiple Ubuntu and CentOS releases. After 
deploying 19.1R1 with the latest Intel supplied i40e and iavf 
(replacement for i40evf) drivers it has been stable for me.

Since deploying 19.1R1, on startup I create the VF's and mark them as 
trusted instead of letting the vmx.sh script handle it. Happy to supply 
the startup script I made if its helpful.



More information about the juniper-nsp mailing list