Hi, thanks for your time to read this.
In function "ip4_lookup_multicast", the ethernet header is one byte
dislocation, which we get it throuch api "ethernet_buffer_get_header".
It's right in the unicast process like "ip4_lookup", is there something wrong
here?
Regards,
Ewan
yug...@telincn.c
Hi Dmitry,
IIUC you have two devices with identical IPv6 addresses, which we’ll call P and
Q, connected on two different interfaces. These interfaces are in different
VRFs so the addresses do not collide.
Now if we succeed in importing the discovered neighbours from VRF 0 to VRF 1,
these addr
John,
When a resource is reused from that freed pool, is it assigned the same IDs
(name and sw_if_index)?
To prevent any confusion and race conditions, it is better to assign them new
unique IDs (e.g. increment the vxlan_tunnel number in the name, use a unique ID
for any internal index such as
Hi,
do you know is there a way to exclude java file / code line from coverity
analysis,
by adding some code annotation?
In case it is not possible (or as a temporary workaround),
here is a list of directories, that need exclusion:
./build-vpp-native/vpp/vpp-api/java/jvpp-acl/target/
./build
Hi Matej,
The proper reuse of deleted VXLAN interface is to create a new one and put this
newly created interface (which is actually reusing an old one, thus using the
same sw_if_index) into a BD, etc. To bring a deleted interface state to up and
into a BD is not the proper way to reuse it and
Hi list,
I ended up with a weired VPP configuration:
there are two host interfaces in VPP: A and B. They both have identical MAC
and IP addresses. The IP address of B is on VRF 1.
Only interface A can get traffic from "real world", and it have one valid
entry in its neighbour table:
DBGvpp# sh ip
Reusing removed VXLAN interfaces sounds good.
However I put deleted vxlan_tunnel interface UP, then assign it to a bridge
domain and add pg interface to this bridge domain.
When I sent a traffic to pg interface VPP crashes with
build-root/install-vpp_lite-native/vpp/bin/vpp[10393]: received signa
Yes, this is the expected behavior. These deleted VXLAN tunnels in the down
state are placed in a pool so that it can be reused when more VXLAN tunnels are
created later. On creating a VXLAN tunnel, any of these deleted ones are reused
first, before new interfaces are created for the VXLAN tunne
> On 10 Jan 2017, at 11:54, Kinsella, Ray wrote:
>
>
> Seems like a welcome, logical, incremental step towards using DPDK binary
> packaging.
>
> Would it make sense to always first try to pull and install the binary
> package from the nexus server.
Yes, absolutely, we are fetching tons o
Seems like a welcome, logical, incremental step towards using DPDK
binary packaging.
Would it make sense to always first try to pull and install the binary
package from the nexus server.
Only building locally when either the download fails or when forced
to do so.
Then for those people who
Hi,
I'm trying delete VXLAN tunnel interfaces and after they are deleted they are
still in show interfaces but with down state.
vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 1
vat# exec create vxlan tunnel src 172.16.1.1 dst 172.16.1.2 vni 2
vat# exec create vxlan tunnel src 17
11 matches
Mail list logo
