[PATCH net-next v2] net: vrf: don't down the interface when add slave

[PATCH net-next v2] net: vrf: don't down the interface when add slave

[Menglong Dong]

For now, cycle_netdev() will be called to flush the neighbor cache when
add slave by downing and upping the slave netdev. When the slave has
vlan devices, the data transmission can interrupted.

Optimize it by introducing the NETDEV_VRF_MASTER event. When a net device
is added to the slave of the vrf, the NETDEV_VRF_MASTER event will be
triggered, and the neighbor cache will be flushed, and the routes will be
moved to the corresponding table.

The moving of the routes across tables is tested with following command:

  $ ip link add name dummy1 up type dummy
  $ sysctl -wq net.ipv6.conf.dummy1.keep_addr_on_down=1
  $ ip address add 192.0.2.1/24 dev dummy1
  $ ip address add 2001:db8:1::1/64 dev dummy1
  $ ip link add name vrf1 up type vrf table 100
  $ ip link set dev dummy1 master vrf1

  $ ip -6 r show table 100
  local 2001:db8:1::1 dev dummy1 proto kernel metric 0 pref medium
  2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
  local fe80::cc26:8ff:fe02:ae95 dev dummy1 proto kernel metric 0 pref medium
  fe80::/64 dev dummy1 proto kernel metric 256 pref medium
  multicast ff00::/8 dev dummy1 proto kernel metric 256 pref medium

  $ ip -4 r show table 100
  192.0.2.0/24 dev dummy1 proto kernel scope link src 192.0.2.1
  local 192.0.2.1 dev dummy1 proto kernel scope host src 192.0.2.1
  broadcast 192.0.2.255 dev dummy1 proto kernel scope link src 192.0.2.1

Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
---
v2:
- introduce the NETDEV_VRF_MASTER
---
 drivers/net/vrf.c         | 6 ++----
 include/linux/netdevice.h | 1 +
 net/core/dev.c            | 2 +-
 net/ipv4/arp.c            | 1 +
 net/ipv4/fib_frontend.c   | 3 +++
 net/ipv6/addrconf.c       | 6 +++++-
 net/ipv6/ndisc.c          | 1 +
 7 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 3ccd649913b5..0fee1f46ef97 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -1042,15 +1042,13 @@ static int vrf_rtable_create(struct net_device *dev)
 static void cycle_netdev(struct net_device *dev,
 			 struct netlink_ext_ack *extack)
 {
-	unsigned int flags = dev->flags;
 	int ret;
 
 	if (!netif_running(dev))
 		return;
 
-	ret = dev_change_flags(dev, flags & ~IFF_UP, extack);
-	if (ret >= 0)
-		ret = dev_change_flags(dev, flags, extack);
+	ret = call_netdevice_notifiers(NETDEV_VRF_MASTER, dev);
+	ret = notifier_to_errno(ret);
 
 	if (ret < 0) {
 		netdev_err(dev,
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5e5de4b0a433..62f0f7f7bcee 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3159,6 +3159,7 @@ enum netdev_cmd {
 	NETDEV_OFFLOAD_XSTATS_REPORT_USED,
 	NETDEV_OFFLOAD_XSTATS_REPORT_DELTA,
 	NETDEV_XDP_FEAT_CHANGE,
+	NETDEV_VRF_MASTER,
 };
 const char *netdev_cmd_to_name(enum netdev_cmd cmd);
 
diff --git a/net/core/dev.c b/net/core/dev.c
index b28ce68830b2..cd5c3ae08487 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1853,7 +1853,7 @@ const char *netdev_cmd_to_name(enum netdev_cmd cmd)
 	N(SVLAN_FILTER_PUSH_INFO) N(SVLAN_FILTER_DROP_INFO)
 	N(PRE_CHANGEADDR) N(OFFLOAD_XSTATS_ENABLE) N(OFFLOAD_XSTATS_DISABLE)
 	N(OFFLOAD_XSTATS_REPORT_USED) N(OFFLOAD_XSTATS_REPORT_DELTA)
-	N(XDP_FEAT_CHANGE)
+	N(XDP_FEAT_CHANGE) N(VRF_MASTER)
 	}
 #undef N
 	return "UNKNOWN_NETDEV_EVENT";
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 5cfc1c939673..67d7c4c949a2 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1328,6 +1328,7 @@ static int arp_netdev_event(struct notifier_block *this, unsigned long event,
 	bool evict_nocarrier;
 
 	switch (event) {
+	case NETDEV_VRF_MASTER:
 	case NETDEV_CHANGEADDR:
 		neigh_changeaddr(&arp_tbl, dev);
 		rt_cache_flush(dev_net(dev));
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 6e1b94796f67..53de7b11e731 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1510,6 +1510,9 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
 		return NOTIFY_DONE;
 
 	switch (event) {
+	case NETDEV_VRF_MASTER:
+		fib_disable_ip(dev, event, false);
+		fallthrough;
 	case NETDEV_UP:
 		in_dev_for_each_ifa_rtnl(ifa, in_dev) {
 			fib_add_ifaddr(ifa);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f17a5dd4789f..c1f8c8a3e394 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3677,6 +3677,7 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
 
 		run_pending = 1;
 		fallthrough;
+	case NETDEV_VRF_MASTER:
 	case NETDEV_UP:
 	case NETDEV_CHANGE:
 		if (idev && idev->cnf.disable_ipv6)
@@ -3689,7 +3690,10 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
 			break;
 		}
 
-		if (event == NETDEV_UP) {
+		if (event == NETDEV_VRF_MASTER)
+			addrconf_ifdown(dev, false);
+
+		if (event == NETDEV_UP || event == NETDEV_VRF_MASTER) {
 			/* restore routes for permanent addresses */
 			addrconf_permanent_addr(net, dev);
 
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 7d5abb3158ec..8db8c34b9108 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1858,6 +1858,7 @@ static int ndisc_netdev_event(struct notifier_block *this, unsigned long event,
 	bool evict_nocarrier;
 
 	switch (event) {
+	case NETDEV_VRF_MASTER:
 	case NETDEV_CHANGEADDR:
 		neigh_changeaddr(&nd_tbl, dev);
 		fib6_run_gc(0, net, false);
-- 
2.50.1

Re: [PATCH net-next v2] net: vrf: don't down the interface when add slave

[kernel test robot]

Hi Menglong,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net-next/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Menglong-Dong/net-vrf-don-t-down-the-interface-when-add-slave/20250807-140407
base:   net-next/main
patch link:    https://lore.kernel.org/r/20250807055634.113753-1-dongml2%40chinatelecom.cn
patch subject: [PATCH net-next v2] net: vrf: don't down the interface when add slave
config: arc-randconfig-001-20250808 (https://download.01.org/0day-ci/archive/20250808/202508080147.1G52KerV-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 14.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250808/202508080147.1G52KerV-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202508080147.1G52KerV-lkp@intel.com/

All warnings (new ones prefixed by >>):

   net/core/lock_debug.c: In function 'netdev_debug_event':
>> net/core/lock_debug.c:20:9: warning: enumeration value 'NETDEV_VRF_MASTER' not handled in switch [-Wswitch]
      20 |         switch (cmd) {
         |         ^~~~~~


vim +/NETDEV_VRF_MASTER +20 net/core/lock_debug.c

03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  11  
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  12  int netdev_debug_event(struct notifier_block *nb, unsigned long event,
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  13  		       void *ptr)
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  14  {
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  15  	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  16  	struct net *net = dev_net(dev);
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  17  	enum netdev_cmd cmd = event;
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  18  
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  19  	/* Keep enum and don't add default to trigger -Werror=switch */
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04 @20  	switch (cmd) {
22cbc1ee268b7e net/core/lock_debug.c     Jakub Kicinski     2025-04-15  21  	case NETDEV_XDP_FEAT_CHANGE:
22cbc1ee268b7e net/core/lock_debug.c     Jakub Kicinski     2025-04-15  22  		netdev_assert_locked(dev);
22cbc1ee268b7e net/core/lock_debug.c     Jakub Kicinski     2025-04-15  23  		fallthrough;
cb7103298d1c5d net/core/lock_debug.c     Jakub Kicinski     2025-04-10  24  	case NETDEV_CHANGE:
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  25  	case NETDEV_REGISTER:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  26  	case NETDEV_UP:
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  27  		netdev_ops_assert_locked(dev);
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  28  		fallthrough;
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  29  	case NETDEV_DOWN:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  30  	case NETDEV_REBOOT:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  31  	case NETDEV_UNREGISTER:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  32  	case NETDEV_CHANGEMTU:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  33  	case NETDEV_CHANGEADDR:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  34  	case NETDEV_PRE_CHANGEADDR:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  35  	case NETDEV_GOING_DOWN:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  36  	case NETDEV_FEAT_CHANGE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  37  	case NETDEV_BONDING_FAILOVER:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  38  	case NETDEV_PRE_UP:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  39  	case NETDEV_PRE_TYPE_CHANGE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  40  	case NETDEV_POST_TYPE_CHANGE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  41  	case NETDEV_POST_INIT:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  42  	case NETDEV_PRE_UNINIT:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  43  	case NETDEV_RELEASE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  44  	case NETDEV_NOTIFY_PEERS:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  45  	case NETDEV_JOIN:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  46  	case NETDEV_CHANGEUPPER:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  47  	case NETDEV_RESEND_IGMP:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  48  	case NETDEV_PRECHANGEMTU:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  49  	case NETDEV_CHANGEINFODATA:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  50  	case NETDEV_BONDING_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  51  	case NETDEV_PRECHANGEUPPER:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  52  	case NETDEV_CHANGELOWERSTATE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  53  	case NETDEV_UDP_TUNNEL_PUSH_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  54  	case NETDEV_UDP_TUNNEL_DROP_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  55  	case NETDEV_CHANGE_TX_QUEUE_LEN:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  56  	case NETDEV_CVLAN_FILTER_PUSH_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  57  	case NETDEV_CVLAN_FILTER_DROP_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  58  	case NETDEV_SVLAN_FILTER_PUSH_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  59  	case NETDEV_SVLAN_FILTER_DROP_INFO:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  60  	case NETDEV_OFFLOAD_XSTATS_ENABLE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  61  	case NETDEV_OFFLOAD_XSTATS_DISABLE:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  62  	case NETDEV_OFFLOAD_XSTATS_REPORT_USED:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  63  	case NETDEV_OFFLOAD_XSTATS_REPORT_DELTA:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  64  		ASSERT_RTNL();
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  65  		break;
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  66  
be94cfdb993ff0 net/core/rtnl_net_debug.c Kuniyuki Iwashima  2025-01-15  67  	case NETDEV_CHANGENAME:
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  68  		ASSERT_RTNL_NET(net);
be94cfdb993ff0 net/core/rtnl_net_debug.c Kuniyuki Iwashima  2025-01-15  69  		break;
be94cfdb993ff0 net/core/rtnl_net_debug.c Kuniyuki Iwashima  2025-01-15  70  	}
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  71  
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  72  	return NOTIFY_DONE;
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  73  }
1901066aab7654 net/core/lock_debug.c     Stanislav Fomichev 2025-04-01  74  EXPORT_SYMBOL_NS_GPL(netdev_debug_event, "NETDEV_INTERNAL");
03fa534856593b net/core/rtnl_net_debug.c Kuniyuki Iwashima  2024-10-04  75  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH net-next v2] net: vrf: don't down the interface when add slave

[Ido Schimmel]

On Thu, Aug 07, 2025 at 01:56:34PM +0800, Menglong Dong wrote:
> For now, cycle_netdev() will be called to flush the neighbor cache when
> add slave by downing and upping the slave netdev. When the slave has
> vlan devices, the data transmission can interrupted.

OK, but can you provide more details on the production use case for
enslaving the real device to a VRF during runtime? Usually this kind of
configuration is performed before data transmission begins. I suspect
this is why nobody complained about this behavior despite being present
in the VRF driver since its initial submission almost a decade ago.

I'm asking because the potential for regressions from this patch seems
quite high to me. For example, before this patch nexthop objects using
the enslaved device would get flushed, but now they persist. This can
impact offload of nexthop objects and it's possible I'm missing more
potential regressions.

Before:

# ip link add name dummy1 up type dummy
# ip link add name vrf1 up type vrf table 100
# ip address add 192.0.2.1/24 dev dummy1
# ip nexthop add id 1 via 192.0.2.2 dev dummy1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link
# ip link set dev dummy1 master vrf1
# ip nexthop
# echo $?
0

After:

# ip link add name dummy1 up type dummy
# ip link add name vrf1 up type vrf table 100
# ip address add 192.0.2.1/24 dev dummy1
# ip nexthop add id 1 via 192.0.2.2 dev dummy1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link 
# ip link set dev dummy1 master vrf1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link 

> 
> Optimize it by introducing the NETDEV_VRF_MASTER event. When a net device
> is added to the slave of the vrf, the NETDEV_VRF_MASTER event will be
> triggered, and the neighbor cache will be flushed, and the routes will be
> moved to the corresponding table.
> 
> The moving of the routes across tables is tested with following command:
> 
>   $ ip link add name dummy1 up type dummy
>   $ sysctl -wq net.ipv6.conf.dummy1.keep_addr_on_down=1
>   $ ip address add 192.0.2.1/24 dev dummy1
>   $ ip address add 2001:db8:1::1/64 dev dummy1
>   $ ip link add name vrf1 up type vrf table 100
>   $ ip link set dev dummy1 master vrf1
> 
>   $ ip -6 r show table 100
>   local 2001:db8:1::1 dev dummy1 proto kernel metric 0 pref medium
>   2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
>   local fe80::cc26:8ff:fe02:ae95 dev dummy1 proto kernel metric 0 pref medium
>   fe80::/64 dev dummy1 proto kernel metric 256 pref medium
>   multicast ff00::/8 dev dummy1 proto kernel metric 256 pref medium
> 
>   $ ip -4 r show table 100
>   192.0.2.0/24 dev dummy1 proto kernel scope link src 192.0.2.1
>   local 192.0.2.1 dev dummy1 proto kernel scope host src 192.0.2.1
>   broadcast 192.0.2.255 dev dummy1 proto kernel scope link src 192.0.2.1
> 
> Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>

Re: [PATCH net-next v2] net: vrf: don't down the interface when add slave

[David Ahern]

On 8/10/25 1:41 AM, Ido Schimmel wrote:
> On Thu, Aug 07, 2025 at 01:56:34PM +0800, Menglong Dong wrote:
>> For now, cycle_netdev() will be called to flush the neighbor cache when
>> add slave by downing and upping the slave netdev. When the slave has
>> vlan devices, the data transmission can interrupted.
> 
> OK, but can you provide more details on the production use case for
> enslaving the real device to a VRF during runtime? Usually this kind of
> configuration is performed before data transmission begins. I suspect
> this is why nobody complained about this behavior despite being present
> in the VRF driver since its initial submission almost a decade ago.
> 
> I'm asking because the potential for regressions from this patch seems
> quite high to me. For example, before this patch nexthop objects using
> the enslaved device would get flushed, but now they persist. This can
> impact offload of nexthop objects and it's possible I'm missing more
> potential regressions.
> 

+1

Thanks for staying on top of this, Ido. I have been very distracted the
past few months.

The design choices when the VRF code was first written was either
1) require the devices to be added to a VRF while down, or
2) cycle the device while adding it to the VRF.

I preferred 2 as the simplest choice for users, and so that is the way
the feature went in.

Re: [PATCH net-next v2] net: vrf: don't down the interface when add slave

[Menglong Dong]

On Mon, Aug 11, 2025 at 8:03 AM David Ahern <dsahern@kernel.org> wrote:
>
> On 8/10/25 1:41 AM, Ido Schimmel wrote:
> > On Thu, Aug 07, 2025 at 01:56:34PM +0800, Menglong Dong wrote:
> >> For now, cycle_netdev() will be called to flush the neighbor cache when
> >> add slave by downing and upping the slave netdev. When the slave has
> >> vlan devices, the data transmission can interrupted.
> >
> > OK, but can you provide more details on the production use case for
> > enslaving the real device to a VRF during runtime? Usually this kind of
> > configuration is performed before data transmission begins. I suspect
> > this is why nobody complained about this behavior despite being present
> > in the VRF driver since its initial submission almost a decade ago.
> >
> > I'm asking because the potential for regressions from this patch seems
> > quite high to me. For example, before this patch nexthop objects using
> > the enslaved device would get flushed, but now they persist. This can
> > impact offload of nexthop objects and it's possible I'm missing more
> > potential regressions.
> >
>
> +1
>
> Thanks for staying on top of this, Ido. I have been very distracted the
> past few months.
>
> The design choices when the VRF code was first written was either
> 1) require the devices to be added to a VRF while down, or
> 2) cycle the device while adding it to the VRF.
>
> I preferred 2 as the simplest choice for users, and so that is the way
> the feature went in.

I see.  The use case is that we want to use VRF for a living
environment and without breaking the traffic on the VLAN. It
seems that it's not a normal use case and we are using it in the
wrong way.

Thanks for Ido's and David's reply ;)

Menglong Dong