search

open-switch / opx-nas-daemon

https://openswitch.net
1 stars 9 forks source link

opx-switch-shell "l3 def ip show" on openswitch V.2.3.x #27

Closed dj-s closed 6 years ago

dj-s commented 6 years ago

Hello,

this question/issue concerned Openswitch version 2.3.0 and 2.3.1 on DELL-S3048 plateform.

Since OPX version 2.3.x. opx-switch-shell "l3 def ip show" does not show my loopback IP address

in fact, with tcpdump, opx-2.3.x does not handle ping response.

A : my local IP : 10.32.0.4 B : remote IP : 10.32.0.1

there is no problem with version 2.2.0 and 2.2.1.

thank for your support

nchervela commented 6 years ago

@dj-s You will need to create a dummy interface for this.

root@OPX:~# ip link add name loop2 type dummy root@OPX:~# ifconfig loop2 10.10.1.1 netmask 255.255.255.0

root@OPX:~# opx-switch-shell "l3 defip show" Unit 0, Total Number of DEFIP entries: 16384

VRF Net addr Next Hop Mac INTF MODID PORT PRIO CLASS HIT VLAN

1024 0 10.10.1.1/32 00:00:00:00:00:00 100002 0 0 0 0 n 1536 0 10.10.1.0/24 00:00:00:00:00:00 100002 0 0 0 0 n

root@OPX:~# opx-show-version OS_NAME="OPX" OS_VERSION="2.3.1" PLATFORM="S6000-ON" ARCHITECTURE="x86_64" INTERNAL_BUILD_ID="OpenSwitch blueprint for Dell 1.0.0" BUILD_VERSION="2.3.1.0" BUILD_DATE="2018-05-15T20:25:40+0000" INSTALL_DATE="2018-06-01T01:24:29+0000" SYSTEM_UPTIME= 4 days, 10 hours, 56 minutes SYSTEM_STATE= running

jeff-yin commented 6 years ago

@dj-s Does that work for you? Let us know if the question can be closed.

nchervela commented 6 years ago

To elaborate on my previous comment, 127.x.y.z/8 interface is the kernel-internal loopback interface, and NPU is not made aware of this. Hence, you don't see it in "l3 defip show". As mentioned in the example in the previous comment, pls create a dummy interface, and assign an ip address that is outside of the 127.x.y.z range. You will then see it in "l3 defip show".

dj-s commented 6 years ago

@nchervela @jeff-yin

thank you for your responses and sorry for my delay. i test many things, and i still have problem to ping a remote ip with a loopback inteface . i will prepare some technical facts within 2 days.

dj-s commented 6 years ago

hi,

I followed your advice about dummy interface.

root@opx230:~#ip link add name dummy1 type dummy root@opx230:~#ifconfig dummy1 10.32.0.4/32 root@opx230:~#ifconfig dummy1 up

root@opx230:~# opx-switch-shell "l3 defip show Unit 0, Total Number of DEFIP entries: 16384 "# VRF Net addr Next Hop Mac INTF MODID PORT PRIO CLASS HIT VLAN" 2048 0 10.32.0.4/32 00:00:00:00:00:00 100002 0 0 0 0 n 2048 0 32.0.0.1/32 00:00:00:00:00:00 100002 0 0 0 0 n 2049 0 32.0.0.33/32 00:00:00:00:00:00 100002 0 0 0 0 n 2049 0 10.32.0.1/32 00:00:00:00:00:00 100004 0 0 0 0 n 3072 0 32.0.0.0/29 00:00:00:00:00:00 100002 0 0 0 0 n 3072 0 32.0.0.32/29 00:00:00:00:00:00 100002 0 0 0 0 n

and ping my remote switch

root@opx220-remote:~# tcpdump -i e101-001-0 proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on e101-001-0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:33:24.794801 IP 172.16.3.99 > 10.32.0.1: ICMP echo request, id 1857, seq 13, length 64
[..]

