0

When I built the EVPN VxLAN simulation environment in GNS3, I found that the learned overlay routing entries and underlay routing entries are as follows for SW-1:

Test TOPO

SW-1# show ip route 
Codes:  K - kernel route, C - connected, S - static, B - BGP, O - OSPF
        > - selected route, * - FIB route, q - queued route, r - rejected route, # - not installed in hardware
       Destination                  Gateway                                                Dist/Metric   Uptime      
-------------------------------------------------------------------------------------------------------------------
 C>*   1.1.1.1/32                   Direct                        Loopback0                0/0           00:10:24    
 B>*   2.2.2.2/32                   via 10.1.0.5                  Ethernet8                200/0         00:10:01    
 C>*   10.1.0.4/31                  Direct                        Ethernet8                0/0           00:10:14    
SW-1# 
SW-1# show ip route vrf Vrf01
Codes:  K - kernel route, C - connected, S - static, B - BGP, O - OSPF
        > - selected route, * - FIB route, q - queued route, r - rejected route, # - not installed in hardware
       Destination                  Gateway                                                Dist/Metric   Uptime      
-------------------------------------------------------------------------------------------------------------------
 C>*   192.168.1.0/24               Direct                        Vlan10                   0/0           00:10:05    
 B>*   192.168.2.0/24               via 2.2.2.2                   Vlan30                   200/0         00:10:01

So can routes between different VRFs be shared?(192.168.2.0/24 -> 2.2.2.2/32)But what I know is that the routing entries for VRF are independent and can not be shared between different VRFs.

Is recursive routing lookup across VRFs legal in this case and how to explain it?

Yongxin Cao
  • 1
  • 1

1 Answers1

0

No, VRFs, by definition, are independent, so recursive look ups between them should not possible.

Andrew
  • 1
  • 4
  • 19
  • (nit: 192.168.1.2.0 is not a valid prefix--please edit & fix). Did you show the whole table (I do not see the return prompt)? From what is shown, 192.168.2.0/24 cannot reach 192.168.2.0/24 in Vrf01. Post the whole table and the successful ping, and I'll say it is a bug. What vendor is this? – Andrew Dec 09 '22 at 14:41
  • (nit: 192.168.1.2.0 is not a valid prefix--please edit & fix) >> sorry, I can't find the edit button for it, only "delete" appears. These are the whole tables(default and VRF01). my device is not real, it is virtal machine running on GNS3, which is SONiC enterprise version from broadcom – Yongxin Cao Dec 12 '22 at 02:31
  • yes, delete it and re-add it corrected. – Andrew Dec 12 '22 at 02:36
  • So how do these two routing tables work together to enable the tenant network segment 192.168.1.0/24 to communicate with 192.168.2.0/24？ – Yongxin Cao Dec 12 '22 at 02:38
  • I think you are incorrectly assuming 2.2.2.2 in the default vrf is the same as 2.2.2.2 in vrf Vrf01, it is not. – Andrew Dec 12 '22 at 15:24