[j-nsp] How does internal communication between vMX virtual control plane and virtual forwarding plane work?
m4rtntns at gmail.com
Wed Jun 6 07:15:28 EDT 2018
On Wed, Jun 6, 2018 at 11:17 AM, James Bensley <jwbensley at gmail.com> wrote:
> On 4 June 2018 at 13:46, Martin T <m4rtntns at gmail.com> wrote:
>> When I deploy a vMX using orchestration scripts, then I end up with
>> following virtualized topology:
>> Now when I execute "file copy root at 192.168.122.1:/tmp/1G_file
>> /dev/zero" in vMX, then I can see that traffic traverses
>> virbr0[ge-0.0.0-vmx1] <-> [ge-0/0/0]vcp-vmx1[em1] <->
>> [vcp-int-vmx1]br-int-vmx1[vfp-int-vmx1] <-> [int]vfp-vmx1. Am I
>> misunderstaning this? Or does it really work in a way that first the
>> VM running Junos receives the traffic, then forwards it to VM running
>> virtualized Trio and then the traffic is forwarded back to Junos VM?
> Have I missed something in relation to your topology/config; ge-0/0/0,
> is that meant to provide you with management access to the VCP or is
> it supposed to be a forwarding place interface? If the later,
> shouldn't it be connected to the VFP VM and not the VCP VM (assuming
> you are trying to access the control plane over an in-band/forwarding
> plane interface)?
> ge-0/0/0, is that meant to provide you with management access to the VCP or is it supposed to be a forwarding place interface?
Management access to the VCP(vcp-vmx1 on my drawing) is over fxp0.
ge-0/0/0 is a forwarding plane interface.
> shouldn't it be connected to the VFP VM and not the VCP VM
I don't know, but that's the way orchestration script deploys it.
Basically the only change I have done to the default vmx.conf YAML
file is removing entries for interfaces ge-0/0/1, ge-0/0/2 and
More information about the juniper-nsp