►
From YouTube: DASH Workgroup Community Meeting 20220309
Description
March 9, 2022 Community Call
A
Clear
so
I
hope
everyone
received
them
and
today
what
we're
going
to
have
is
keysight,
presenting
a
presentation
around
testing
and
maybe
a
short
demo.
So
that's
right
here
in
our
title
and
we
can
go
over
the
notes
later
after
that
we
might
take
about
30
minutes
for
that
or
more
depending
on
the
number
of
questions.
B
I'll
start
sharing
my
screen,
so
hello,
everybody,
so
my
name
is
mirjadan
and
I'm
presenting
today
on
behalf
of
keysight
and
although
I'm
presenting.
Basically,
this
is
the
work
of
the
whole
team
from
our
side,
and
I
think
we
have
today
here
alberto
and
I
think
we
have
also
vinod
and
also
chris
summers.
B
Now
this
pull
request
that
we
are
doing
today.
It's
actually
making
the
official
transition
from
stage
one
of
testing
where
everything
was
manual,
gui
based
to
trying
to
standardize
and
automate
the
test
cases,
although
we
are
still
using
proprietary
ways
of
configuring,
the
device
under
test
and
actually
the
configuration
it's
done
manually
and
we'll
talk
about
that.
B
B
Now,
if
we
go
over
the
files,
all
the
files
that
are
contributed
are
under
dash
test
folder
and,
like
I
said
we
have
in
docs,
we
have
the
testbed
section.
We
have
a
quick
overview.
Just
describe
the
testbed
and
then
we
go
into
the
physical
topology,
where
we
have
the
dash
appliance,
but
this
can
be
any
server
of
the
shelf
server
where
we
plug
two
or
more
cards.
B
I
put
on
the
diagram
here,
a
greyed
out
multiple
slots
and
possible
multiple
appliances,
as
this
evolve
further,
when
we'll
talk
about
high
availability
and
other
features
that
are
under
discussion
in
the
community.
So
I
kept
them
here
just
to
show
the
future
but
they're
greyed
out,
not
the
news,
and
we
have
the
test
equipment
where
we
can
do
both
stateless,
like
udp
traffic
and
full
stateful.
B
B
It's
not
mandatory
to
be
a
physical
server,
so
kind
of
these
are
the
components
that
are
making
the
testbed
and
it's
the
listing
here,
the
components
and
as
well
as
listing
some
recommended
performance,
I
would
say,
for
the
server
in
order
to
be
able
to
handle
all
the
vms
and
containers,
we
need
to
start
to
realize
the
test
case.
So
this
is
a
physical
topology.
B
If
we
go
back,
we
have
the
setup
environment
which
just
talks
about
installing
ubuntu
linux
on
the
server
it's
not
necessarily
to
be
ubuntu.
I
try
personal
like
centos
and
arch
linux.
Any
will
work,
but
the
example
here
is
ubuntu.
It
talks
about
what
prerequisites
to
install
installing
docker.
This
is
just
a
snippet
from
actual
docker
website
of
what
needs
to
be
installed
for
ubuntu,
installing
kvm
for
the
vm.
I
know
this
may
be
frowned
upon,
but
if
anybody
wants
to
enable
root
on
ubuntu
can
do
it
as
well.
B
Networking
setup
just
setting
up
a
bridge
for
all
the
vms
to
have
networking
access,
and
once
we
have
all
these
prerequisites
done,
we
can
start
cloning,
the
dash
repository
all
the
rest
of
the
environment.
We
have
and
I'll
show
it
next
in
a
container,
so
you
don't
have
to
keep
doing
manual
steps
just
build
the
container
that
is
provided
here
on
this
path
and
all
the
requirements
for
the
test.
Cases
and
the
environment
will
be
pulled
in
the
container.
B
B
So
this
is
the
configuration
part.
I
will
go
a
bit
over
the
container
part.
I
have
here
an
environment
that
I
set
up
inside.
We
have
a
docker
file
definition
and
python
requirements
for
the
test.
Cases-
and
all
we
have
to
do
is
just
to
build
the
container
same
commands
that
are
given
in
the
document
in
the
how
to
let
me
go
back
to
docs,
so
we
have
the
hardware
testbed
up
all
cabled.
B
We
have
the
setup
for
the
environment
all
up
and
set
up,
and
now
we
need
to
do
a
bit
of
configuration
to
map
the
ports.
Maybe
you
have
port
2?
Maybe
here
you
have
4.67,
so
we
are
providing
a
testbed
file
that
defines
the
ipo
of
the
server
the
management
id
of
the
server
of
the
chassis
of
the
devices
that
we
want
to
test
ips
of
the
vms
which
ports
are
connected.
B
So
what
we
see
here
in
the
diagram
we
will
have
in
the
testbed
file
here
also,
I
separated
any
credentials
in
a
credential
file
and
actually
I
created
as
a
template
and
the
actual
file
added
ignore.
So
nobody
makes
like
a
mistake
and
contributes
their
credentials,
and
now
they
are
out
there
in
the
world.
So
this
is
the
configuration
part
that
a
user
will
have
to
do
to
get
the
test
gets
going
once
the
configuration
is
done.
We
can
move
directly
into
running
the
test
cases
and
for
running
the
test
cases.
B
All
we
have
to
do
is
basically
start
the
container
and
after
that,
by
test
and
just
run
one
test
case
or
all
of
them
or
whatever
you
want.
If
we
want
to
simplify
a
bit,
I
can
make
a
shell
script
which
actually
hides
this
long
command
and
all
you
have
to
do
something
like
pi
test
dash
or
something
I
can
name
that
script
and
then
it
just
calls
the
cases
and
actually
everything
will
run
behind
in
the
container
without
the
user
having
to
give
all
these
long
paths.
B
We
are
contributing
initially
a
test
case
under
the
v-net
to
v-net
categories.
There
are
multiple
categories,
as
described
in
the
other
docs
and
for
the
v-net
v-net.
We
are
contributing
the
best-case
scenario.
So
this
is
the
kind
of
the
easiest
case
and
is
supposed
to
showcase
the
maximum
performance
that
could
be
obtained
by
the
device
and
this,
in
addition
with
the
test,
which
will
showcase
the
worst
case
in
a
worst
case
scenario,
that
will
be
contributing
a
subsequent
pull
request.
B
B
Kind
of
this
is
the
goal
of
the
test
case.
As
test
case
topology
goes
so
we
have
the
device
under
test
with
a
very
basic
acl
rule.
Where
allows
the
traffic
from
the
vm1
to
the
vm2
and
from
vm2
to
vm1,
and
it
denies
everything
else.
It
just
have
emulated
one
single
vm
with
one
single
ip
one,
vni,
one
vpc,
the
most
basic
thing
I
would
say
what
is
not
the
most
basic
thing
is
the
fact
that
we
have
bidirectional
traffic,
especially
since
udp.
B
I
could
make
it
international,
but
usually
tcp.
It's
you
send
and
you
receive
something
back,
so
it's
bidirectional
traffic.
So
I
believe
the
device
under
test
will
register
this
as
two
flows.
Not
only
one,
so
you
know
it
could
be
simplified
for,
but
I
think
two
flows,
it's
the
minimum
to
actually
make
sense,
and
with
this
in
mind,
while
you're
running
the
test
case,
you
will
get
a
final
result.
Something
like
this,
where
let's
say
it
will
try
a
million
packets
per
second,
it
will
get
no
loss,
no
frames
delta.
B
B
When
you
run
on
your
device,
you
will
get
your
own
numbers.
Basically,
you
will
get.
Let's
say
four
million.
You
see
some
loss.
This
is
not
good,
we'll
type
two
and
three
and
you'll
get
a
result
in
millions
of
packets
per
second.
We
can
tweak
it
and
go
into
hundred
cases
and
so
on.
We
can
took
the
resolution,
but
usually,
if
you
wanna
know
millions,
it's
good
enough,
I
would
say,
and
for
cps
test
we'll
have
also
sample
output.
B
I
guess
I
just
put
some
effective
numbers
very
low,
we'll
have
the
amount
of
connections
per
second,
the
connection
rate
and
we'll
see
the
http
transactions
connections
and,
of
course
we
don't
want
any
request
fail.
We
don't
want
transmits,
so
we
have
multiple
stats
that
we
are
looking
and
considering
when
we
are
saying
this
is
the
max
that
could
be
achieved
under
this
scenario.
B
B
B
Under
target-
and
this
will
be
the
device-
let's
call
it
part
number
or
company
that
contributes
it-
or
maybe
it's
a
psy
implementation,
or
maybe
the
site,
thrift
or
maybe
the
grpc
implementation.
So
here
we'll
be
able
to
add
drivers
which
will
configure
the
device
they
can
be
proprietary
or
they
can
be
open,
but
at
different
stages
of
the
project,
like
we
show
here
in
different
diagrams,
we
can
have
site
thrift
to
library.
Maybe
we
have
configuration
through
red
design,
radius
and
so
on,
as
we
are
moving
forward
to
the
final
goal.
B
B
So
the
data
set
with
the
ips,
the
acl
rules
and
everything
that
is
needed
will
be
passed
also
to
the
library
which
configures
the
device
in
order
to
configure
it
automatically.
At
this
moment,
at
this
phase,
where
we
are
today,
I
am
still
doing
this
configuration.
Let's
call
it
manually
and
actually
this
ties
into
the
kind
of
what's
next.
B
C
B
B
Yes,
it
will
not
be
device
specific,
but
as
we
move
through
the
phases,
it
can
be
configured
at
different
levels,
which
will
require
different,
let's
say
python,
libraries
or
implementations
to
we
can
go
directly
and
directly
to
cycles
and
configure
the
device
or
maybe
later
there
will
be
a
grpc
library
that
will
allow
us
to
connect
and
send
the
comments,
and
this
will
be
different.
Let's
call
it
drivers
that
can
configure
it
in
a
dash
way
in
the
end,
but
at
different
stages.
B
Also
having
this
flexibility
doesn't
doesn't
mean
it
needs
to
be
only
dash
whatever
it's
in
the
community.
Anybody
could
take
it
and
put
their
own
proprietary
library.
They
don't
need
to
contribute
here.
They
can
have
it
or
on
their
own
repository,
hidden
whatever
and
use
that
taking
the
data
from
the
test
and
configure
their
device,
while
the
dash
api
is
being
developed.
B
So
right
now,
the
first
demo
that
I
made
to
showcase
this
was
actually
with
a
sonic
duty.
So
I
took
a
sonic
duty.
I
configured
some
basic
acls
there
and
I
run
the
test
using
a
sonic
duty.
A
next
phase
will
be
to
take
an
actual
device
and
use
proprietary
apis
that
already
exist,
which
are
not
yet
dash
and
configure
the
device
and
run
the
test
which
we
are
able
to
do
that
today.
Basically,.
C
D
D
B
B
B
B
So
if
you
take-
and
you
go
to
the
steps
here-
and
you
actually
build
the
docker
sonic
management
this
container-
and
we
just
need
to
make
sure
that
if
we
go
the
sonic
management
route,
whatever
requirements,
they
have
for
pythons
that
they
import
when
they
build
the
sonic
management.
There
are
also
the
requirements
that
we
have
here,
so
we
need
kind
of
to
do
a
merge,
but
this
container
could
be
as
well
the
sonic
management
content,
so
everything
that
I'm
submitting
today
it's
in
that
direction.
B
So
test-based
setup
I
would
say
it's
as
identical
as
I
could
make
it
and
running
the
test
from
a
container.
It's
exactly
same
philosophy
as
sonic
management
has
and
these
containers
as
we
how
to
say,
go
towards
that
goal
of
running
sonic
on
the
car
and
doing
all
this
stuff.
We
can
go
that
way.
It's
already
I'll,
say.
A
B
E
D
Yeah
this
is
good,
but
isn't
that
you
know
if
we
go
in
the
direction,
then
you
know
whatever
changes
you
make
right.
So,
for
example,
you
know
the
container
requirements
which
we
should
be
merging
to
that
repo
right.
So
you
know
we
have
a
way
to
build
that
build
that
container.
We
we
need
to
incorporate
that
into
that,
because
I
think
the
you
know
what
I'm
trying
to
say
is
that
you
know
the
sonic.
D
The
current
the
sonic
management
test
framework
has
been
adopted
widely
right,
so
many
people
are
already
familiar
with
that
how
to
set
up
the
test,
but
they
just
follow
those
instructions
to
set
up
the
test.
Bed,
then
isn't
that
you
know
if
we,
if
we're
trying
to
line
this,
you
know
it's
a
dash,
a
special
case
for
that
test.
Better
set
up
in
that
you
know.
Whatever
changes
we
want
to
make
you
know
new,
for
example,
you
need
to
pull
new
packages,
then
we
can
add
to
the
existing
sonic
management
right
steps.
D
So
we
can.
We
can
incorporate
that.
So
you
know
people
just
follow
one
step
and
can
choose
what
attachment
they
want
to
build.
We
have
t0
t1
and
then,
in
this
case
we
can
choose
like
sd
appliance
test
pad.
They
can
build
the
you
know
the
the
same.
You
know
the
temp,
the
temp,
the
test
that
for
for
this
project,
and
also
you
know
not
just
not
just
the
the
the
test
framework
right.
D
You
know
whatever
steps
you
have
it's
actually
in
the
is
ansible
playbook,
so
people
don't
have
to
run
those
you
know
steps
manually,
they
can
just
run
the
playbook
and
then
set
up
the
servers
and
other
things
you
know
the
the
the
docker
so
so
those
deployed,
and
also
you
know
the
the
the
the
way
that
the
you
know.
The
sonic
management
also
manages
the
test
right.
So
all
these
tests
they
use
pi
tests
to
manage
those
tests.
I
think
yeah
you.
B
They
are
under
byte
test
and
they
have
the
same
format.
So
I
I
got
your
feedback
like
I
said
they're
in
the
same
line.
I
can
take
all
these
contributions
that
I
have
here
for
the
docker
container
and
requirements
and
see
what
is
needed
to
be
added
to
the
sonic
management
container,
and
I
can
make
a
pull
request
into
sonic
management.
D
B
These
changes,
but
now
in
order
to
move
all
the
test
cases
from
under
dash
repository
into
sonic
management
repository
it's
possible,
but
I
think
this
needs
to
be
a
dash
community
decision.
If
community
decides
this
way,
I
have
no
problem
moving
the
files
to
here.
Like
I
said,
we
already
made
it
with
this
assumption
that
we
want
to
be
sonic
management
yeah,
because
that
was
part
of
the
vision.
D
B
F
F
G
E
E
If
there's
any
other
questions,
gohan
thanks
for
the
input,
I
guess
my
comment
I
wanted
to
make
was:
one
of
the
things
we
want
to
do
is
make
it
easy
enough
for
vendors
to
start
testing
their
gpus
without
having
to
go
down
the
whole
sonic
management
learning
curve.
Also.
So
this
is
a
good
place
to
incubate.
This
and
and
merch
is
well
aware
of
the
sonic
management
testbed,
since
we
contribute
to
it
we'll
always
be
able
to
reconcile
and
merge
in.
We
will
keep.
D
That
I
I
disagree
with
that.
You
know
I
think,
under
my
mind
right.
So
you
know
this
dash
project
is
part
of
the
song.
It's
called
sonic
dash
so
and
to
the
to
the
previous
comment
that
wizard,
because
we
have
standardized
apis
right,
so
the
size
radius
api,
which
we
have
standardized,
whether
or
not
right.
So
you
know
it
is
sonic.
D
If
some
vendors
are
not
convinced
it
doesn't
prevent
to,
you
know
to
use
the
same
apis
right
so
and
the
sonic
management-
that's
that's,
does
manage
other
devices
as
well,
like
us,
our
cnc
abstraction
layer
to
hide
those
those.
You
know
those
device
specific
comments.
So
I
don't
think
that
would
be
a
concern
to
me
to
move
to
the
sonic
management
repo
for
this.
D
B
Like
I
said
that
as
a
testbed
configuration
file,
I'm
actually
inviting
anyone
to
actually
do
a
diff
between
the
one
I'm
submitting
and
the
one
that's
already
there
in
sonic
management
is
the
same
cases
wise.
We
are
following
the
same
model.
It's
it's
the
same
team
from
our
side
that
is
contributing
to
both
projects.
B
B
D
A
D
We,
you
know
those
tasks
that
should
you
know,
should
not
be
in
this
repo
right,
so
it
should
go
to
the
sonic
magi
repo.
You
know
this
repo
is
most
for
the
dash
architecture
designs.
I
mean
in
terms
of
code
right,
so
why
do
we
want
to
have
a
kind
of
two
branches
of
a
code
you
know
both
having
here
and
having
there?
You
should
maintain
one
branching,
because
you
know
having
a
tool
having
a
full
fork
of
you
know.
Another
project
I
see
maintenance
would
be
you
know,
double
the
maintenance.
A
D
Repo,
no
no,
but
I
think,
there's
a
stage
I
understand,
but
I
think
what
I
look
at
the
you
know:
the
the
steps,
the
environment.
You
know
the
way
to
build
the
docker.
I
think
it's
it's.
You
know
very
similar
to
the
sonic
management
report
right.
So
therefore,
why
not
unify
the
effort
in
the
beginning?
D
You
know
if
we,
I
think
the
concern
I
have.
If
we
do
the
fork
and
then
later,
because
it's
different
ripples,
it
will
diverge
rather
than
we
have
two.
We
have
to
maintain
two
efforts
here.
We
cannot
leverage
whatever
the
improvement
we
have
in
the
sonic
matching
report
right.
So
we
need
to
unify
the
efforts
here.
D
Oh,
that
we
can
we
we
we
can
give
you
right,
you
can
help
to.
You
know,
merge
your
things,
but
I
think
you
know
that
that's
that's
administrative
things.
I
think
it's
not
difficult
to
solve,
but
but
in
terms
of
you
get
because
we're
not
just
talking
about
design
here
right,
so
we're
talking
about
actually
running
code,
those
things
right
so
we
need
to.
We
need
to
be
unified.
You
know
the
community
efforts
here.
A
C
I
G
B
B
If
I
have
a
vendor
or
a
dash
api
to
configure
the
device,
we
can
tie
everything
together
with,
let's
say
one,
the
most
basic
thing,
but
we
can
at
least
do
it
end
to
end
and,
like
I
said,
the
next
pull
request
that
we're
intending
to
do
will
be
the
worst
case
scenario
like
a
basically
the
hero
test
and
from
what
I
tried
so
far.
To
be
honest,
there
will
be
multiple.
The
hero
test
will
not
be
only
one
test.
It
will
be
a
collection
of
data
sets.
B
B
B
But
I
would
really
actually
want
to
have
a
way
in
the
community
to
configure
the
devices,
because
that
will
give
me
some
confidence
in
the
data
sets.
I'm
building
that
I'm
not
writing
now
huge
files
that
later
may
prove
hey.
You
missed
this
flag
or
I
I
don't
know
what
I
could
miss
since
I
do
not
have
the
exact
api
in
front
of.
H
B
I
know
what
I
need
to
configure
on
the
test
side,
but
I
don't
I
don't
know
yet
all
the
details
and
what
to
configure
on
the
device
side-
and
you
know
it
may
create
a
lot
of
work
for
me
to
create
the
hero
test
and
then
miss
something
and
then
have
to
redo
it
all
over
at
scale.
So
it
will
be
really
good.
If
now,
while
we
have
this
the
most
basic
one,
we
can
get
that
component
for
configuring
also
the
device.
B
B
J
B
A
H
E
B
Describe,
let's
say
the
acl
policy
I
put
it
here,
but
you
know
there
may
be
other
flags
that
will
need
to
be
passed
here
and
once
I
get
the
api
for
configuring
acl
policies,
we
will
need
to
see
what
we
need
to
have
in
here.
Does
it
need
to
be
a
collection
of
them,
so
it
needs
to
be
a
higher
level
that
contains
multiple
policies
at
this
moment
is
just
a
list,
but
maybe
it
needs
some
attributes.
B
So
as
I
get
the
first
thing
that
and
configure
the
device,
I
can
better
structure
this
part,
and
then
we
have
the
part
which
is
the
whole
control
plane
and
everything
on
the
vxlan
or
we
have
the
vmip's,
the
vm
mac,
and
then
this
information
go
both
on
the
tester
side,
as
always
on
the
device
in
order
to
allow
the
traffic
to
flows
from
one
side.
Of
course,
if
there
are
loopback
interfaces
are
defined.
B
If
there
is
bgp
which
advertises
this
low
back
interface,
so
traffic
flows,
it
will
all
be
described
in
here,
like
I
said
this
information
right
now,
it's
mostly
proven
and
needed
by
the
testing
side.
As
soon
as
I
get
the
first-
let's
say,
official
user
in
the
community
thingy
that
configures
also
the
device,
I
will
be
able
to
prove
that
the
data
set
it's
able
to
be
sent
to
both
device
and
tester
and
it
will
satisfy
both
libraries
needs
to
configure
the
devices.
F
B
B
A
configuration
is
pushed
into
the
device,
and
at
this
moment
we
do
not
have
in
the
community
a
way
to
push
a
configuration
to
the
device,
and
once
we
have
that
the
data
set
that
it's
in
that
file
I'll
be
able
to
actually
show
you
guys
a
demo
and
be
like
hey
look.
If
you,
this
data
is
being
given
to
the
library
to
configure
the
car
and
to
the
tester.
The
test
will
just
work
at
this
moment.
I
can.
F
K
B
F
B
E
Yeah
one
thing
that's
not
said
explicitly
yet
is-
is
trying
to
define
this
structure
so
that
you
can
have
your
own
proprietary,
config
library,
in
your
own
development
environment,
without
necessarily
sharing
it,
but
we're
not
going
to
make
progress
towards
common
goal.
If
we
don't
start
like
integrating
this
together,.
F
B
E
K
So
yeah,
you
know
this,
this
might
be
might
be
too
early
to.
Perhaps
you
know
bring
this
one
up,
but
but
I'll
just
basically
say
these
things
so
that
we
can.
We
can
start,
you
know,
thinking
about
it
as
we
move
along,
and
that
is
to
say
that,
okay,
as
we
build
these,
you
know
test
environment
and
test
configuration
and
test
beds
and
test
setups
and
so
forth.
We
should
start
thinking
about
how
you're
going
to
stage
it
in.
K
Okay,
if,
if
test
cases
or
new
configurations
or
new
data
sets,
are
coming
in,
we
have
a
way
to
really
you
know,
seamlessly,
integrate
it
and
validate
them
in
the
back
end,
and-
and
you
know,
if
you
can
understand
this
part-
is
that
you
know
how
do
you
really
do
this
thing
as
part
of
like
what
ci
cd
is
built
in
the
cloud
environment?
So,
are
we
really
setting
up
all
of
those
things
with
that
thing
in
mind,
or
is
it
just
to
you
know
it's
just
too
rudimentary
right
now.
B
No,
it's
set
in
that
direction.
My
my
background
click
system,
test
team
for
our
products
and
actually
in
automation.
So
for
me
everything
needs
to
be
done
automated
and
nobody
touch
it,
and
actually
our
regressions
are
made
in
such
a
way.
Even
internally
bills
are
coming,
they
run,
they
publish
results,
you
get
emails,
it's
zero
touch
ideology,
at
least
for
me,
so
I
would
say
yes.
E
B
This
we
are
having
in
mind,
and
actually
I
if
there
is
interest
and
we
can
work
on
it,
I
can
contribute
a
test
bed
and
topology,
which
can
actually
be
run
fully
virtual.
If
you
want
to
test,
if
you
let's
say
you,
don't
have
the
hardware,
but
you
have
an
emulation
of
the
hardware
that
we
can
test
when
you
say
cloud
this
one,
I'm
saying
maybe
virtual,
we
can
run
that
as
well,
not
necessarily
on
hot
or
harder,
but.
K
B
K
Interest
for
for
officially
and
then
moving
forward,
also
because
it
just
you
know,
allows
us
to
really.
You
know
quickly,
do
a
turnaround
and
then
be
able
to
you
know
test
it.
Of
course
there
are,
there
are
hardware
related
tests.
You
won't
be
able
to
do,
but
at
least
you
can
do
probably
you
know
eighty
to
ninety
percent
of
test
cases
that
you
could
run
only
in
the
virtual
one
and
be
able
to
really
validate
that.
Indeed,
they
are
working
right.
So.
B
B
This
in
a
vm,
I'm
actually
using
double
virtualization
and
so
on,
the
nested
verticalization,
the
tester
part,
could
also
be
virtualized
this.
I
have
no
problem
actually
this
having
a
nick
here
and
all
this
being
vm
here
and
basically
sending
the
traffic
to
also
this
before
implementation
being
virtual
and
so
on.
B
L
Yeah
hi
this
is
amit.
I
had
a
specific
question
with
the
veena
to
wiener
test
that
you're
committing
today.
So
obviously
you
know
the
appliance
expects
vxlan
encapped
traffic
right
so
in
this
topology
and
setup
of
yours,
where
is
the
vxlan
encap
decal
being
done?
I
assume
it's
not
on
the
traffic
generator.
B
B
B
B
L
J
B
A
K
C
B
B
So
I
have
no
problem
putting
the
nic
here,
moving
all
these
svms
in
inside
the
server
and
having
the
traffic
exiting
through
the
nic
or
having
the
traffic
inside
to
I
know,
bridges,
virtual
switches
or
whatever
reaching
the
virtual
implementation
or
emulation
of
the
device
and
those
we.
We
have
virtual
solutions
as
well,
not
necessarily
from
keysight,
but
there
are
out
there
vm
images
that
will
achieve
this
goal,
such
as.
E
B
It
a
try
and
as
I
go
through
it
probably
you
know,
you're
gonna
find
the
gotchas
and
so
on,
like
even
these
devices.
Here
I
tried,
I
would
say
last
week,
to
put
here
sonic
switches
yeah
to
do
this
stuff,
and
I
consider
I
configure
a
cable.
I
got
to
a
point
where
I
saw
no,
it
doesn't
work
and
a
necessary
bit
of
feature
was
missing.
So.