Sure, I will try this and let you know. Thanks a lot.

Wei
________________________________
From: Stanislav Zaikin <zsta...@gmail.com>
Sent: Tuesday, November 30, 2021 2:51 PM
To: Wei Huang <wei.hu.hu...@oracle.com>
Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: [External] : Re: [vpp-dev] Recursive routing issue

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<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>").
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<https://urldefense.com/v3/__https://gerrit.fd.io/r/c/vpp/*/34621__;Kw!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4i8c2rntg$>

On Tue, 30 Nov 2021 at 17:54, Wei Huang 
<wei.hu.hu...@oracle.com<mailto: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<https://urldefense.com/v3/__http://192.168.21.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4ionavtkQ$>

I added two routes like this
vppctl ip route add 
192.168.21.0/24<https://urldefense.com/v3/__http://192.168.21.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4ionavtkQ$>
 via ipip0
vppctl ip route add 
192.168.21.0/24<https://urldefense.com/v3/__http://192.168.21.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4ionavtkQ$>
 via ipip1

Then I added a route like this:
vppctl ip route add 
192.168.200.0/24<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>
 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<https://urldefense.com/v3/__http://192.168.21.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4ionavtkQ$>
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<https://urldefense.com/v3/__http://192.168.21.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4ionavtkQ$>
 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<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>
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<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>
 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<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>
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<https://urldefense.com/v3/__http://192.168.200.0/24__;!!ACWV5N9M2RV99hQ!YHui6j9S6oROswNFE5HJLwpC4c7TgHZNpHN1WpdgBGWf1vxMSB7kix2Cy4hszlsaRg$>
 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 (#20566): https://lists.fd.io/g/vpp-dev/message/20566
Mute This Topic: https://lists.fd.io/mt/87411412/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to