ping does'nt work because my source IP is "management IP eth0, 172.16.3.99" and not my "dummy ip 10.32.0.4".

Ping source with dummy1 does'nt work.

a solution with iptable.

root@opx230:~#iptables -t nat -A POSTROUTING -s 0.0.0.0/0 -d 10.32.0.0/16 -j SNAT --to-source 10.32.0.4

root@opx230:~#iptables -t nat -L [...] Chain POSTROUTING (policy ACCEPT) target prot opt source destination
SNAT all -- anywhere 10.32.0.0/16 to:10.32.0.4

iptables rule is OK

root@opx230:~# ping 10.32.0.1 PING 10.32.0.1 (10.32.0.1) 56(84) bytes of data. 64 bytes from 10.32.0.1: icmp_seq=1 ttl=64 time=0.499 ms 64 bytes from 10.32.0.1: icmp_seq=2 ttl=64 time=0.512 ms 64 bytes from 10.32.0.1: icmp_seq=3 ttl=64 time=0.491 ms 64 bytes from 10.32.0.1: icmp_seq=4 ttl=64 time=0.497 ms

remote switch

root@opx220-remote:~# tcpdump -i e101-001-0 proto ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on e101-001-0, link-type EN10MB (Ethernet), capture size 262144 bytes 16:48:37.218717 IP 10.32.0.4 > 10.32.0.1: ICMP echo request, id 1862, seq 1, length 64 16:48:37.218755 IP 10.32.0.1 > 10.32.0.4: ICMP echo reply, id 1862, seq 1, length 64

now ping is OK !

Questions :

is it possible to use a dummy Iface without iptables rules (NAT) ?

i have to test others things before post problems/questions about :

1) persistent dummy in /etc/network/interfaces.d 2) persistent iptables 3) `opx-switch-shell "l3 defip show"` result change with id 1024or2048 to 1025or2049 with my dummy

where can i post these futur questions ?

thanks a lot for your time !

nchervela commented 6 years ago

@dj-s can you please describe your setup, with a diagram if possible? Also, can you share details of "IP route show", and interface configurations.

nchervela commented 6 years ago

And "arp -n" output too, pls

dj-s commented 6 years ago

@nchervela ,

i prepared this plan yesterday without "arp -n" outpout.

opx-issue

nchervela commented 6 years ago

@dj-s thanks...will look into it.

nchervela commented 6 years ago

@dj-s We reproduced the issue, and here's how to get around it. 

1.  Instead of "dummy1" pls use "lo10" (or any other lo)
lo10      Link encap:Ethernet  HWaddr 4a:60:b2:c0:9b:e5
          inet addr:10.32.0.4  Bcast:0.0.0.0  Mask:255.255.255.255
          inet6 addr: fe80::4860:b2ff:fec0:9be5/64 Scope:Link
2. Specify source address in ping packets.  
ping -I 10.32.0.4 10.32.0.1
3.  The above 2 steps should resolve the issue
PING 10.32.0.1 (10.32.0.1) from 10.32.0.4 : 56(84) bytes of data.
64 bytes from 10.32.0.1: icmp_seq=1 ttl=64 time=0.819 ms
64 bytes from 10.32.0.1: icmp_seq=2 ttl=64 time=0.845 ms

18:12:18.177294 IP 10.32.0.4 > 10.32.0.1: ICMP echo request, id 8357, seq 6, length 64
18:12:18.177369 IP 10.32.0.1 > 10.32.0.4: ICMP echo reply, id 8357, seq 6, length 64

Similar issue was reported here https://github.com/FRRouting/frr/issues/361.

nchervela commented 6 years ago

@dj-s Have you tried the steps in the comment above? If no further questions, I'd like to close this ticket. Turns out that FRR needs the interface name to start with "lo", and ping needs the source address (and not just interface name) to be specified.

dj-s commented 6 years ago

@nchervela ,

thank you for your response, i can't test this workaround now, i'll do it as soon as possible.

ok, to close this issue

nchervela commented 6 years ago

@dj-s welcome!