How about if you issue the command no validate-update-source?
That should fix your issue.
When a router running Routing Information Protocol (RIP) receives an update from a neighboring router, it checks whether the source of the update belongs to the same network or sub-network as the receiving interface. If they are the same, the routes are accepted for installing into the routing table. Otherwise, the update is dropped.
This situation is more common in dial-up environments when the ip unnumbered command is issued on one end and ip address negotiated command is issued on the other end, which can result in different subnet masks, although the addresses are actually assigned from the same subnet. This can also occur when connecting across a firewall which does not participate in routing but transparently forwards the updates between the routers connected to its various interfaces belonging to different subnets. This can also occur if RIP is used in Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environments over multiple Generic Routing Encapsulation (GRE) tunnels belonging to different Virtual Routing and Forwarding (VRF) tables on the router, and the same addresses are used as tunnel endpoints for the different tunnels.
If you issue the debug ip rip command, the error message starting with the text RIP: ignored v2 update from bad source or RIP: ignored v1 update from bad source is not displayed depending on the RIP version being used. This indicates that the source of the update is not on the same subnet as the receiving interface.
To resolve this problem, issue the no validate-update-source command under router configuration mode of RIP, which stops validating the source address and accepts the updates. Make sure that you issue this command with caution since it may hide a real problem if the IP addresses on the routers are misconfigured. When using RIP over GRE tunnels with VRFs in an MPLS VPN environment, use unique endpoints as tunnel source and tunnel destination for different GRE tunnels.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...