Hi Neale,
Thanks for your reply.
I am adding a default route via 10.0.0.15 dev Ge0/4/0, a subnet route
10.0.0.0/24 via 10.0.0.15 dev Ge0/4/0 and a host route to the 10.0.0.15/32
on dev Ge0/4/0. No explicit arp entry is added. Without the specific
10.0.0.15/32 on dev Ge0/4/0 link the arp ipv4 response for 10.0.0.15 gets
dropped for the reason src subnet not local to interface. On the link down
of Ge0/4/0 all the routes specified above gets deleted. But on the other
link Ge0/3/0 we have similar routes, default route and subnet route via
10.0.0.14 and host route to 10.0.0.14/32 on dev Ge0/3/0.
As per the fib log the src API based path gets removed but the src adj
based one remains. Even if the interface is down the adjacency source entry
remains the cover seems to get updated. to 7 , which is on a different
interface ie Ge0/3/0 than that is in the adjacency is still on Ge0/4/0.
show ip fib 10.0.0.15
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ]
locks:[src:plugin-hi:2, src:DHCP:7, src:adjacency:5, src:default-route:1, ]
10.0.0.15/32 fib:0 index:8 locks:2
src:adjacency refs:1 entry-flags:attached,
src-flags:added,contributing,active, cover:7
path-list:[17] locks:2 uPRF-list:7 len:1 itfs:[3, ]
path:[18] pl-index:17 ip4 weight=1 pref=0 attached-nexthop:
10.0.0.15 GigabitEthernet0/4/0^M
[@0]: ipv4 via 10.0.0.15 GigabitEthernet0/4/0: mtu:9000
deaddead0005deaddead00010800
Extensions:
path:18
forwarding: UNRESOLVED
and cover fib entry 7 specified above is the following.
7@10.0.0.0/24
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:36
to:[1770:254632]]
[0] [@5]: ipv4 via 10.0.0.14 GigabitEthernet0/3/0: mtu:9000
deaddead0004deaddead00010800
When the interface is down is the corresponding fib entry sourced by the
adjacency expected to be deleted. ? Could you also explain a bit on the
adjacency source refinement?
Thanks
Rupesh
On Wed, Feb 3, 2021 at 2:40 PM Neale Ranns <ne...@graphiant.com> wrote:
> Hi Rupesh,
>
>
>
> 10.0.0.15 remains unresolved after link down because there remains an
> adjacency/ARP-entry for it on Ge0/4/0 – did you add a static one? It is
> unresolved because it fails the adjacency source refinement criteria.
> Packets to 10.0.0.15 are forwarded using the default route. This is
> expected behaviour.
>
>
>
> Your use of unnumbered is unconventional. You’d get a better experience if
> you used standard IP addressing. For example, add separate /31s on your
> gigEs, then another /32 on the loopbacks. Add routes to the peer’s
> loopbacks via your control plane agent. The tunnel endpoints should be the
> loopback addresses.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Rupesh
> Raghuvaran via lists.fd.io <rupesh.raghuvaran=gmail....@lists.fd.io>
> *Date: *Tuesday, 2 February 2021 at 17:08
> *To: *vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
> *Subject: *[vpp-dev] Fib entries as per show ip fib for prefix has
> forwarding UNRESOLVED though packet is forwarded.
>
>
>
> VPP is configured as router (R0) connects to two routers referred as R1
> and R2 , and there is direct link between R1 and R2 is connected.
>
>
>
> R0 has a loopback interface loop0 configured with 10.0.0.16/32 and
> 10.0.0.18/32 , interface Ge0/3/0 and Ge0/4/0 is unnumbered to loop0
>
> R0 Ge0/3/0 connects to R1
>
> R0 Ge0/4/0 connecte to R2
>
>
>
> R1 has a loopback interface with 10.0.0.14/32 and the R1-R0 interface
> is unnumbered to that interface.
>
> R2 has a loopback interface with 10.0.0.15/32 and the R2-R0 interface
> is unnumbered to that interface.
>
>
>
>
>
> R0 is configured with following routes
>
>
>
> 0.0.0.0/0 via 10.0.0.14
>
> 0.0.0.0/0 via 10.0.0.15
>
> 10.0.0.0/24 via 10.0.0.14
>
> 10.0.0.0/24 via 10.0.0.15
>
> 10.0.0.14/32 via Ge0/3/0
>
> 10.0.0.15/32 via Ge0/4/0
>
>
>
> with this configuration I am able to ping 10.0.0.15 and 10.0.0.14 on
> respective link.
>
>
>
> show ip fib 10.0.0.15
>
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ]
> locks:[src:plugin-hi:2, src:DHCP:7, src:adjacency:5, src:default-route:1, ]
>
> 10.0.0.15/32 fib:0 index:8 locks:3
>
> src:API refs:1 entry-flags:attached, src-flags:added,contributing,active,
>
> path-list:[12] locks:2 flags:shared, uPRF-list:14 len:1 itfs:[3, ]
>
> path:[12] pl-index:12 ip4 weight=1 pref=0 attached-nexthop:
> oper-flags:resolved, cfg-flags:attached,
>
> 10.0.0.15 GigabitEthernet0/4/0
>
> [@0]: ipv4 via 10.0.0.15 GigabitEthernet0/4/0: mtu:9000
> deaddead0005deaddead00010800
>
>
>
> src:adjacency refs:1 entry-flags:attached, src-flags:added, cover:-1
>
> path-list:[17] locks:1 uPRF-list:7 len:1 itfs:[3, ]
>
> path:[18] pl-index:17 ip4 weight=1 pref=0 attached-nexthop:
> oper-flags:resolved,
>
> 10.0.0.15 GigabitEthernet0/4/0^M
>
> [@0]: ipv4 via 10.0.0.15 GigabitEthernet0/4/0: mtu:9000
> deaddead0005deaddead00010800
>
> Extensions:
>
> path:18
>
> forwarding: unicast-ip4-chain
>
> [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:14
> to:[2020:207099]]
>
> [0] [@5]: ipv4 via 10.0.0.15 GigabitEthernet0/4/0: mtu:9000
> deaddead0005deaddead00010800
>
>
>
>
>
> On Link down of Ge0/4/0 the control plange agent on the link down event
> removes following routes
>
> ie corresponding to the one via the specific link set to down.
>
> 0.0.0.0/0 via 10.0.0.15
>
> 10.0.0.0/24 via 10.0.0.15
>
> 10.0.0.15/32 via Ge0/4/0
>
>
>
> When the Ge0/4/0 link is down fib entry for 10.0.0.15 has forwarding
> marked as UNRESOLVED.
>
>
>
> show ip fib 10.0.0.15
>
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ]
> locks:[src:plugin-hi:2, src:DHCP:7, src:adjacency:5, src:default-route:1, ]
>
> 10.0.0.15/32 fib:0 index:8 locks:2
>
> src:adjacency refs:1 entry-flags:attached,
> src-flags:added,contributing,active, cover:7
>
> path-list:[17] locks:2 uPRF-list:7 len:1 itfs:[3, ]
>
> path:[18] pl-index:17 ip4 weight=1 pref=0 attached-nexthop:
>
> 10.0.0.15 GigabitEthernet0/4/0
>
> [@0]: ipv4 via 10.0.0.15 GigabitEthernet0/4/0: mtu:9000
> deaddead0005deaddead00010800
>
> Extensions:
>
> path:18
>
> forwarding: UNRESOLVED
>
>
>
> Its found that the packets destined to 10.0.0.15 is send out via the
> Ge0/3/0 as expected even though it is marked unresolved.
>
> ie ping from R0 to R2 ip 10.0.0.15 via R1 when link from R0 to R2 is down
>
>
>
>
>
> 00:13:42:303487: ip4-input
>
> ICMP: 10.0.0.16 -> 10.0.0.15
>
> tos 0x00, ttl 64, length 84, checksum 0xbd3c
>
> fragment id 0x694e, flags DONT_FRAGMENT
>
> ICMP echo_request checksum 0xe43a
>
> 00:13:42:303492: ip4-lookup
>
> fib 0 dpo-idx 3 flow hash: 0x00000000
>
> ICMP: 10.0.0.16 -> 10.0.0.15
>
> tos 0x00, ttl 64, length 84, checksum 0xbd3c
>
> fragment id 0x694e, flags DONT_FRAGMENT
>
> ICMP echo_request checksum 0xe43a
>
> 00:13:42:303497: ip4-rewrite
>
> tx_sw_if_index 2 dpo-idx 3 : ipv4 via 10.0.0.14 GigabitEthernet0/3/0:
> mtu:9000 deaddead0004deaddead00010800 flow hash: 0x00000000
>
> 00000000:
> deaddead0004deaddead0001080045000054694e40003f01be3c0a0000100a00
>
> 00000020: 000f0800e43a0a4700504066196000000000ea940600000000001011
>
> 00:13:42:303500: GigabitEthernet0/3/0-output
>
> GigabitEthernet0/3/0
>
> IP4: de:ad:de:ad:00:01 -> de:ad:de:ad:00:04
>
> ICMP: 10.0.0.16 -> 10.0.0.15
>
> tos 0x00, ttl 63, length 84, checksum 0xbe3c
>
> fragment id 0x694e, flags DONT_FRAGMENT
>
> ICMP echo_request checksum 0xe43a
>
> 00:13:42:303503: GigabitEthernet0/3/0-tx
>
> GigabitEthernet0/3/0 tx queue 0
>
> buffer 0x18e07: current data -14, length 98, buffer-pool 0, ref-count 1,
> trace handle 0x28
>
> PKT MBUF: port 65535, nb_segs 1, pkt_len 98
>
> buf_len 2176, data_len 98, ol_flags 0x0, data_off 114, phys_addr
> 0x73a38240
>
> packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>
> IP4: de:ad:de:ad:00:01 -> de:ad:de:ad:00:04
>
> ICMP: 10.0.0.16 -> 10.0.0.15
>
> tos 0x00, ttl 63, length 84, checksum 0xbe3c
>
> fragment id 0x694e, flags DONT_FRAGMENT
>
> ICMP echo_request checksum 0xe43a
>
>
>
> But for any gre tunnels with l2 adj index which refers to 10.0.0.15 seems
> to have forwarding dpo-drop as drop.
>
> Why is the fib entry for 10.0.0.15 remains with forwarding unresolved ?
>
> I hope the configuration attempted is supported. Please find the related
> logs and various fib related cli outputs before and after.
>
> Thanks in Advance
> Rupesh
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18654): https://lists.fd.io/g/vpp-dev/message/18654
Mute This Topic: https://lists.fd.io/mt/80318226/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
