Hello Neale, Thank you very much for the clarification. I’ll update VRF tests based on this information.
Regards, Jan From: Neale Ranns (nranns) Sent: Monday, February 27, 2017 16:49 To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.com>; vpp-dev@lists.fd.io Cc: csit-...@lists.fd.io Subject: Re: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hi Jan, The remaining prefixes are those added via ‘set int ip addr XXX’ These will not be removed by the FIB flush, they need to be removed via the ‘set int del ip addr …’. The same interface del should happen for v6 too. Otherwise VPP holds stale state (even though it may not be visible in the FIB), Regards, neale From: <csit-dev-boun...@lists.fd.io<mailto:csit-dev-boun...@lists.fd.io>> on behalf of "Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)" <jgel...@cisco.com<mailto:jgel...@cisco.com>> Date: Monday, 27 February 2017 at 15:38 To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>> Subject: Re: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hello vpp developers, Thanks to Neal’s patch the reset of IPv6 FIB works well. Unfortunately I still have doubts regarding reset of IPv4 FIB – there are still remaining some routes for unicast IPv4 addresses in the VRF after its reset (tested on ubuntu16.04 VM with vpp_lite). Could somebody of vpp developers let me know if the current behaviour is correct, please? Thanks, Jan IPv4 VRF1 before reset: ipv4-VRF:1, fib_index 1, flow hash: src dst sport dport proto 0.0.0.0/0 unicast-ip4-chain [@0]: dpo-load-balance: [index:15 buckets:1 uRPF:13 to:[0:0]] [0] [@0]: dpo-drop ip4 0.0.0.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:16 buckets:1 uRPF:14 to:[0:0]] [0] [@0]: dpo-drop ip4 172.16.1.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:22 buckets:1 uRPF:20 to:[0:0]] [0] [@2]: dpo-receive: 172.16.1.1 on pg0 172.16.1.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:21 buckets:1 uRPF:19 to:[0:0]] [0] [@4]: ipv4-glean: pg0 172.16.1.2/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:23 buckets:1 uRPF:21 to:[0:0]] [0] [@5]: ipv4 via 172.16.1.2 pg0: IP4: 02:fe:5e:14:60:d7 -> 02:01:00:00:ff:02 172.16.1.3/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:24 buckets:1 uRPF:22 to:[0:0]] [0] [@5]: ipv4 via 172.16.1.3 pg0: IP4: 02:fe:5e:14:60:d7 -> 02:01:00:00:ff:03 172.16.1.4/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:25 buckets:1 uRPF:23 to:[0:0]] [0] [@5]: ipv4 via 172.16.1.4 pg0: IP4: 02:fe:5e:14:60:d7 -> 02:01:00:00:ff:04 172.16.1.5/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:26 buckets:1 uRPF:24 to:[0:0]] [0] [@5]: ipv4 via 172.16.1.5 pg0: IP4: 02:fe:5e:14:60:d7 -> 02:01:00:00:ff:05 172.16.1.6/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:27 buckets:1 uRPF:25 to:[0:0]] [0] [@5]: ipv4 via 172.16.1.6 pg0: IP4: 02:fe:5e:14:60:d7 -> 02:01:00:00:ff:06 172.16.2.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:28 buckets:1 uRPF:26 to:[0:0]] [0] [@4]: ipv4-glean: pg1 172.16.2.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:29 buckets:1 uRPF:27 to:[0:0]] [0] [@2]: dpo-receive: 172.16.2.1 on pg1 172.16.2.2/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:30 buckets:1 uRPF:28 to:[0:0]] [0] [@5]: ipv4 via 172.16.2.2 pg1: IP4: 02:fe:f6:5c:24:b7 -> 02:02:00:00:ff:02 172.16.2.3/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:31 buckets:1 uRPF:29 to:[0:0]] [0] [@5]: ipv4 via 172.16.2.3 pg1: IP4: 02:fe:f6:5c:24:b7 -> 02:02:00:00:ff:03 172.16.2.4/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:32 buckets:1 uRPF:30 to:[0:0]] [0] [@5]: ipv4 via 172.16.2.4 pg1: IP4: 02:fe:f6:5c:24:b7 -> 02:02:00:00:ff:04 172.16.2.5/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:33 buckets:1 uRPF:31 to:[0:0]] [0] [@5]: ipv4 via 172.16.2.5 pg1: IP4: 02:fe:f6:5c:24:b7 -> 02:02:00:00:ff:05 172.16.2.6/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:34 buckets:1 uRPF:32 to:[0:0]] [0] [@5]: ipv4 via 172.16.2.6 pg1: IP4: 02:fe:f6:5c:24:b7 -> 02:02:00:00:ff:06 172.16.3.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:35 buckets:1 uRPF:33 to:[0:0]] [0] [@4]: ipv4-glean: pg2 172.16.3.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:36 buckets:1 uRPF:34 to:[0:0]] [0] [@2]: dpo-receive: 172.16.3.1 on pg2 172.16.3.2/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:37 buckets:1 uRPF:35 to:[0:0]] [0] [@5]: ipv4 via 172.16.3.2 pg2: IP4: 02:fe:98:fe:c8:77 -> 02:03:00:00:ff:02 172.16.3.3/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:38 buckets:1 uRPF:36 to:[0:0]] [0] [@5]: ipv4 via 172.16.3.3 pg2: IP4: 02:fe:98:fe:c8:77 -> 02:03:00:00:ff:03 172.16.3.4/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:39 buckets:1 uRPF:37 to:[0:0]] [0] [@5]: ipv4 via 172.16.3.4 pg2: IP4: 02:fe:98:fe:c8:77 -> 02:03:00:00:ff:04 172.16.3.5/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:40 buckets:1 uRPF:38 to:[0:0]] [0] [@5]: ipv4 via 172.16.3.5 pg2: IP4: 02:fe:98:fe:c8:77 -> 02:03:00:00:ff:05 172.16.3.6/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:41 buckets:1 uRPF:39 to:[0:0]] [0] [@5]: ipv4 via 172.16.3.6 pg2: IP4: 02:fe:98:fe:c8:77 -> 02:03:00:00:ff:06 224.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [index:18 buckets:1 uRPF:16 to:[0:0]] [0] [@0]: dpo-drop ip4 240.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [index:17 buckets:1 uRPF:15 to:[0:0]] [0] [@0]: dpo-drop ip4 255.255.255.255/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:19 buckets:1 uRPF:17 to:[0:0]] [0] [@0]: dpo-drop ip4 IPv4 VRF1 after reset: ipv4-VRF:1, fib_index 1, flow hash: src dst sport dport proto 0.0.0.0/0 unicast-ip4-chain [@0]: dpo-load-balance: [index:15 buckets:1 uRPF:13 to:[0:0]] [0] [@0]: dpo-drop ip4 0.0.0.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:16 buckets:1 uRPF:14 to:[0:0]] [0] [@0]: dpo-drop ip4 172.16.1.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:22 buckets:1 uRPF:20 to:[0:0]] [0] [@2]: dpo-receive: 172.16.1.1 on pg0 172.16.1.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:21 buckets:1 uRPF:19 to:[0:0]] [0] [@0]: dpo-drop ip4 172.16.2.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:28 buckets:1 uRPF:26 to:[0:0]] [0] [@0]: dpo-drop ip4 172.16.2.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:29 buckets:1 uRPF:27 to:[0:0]] [0] [@2]: dpo-receive: 172.16.2.1 on pg1 172.16.3.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [index:35 buckets:1 uRPF:33 to:[0:0]] [0] [@0]: dpo-drop ip4 172.16.3.1/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:36 buckets:1 uRPF:34 to:[0:0]] [0] [@2]: dpo-receive: 172.16.3.1 on pg2 224.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [index:18 buckets:1 uRPF:16 to:[0:0]] [0] [@0]: dpo-drop ip4 240.0.0.0/4 unicast-ip4-chain [@0]: dpo-load-balance: [index:17 buckets:1 uRPF:15 to:[0:0]] [0] [@0]: dpo-drop ip4 255.255.255.255/32 unicast-ip4-chain [@0]: dpo-load-balance: [index:19 buckets:1 uRPF:17 to:[0:0]] [0] [@0]: dpo-drop ip4 From: Neale Ranns (nranns) Sent: Monday, February 20, 2017 18:35 To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.com<mailto:jgel...@cisco.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io> Subject: Re: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hi Jan, Thanks for the test code. I have fixed the crash with: https://gerrit.fd.io/r/#/c/5438/ the tests don’t pass, but now because of those pesky IP6 ND packets. Regards, neale From: "Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)" <jgel...@cisco.com<mailto:jgel...@cisco.com>> Date: Monday, 20 February 2017 at 11:51 To: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>, "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>> Subject: RE: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hello Neale, It’s in review: https://gerrit.fd.io/r/#/c/4433/ Affected tests are skipped there at the moment. Regards, Jan From: Neale Ranns (nranns) Sent: Monday, February 20, 2017 12:49 To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.com<mailto:jgel...@cisco.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io> Subject: Re: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hi Jan, Can you please share the test code, then I can reproduce the problem and debug it. Maybe push as a draft to gerrit and add me as a reviewer. Thanks, neale From: "Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)" <jgel...@cisco.com<mailto:jgel...@cisco.com>> Date: Monday, 20 February 2017 at 09:41 To: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>, "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>> Subject: RE: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hello Neale, I tested it with vpp_lite built up from the master branch. I did rebase to the current head (my parent is now 90c55724b583434957cf83555a084770f2efdd7a) but still the same issue. Regards, Jan From: Neale Ranns (nranns) Sent: Friday, February 17, 2017 17:19 To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.com<mailto:jgel...@cisco.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io> Subject: Re: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hi Jan, What version of VPP are you testing? Thanks, neale From: <csit-dev-boun...@lists.fd.io<mailto:csit-dev-boun...@lists.fd.io>> on behalf of "Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)" <jgel...@cisco.com<mailto:jgel...@cisco.com>> Date: Friday, 17 February 2017 at 14:48 To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: "csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>" <csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>> Subject: [csit-dev] [vpp-dev] reset_fib API issue in case of IPv6 FIB Hello VPP dev team, Usage of reset_fib API command to reset IPv6 FIB leads to incorrect entry in the FIB and to crash of VPP. Could somebody have a look on Jira ticket https://jira.fd.io/browse/VPP-643, please? Thanks, Jan From make test log: 12:14:51,710 API: reset_fib ({'vrf_id': 1, 'is_ipv6': 1}) 12:14:51,712 IPv6 VRF ID 1 reset 12:14:51,712 CLI: show ip6 fib 12:14:51,714 show ip6 fib ipv6-VRF:0, fib_index 0, flow hash: src dst sport dport proto ::/0 unicast-ip6-chain [@0]: dpo-load-balance: [index:5 buckets:1 uRPF:5 to:[30:15175]] [0] [@0]: dpo-drop ip6 fd01:4::1/128 unicast-ip6-chain [@0]: dpo-load-balance: [index:44 buckets:1 uRPF:5 to:[0:0]] [0] [@0]: dpo-drop ip6 fd01:7::1/128 unicast-ip6-chain [@0]: dpo-load-balance: [index:71 buckets:1 uRPF:5 to:[0:0]] [0] [@0]: dpo-drop ip6 fd01:a::1/128 unicast-ip6-chain [@0]: dpo-load-balance: [index:98 buckets:1 uRPF:5 to:[0:0]] [0] [@0]: dpo-drop ip6 fe80::/10 unicast-ip6-chain [@0]: dpo-load-balance: [index:6 buckets:1 uRPF:6 to:[0:0]] [0] [@2]: dpo-receive ipv6-VRF:1, fib_index 1, flow hash: src dst sport dport proto ::/0 unicast-ip6-chain [@0]: dpo-load-balance: [index:15 buckets:1 uRPF:13 to:[0:0]] [0] [@0]: dpo-drop ip6 fd01:1::/64 UNRESOLVED fe80::/10 unicast-ip6-chain [@0]: dpo-load-balance: [index:16 buckets:1 uRPF:14 to:[0:0]] [0] [@2]: dpo-receive And later: 12:14:52,170 CLI: packet-generator enable 12:14:57,171 --- addError() TestIP6VrfMultiInst.test_ip6_vrf_02( IP6 VRF Multi-instance test 2 - delete 2 VRFs ) called, err is (<type 'exceptions.IOError'>, IOError(3, 'Waiting for reply timed out'), <traceback object at 0x2abab83db5a8>) 12:14:57,172 formatted exception is: Traceback (most recent call last): File "/usr/lib/python2.7/unittest/case.py", line 331, in run testMethod() File "/home/vpp/Documents/vpp/test/test_ip6_vrf_multi_instance.py", line 365, in test_ip6_vrf_02 self.run_verify_test() File "/home/vpp/Documents/vpp/test/test_ip6_vrf_multi_instance.py", line 322, in run_verify_test self.pg_start() File "/home/vpp/Documents/vpp/test/framework.py", line 398, in pg_start cls.vapi.cli('packet-generator enable') File "/home/vpp/Documents/vpp/test/vpp_papi_provider.py", line 169, in cli r = self.papi.cli_inband(length=len(cli), cmd=cli) File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 305, in <lambda> f = lambda **kwargs: (self._call_vpp(i, msgdef, multipart, **kwargs)) File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 547, in _call_vpp r = self.results_wait(context) File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 395, in results_wait raise IOError(3, 'Waiting for reply timed out') IOError: [Errno 3] Waiting for reply timed out 12:14:57,172 --- tearDown() for TestIP6VrfMultiInst.test_ip6_vrf_02( IP6 VRF Multi-instance test 2 - delete 2 VRFs ) called --- 12:14:57,172 CLI: show trace 12:14:57,172 VPP subprocess died unexpectedly with returncode -6 [unknown] 12:14:57,172 --- addError() TestIP6VrfMultiInst.test_ip6_vrf_02( IP6 VRF Multi-instance test 2 - delete 2 VRFs ) called, err is (<class 'hook.VppDiedError'>, VppDiedError('VPP subprocess died unexpectedly with returncode -6 [unknown]',), <traceback object at 0x2abab8427098>) 12:14:57,173 formatted exception is: Traceback (most recent call last): File "/usr/lib/python2.7/unittest/case.py", line 360, in run self.tearDown() File "/home/vpp/Documents/vpp/test/test_ip6_vrf_multi_instance.py", line 148, in tearDown super(TestIP6VrfMultiInst, self).tearDown() File "/home/vpp/Documents/vpp/test/framework.py", line 333, in tearDown self.logger.debug(self.vapi.cli("show trace")) File "/home/vpp/Documents/vpp/test/vpp_papi_provider.py", line 167, in cli self.hook.before_cli(cli) File "/home/vpp/Documents/vpp/test/hook.py", line 138, in before_cli self.poll_vpp() File "/home/vpp/Documents/vpp/test/hook.py", line 115, in poll_vpp raise VppDiedError(msg) VppDiedError: VPP subprocess died unexpectedly with returncode -6 [unknown]
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
