Hi Wei, Interesting finding! Only the first resolved path was added when creating the rr entry (as you can see in the first output of "show ip fib 192.168.200.0/24"). I've prepared (probably) a fix [0] and tested it with the same setup (2 ipip tunnels). At least from cli perspective - it works now, I didn't test it with any traffic though. Can you give it a try?
[0] - https://gerrit.fd.io/r/c/vpp/+/34621 On Tue, 30 Nov 2021 at 17:54, Wei Huang <wei.hu.hu...@oracle.com> wrote: > I have an issue with recursive routing and like to get some advice on how > to fix this. > > On my vpp node, I have two interfaces ipip0, ipip1, both can reach > 192.168.21.0/24 > > I added two routes like this > vppctl ip route add 192.168.21.0/24 via ipip0 > vppctl ip route add 192.168.21.0/24 via ipip1 > > Then I added a route like this: > vppctl ip route add 192.168.200.0/24 via 192.168.21.2 > > I try to ping 192.168.21.2, 192.168.200.20, both works fine, traffic goes > through ipip0. > > vpp#show ip fib 192.168.21.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.21.0/24 fib:0 index:29 locks:2 > CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, > path-list:[39] locks:2 flags:shared, uPRF-list:38 len:2 itfs:[4, 5, ] > path:[48] pl-index:39 ip4 weight=1 pref=0 attached: > oper-flags:resolved, > ipip0 > path:[49] pl-index:39 ip4 weight=1 pref=0 attached: > oper-flags:resolved, > ipip1 > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:32 buckets:2 uRPF:38 to:[5:443]] > [0] [@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 flags:[fixup-ip4o4 > ] 45000000000000004004f69dc0a80106c0a80206 > stacked-on entry:30: > [@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 > to:[0:0] via:[4965:724564]] > [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:6 > flags:[] fa163fdd32d9fa163f30992d0800 > [1] [@6]: ipv4 via 0.0.0.0 ipip1: mtu:9000 next:10 flags:[fixup-ip4o4 > ] 45000000000000004004db9dc0a80a06c0a81406 > stacked-on entry:31: > [@2]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:20 > to:[0:0] via:[292:31108]] > [0] [@5]: ipv4 via 192.168.10.1 tn-eth1: mtu:9000 next:7 > flags:[] fa163f3186d0fa163f93d4ea0800 > vpp# show ip fib 192.168.200.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.200.0/24 fib:0 index:33 locks:2 > API refs:1 src-flags:added,contributing,active, > path-list:[40] locks:4 flags:shared, uPRF-list:40 len:1 itfs:[4, ] > path:[50] pl-index:40 ip4 weight=1 pref=0 recursive: > oper-flags:resolved, > via 192.168.21.2 in fib:0 via-fib:34 via-dpo:[dpo-load-balance:35] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:36 buckets:1 uRPF:40 > to:[4250:357000]] > [0] [@12]: dpo-load-balance: [proto:ip4 index:35 buckets:1 uRPF:39 > to:[142:8733] via:[4250:357000]] > [0] [@6]: ipv4 via 0.0.0.0 ipip0: mtu:9000 next:10 > flags:[fixup-ip4o4 ] 45000000000000004004f69dc0a80106c0a80206 > stacked-on entry:30: > [@2]: dpo-load-balance: [proto:ip4 index:13 buckets:1 > uRPF:12 to:[0:0] via:[4975:726084]] > [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:6 > flags:[] fa163fdd32d9fa163f30992d0800 > > Then I take down ipip0, if I ping 192.168.21.2, it works, traffic goes > through ipip1, but for 192.168.200.20, it doesn't. > > vpp# show ip fib 192.168.200.0/24 > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[adjacency:1, recursive-resolution:4, > default-route:1, ] > 192.168.200.0/24 fib:0 index:33 locks:2 > API refs:1 src-flags:added,contributing,active, > path-list:[40] locks:4 flags:shared, uPRF-list:39 len:1 itfs:[4, ] > path:[50] pl-index:40 ip4 weight=1 pref=0 recursive: > via 192.168.21.2 in fib:0 via-fib:34 via-dpo:[dpo-load-balance:35] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:36 buckets:1 uRPF:39 > to:[4336:364224]] > [0] [@0]: dpo-drop ip4 > > Is there anyway to let the recursive route knows to use the ipip1 when > ipip0 is down? > > Thanks in advance, > > Wei > > > > -- Best regards Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20565): https://lists.fd.io/g/vpp-dev/message/20565 Mute This Topic: https://lists.fd.io/mt/87406938/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
