IOSv creates a routing loop on pinging from global RT to a link on a VRF

[somsinha]

Hi Team,

My topology is:

My config has:

• R1 and R2 are connected via 192.168.0.0/30 with .1 on R1(Gi0/0) and .2 on R2 (Gi0/0).
• They also each have a loopback 1.1.1.1 on R1 and 2.2.2.2 on R2.
• R2 has a return route to 1.1.1.1 via 192.168.0.1
• R1 has Gi0/0 on a vrf "TRANS" on which it connects to R2.
• R1 has lo0 with ip 1.1.1.1 in the global routing table.
• R1 also has the following routes and PBR configured:

r1#sh run | i ip route
 no ip route-cache cef
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 192.168.0.2 name DEF
ip route vrf TRANS 0.0.0.0 0.0.0.0 192.168.0.2 name DEF_VRF

r1#sh ip policy
Interface Route map
Gi0/0 RM_LAN
r1#
r1#sh route-map RM_LAN
route-map RM_LAN, permit, sequence 10
Match clauses:
ip address (access-lists): LAN_RTN
Set clauses:
global
Policy routing matches: 635 packets, 72390 bytes
r1#
r1#sh ip access-lists LAN_RTN
Extended IP access list LAN_RTN
10 permit ip any host 1.1.1.1 (635 matches)
20 permit icmp any host 1.1.1.1

• On pinging 2.2.2.2 from 1.1.1.1, not only do I get no response, but R1 sends back the packet destined for 1.1.1.1 back to 2.2.2.2 (matching default route, probably).
• The expectation is the packet should go to R2 (s=1.1.1.1, d=2.2.2.2) and the reply should come back to R1, where PBR should cause it to return to lo0 on R1.

I need to understand why this isn't working and how to fix this. A similar config works on IOS-XE (CSR1Kv image on CML2).

Full Config

R1: 

  ip vrf TRANS
   description Transport
   rd 1:1
  !
  interface Loopback0
   description to
   ip address 1.1.1.1 255.255.255.255
  !
  interface GigabitEthernet0/0
   description to GigabitEthernet0/0.R2
   ip vrf forwarding TRANS
   ip address 192.168.0.1 255.255.255.252
   no ip route-cache cef
   ip policy route-map RM_LAN
   duplex auto
   speed auto
   media-type rj45
   no mop enabled
   no mop sysid
  !
  ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 192.168.0.2 name DEF
  ip route vrf TRANS 0.0.0.0 0.0.0.0 192.168.0.2 name DEF_VRF
  !
  ip access-list extended LAN_RTN
   permit ip any host 1.1.1.1
   permit icmp any host 1.1.1.1
  !
  ipv6 ioam timestamp
  !
  route-map RM_LAN permit 10
   match ip address LAN_RTN
   set global
  !

 R2 has the config:

r2#sh ip route | b ^Gate
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 192.168.0.1
      2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback0
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, GigabitEthernet0/0
L        192.168.0.2/32 is directly connected, GigabitEthernet0/0

r2#sh run int Gi0/0
Building configuration...

Current configuration : 184 bytes
!
interface GigabitEthernet0/0
 description to GigabitEthernet1.R1
 ip address 192.168.0.2 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
 no mop enabled
 no mop sysid
end

r2#sh run int lo0
Building configuration...

Current configuration : 79 bytes
!
interface Loopback0
 description to
 ip address 2.2.2.2 255.255.255.255
end

Both routers run on IOSv in CML2:

r1#sh ver
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M2, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2020 by Cisco Systems, Inc.
Compiled Tue 28-Jul-20 07:09 by prod_rel_team


ROM: Bootstrap program is IOSv

r1 uptime is 5 hours, 13 minutes
System returned to ROM by reload
System image file is "flash0:/vios-adventerprisek9-m"
Last reload reason: Unknown reason

 I'm also attaching the Lab file (YAML).

[Harold Ritter]

Hi @somsinha ,

This is normal behavior, as packets received via the VRF interface will be looked up in the VRF routing table. The destination (1.1.1.1) does not exist in the VRF TRANS and the best match in the VRF routing table is the default route going back to r2, hence the loop.

Moreover, even if you had an entry in the VRF TRANS for 1.1.1.1/32 (let's say another loopback interface in the VRF), this would still not work as you can't ping from the global and receive the ping response via the VRF or vice versa. If ping is from the global, the response needs to be received from global. If ping is from a given VRF, the response needs to be received from the same VRF.

Regards,

[somsinha]

Hi @Harold Ritter ,

That's why I'm putting in a static route in Global to go via vrf TRANS, and a PBR in the WAN interface, to match traffic for the loopback in the global RT and route to it. Shouldn't this work?

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 192.168.0.2 name DEF
ip route vrf TRANS 0.0.0.0 0.0.0.0 192.168.0.2 name DEF_VRF
!

r1#sh route-map RM_LAN
route-map RM_LAN, permit, sequence 10
 Match clauses:
  ip address (access-lists): LAN_RTN
 Set clauses:
  global
 Policy routing matches: 635 packets, 72390 bytes
r1#
r1#sh ip access-lists LAN_RTN
 Extended IP access list LAN_RTN
 10 permit ip any host 1.1.1.1 (635 matches)
 20 permit icmp any host 1.1.1.1

Weirdly enough, this works in IOS-XE (CSR1Kv) but not IOSv.

[Harold Ritter · Accepted solution]

Hi @somsinha ,

Sorry I had missed the PBR policy. It looks like it is supported in IOS, but it might depend on the platform as such. Unfortunately, it does not look like it works in IOSv.

Regards,

[networkinblood]

Hi Sir ,  so finally  we can conclude the configuration  part is good enough to ping each other ips ...it's issue with ios image file / ios platform  .

[Harold Ritter · Accepted solution]

Yes, in the above scenario, if you were to replace the IOSv by a CSR1000v for instance, it would work as expected.

Regards,