You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Trying to ping the bridge IP from the target was not working, I could not see anything with tcpdump in the proxy. But pinging the target from the proxy was working. While it pinging the target from the proxy, I tried again pinging the proxy from the target and it worked. I then stopped all pings, and wait 5 seconds, tried again to ping the bridge IP from the target, and it was not working.
Arp from target to bridge IP works fine, even if ping is not working.
Ping from target to the peer interface in the proxy works.
Ping from the target to another target works.
The problem might be related to the vpp forwarder.
To Reproduce
Run these e2e several times: #318
First e2e run: 968970349
Second e2e run: 267521934
Specific test order
new-attractor-nsm-vlan -> open-second-stream-second-conduit
Expected behavior
Target should be able to ping the bridge IP and should get its nsm interface removed when disconnecting a conduit (#344)
Context
Kernel: 5.15.0
Kubernetes: 1.26.0
Network Service Mesh: v1.7.1 (previous version might have the same problem)
Meridio: v1.0.1
Logs
Target arp table:
? (10.244.1.1) at d6:80:7e:0c:11:11 [ether] on eth0
? (172.16.0.1) at 02:fe:84:8c:f1:46 [ether] on nsm-0
Target interface:
3: nsm-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 1000
link/ether 02:fe:26:3c:c8:2c brd ff:ff:ff:ff:ff:ff
inet 172.16.0.6/24 brd 172.16.0.255 scope global nsm-0
valid_lft forever preferred_lft forever
inet 20.0.0.1/32 scope global nsm-0
valid_lft forever preferred_lft forever
inet6 2000::1/128 scope global nodad
valid_lft forever preferred_lft forever
inet6 fd00::6/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::fe:8aff:fee3:1b16/64 scope link
valid_lft forever preferred_lft forever
Proxy arp table:
? (172.16.0.6) at 02:fe:26:3c:c8:2c [ether] on bridge0
? (10.244.1.1) at 7e:9e:d4:c6:6c:7a [ether] on eth0
Proxy interface:
3: bridge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1446 qdisc noqueue state UP group default
link/ether 02:fe:84:8c:f1:46 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global bridge0
valid_lft forever preferred_lft forever
inet6 fd00::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::2444:c6ff:fef5:153b/64 scope link
valid_lft forever preferred_lft forever
9: proxy.cond-9928: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master bridge0 state UNKNOWN group default qlen 1000
link/ether 02:fe:8a:5c:e8:08 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.7/24 brd 172.16.0.255 scope global proxy.cond-9928
valid_lft forever preferred_lft forever
inet6 fd00::7/64 scope global nodad
valid_lft forever preferred_lft forever
inet6 fe80::fe:8aff:fe5c:e808/64 scope link
valid_lft forever preferred_lft forever
Describe the bug
Trying to ping the bridge IP from the target was not working, I could not see anything with tcpdump in the proxy. But pinging the target from the proxy was working. While it pinging the target from the proxy, I tried again pinging the proxy from the target and it worked. I then stopped all pings, and wait 5 seconds, tried again to ping the bridge IP from the target, and it was not working.
Arp from target to bridge IP works fine, even if ping is not working.
Ping from target to the peer interface in the proxy works.
Ping from the target to another target works.
The problem might be related to the vpp forwarder.
To Reproduce
Run these e2e several times: #318
First e2e run: 968970349
Second e2e run: 267521934
Specific test order
new-attractor-nsm-vlan -> open-second-stream-second-conduit
Expected behavior
Target should be able to ping the bridge IP and should get its nsm interface removed when disconnecting a conduit (#344)
Context
Logs
Target arp table:
Target interface:
Proxy arp table:
Proxy interface:
vppctl show interface addr:
vppctl show mode:
TAP interface on the proxy side:
TAP interface on the target side:
The text was updated successfully, but these errors were encountered: