linux-vrf-core — Mailing list for core developers

[linux-vrf-core] Add default vrf to process

[Nick E. <ni...@dc...>]

I am investigating adding code to assign a default vrf to a process.

Each process would initially start in vrf 0.  The socket creation code would be
modified to set the socket vrf to current->default_vrf instead of 0.

I hesitate to add yet another set of system calls for this simple function and
am leaning toward a /proc interface.

Please comment.

--Nick



-- 
Nick Eggleston
Consultant
Data Communications Consulting, Inc.
6320 Rucker Road, Suite E
Indianapolis, IN  46220
317/726-0295 x18
317/202-2445 (fax)

Re: [linux-vrf-core] [PATCH] routes are on the fib but ip route doesn't list them

[James R. L. <jl...@mi...>]

Thanks.  I'll look it over and apply to my tree.

On Fri, Jan 31, 2003 at 05:30:58PM +0100, Jorge Boncompte [DTI2] wrote:
>     This took me 1 week guesing what was happening :(
> 
>     The vrf value wasnt't being saved in the netlink callback so when the
> skb is filled with routes and sent to userspace and inet_dump_fib is called
> again to return more routes it doesn't continue where it left it. It seems
> that inet_dump_rules has the same bug.
> 
>     patch attached applies on top of linux-vrf 0.100
> 
>     Best regards,
> 
>     -Jorge
> 
> ==============================================================
> Jorge Boncompte - Tecnico de sistemas
> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
> --------------------------------------------------------------
> C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
> Tlf: +34 957 761395 / FAX: +34 957 450380
> --------------------------------------------------------------
> jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
> ==============================================================
> - Sin pistachos no hay Rock & Roll...
> - Without wicker a basket cannot be done.
> ==============================================================



-- 
James R. Leu

[linux-vrf-core] [PATCH] routes are on the fib but ip route doesn't list them

[Jorge B. [DTI2] <jo...@dt...>]

    This took me 1 week guesing what was happening :(

    The vrf value wasnt't being saved in the netlink callback so when the
skb is filled with routes and sent to userspace and inet_dump_fib is called
again to return more routes it doesn't continue where it left it. It seems
that inet_dump_rules has the same bug.

    patch attached applies on top of linux-vrf 0.100

    Best regards,

    -Jorge

==============================================================
Jorge Boncompte - Tecnico de sistemas
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
--------------------------------------------------------------
jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be done.
==============================================================

Re: [linux-vrf-core] [PATCHLET] Check ioctl parameters.

[James R. L. <jl...@mi...>]

Patch applied.

On Thu, Jan 02, 2003 at 01:39:55PM +0100, Yon Uriarte wrote:
> Hi,
> 
> Do not happily overwrite memory. A better solution could be to just
> #define VRF_MAX 256
> and forget about it (there is cast in the af_inet.c call, so the check
> would be redundant). Wasted memory is not an issue ( less than 1Kbyte).
> 
> And a happy new year,
>  yon
> 
> 

> --- net/ipv4/orig2.fib_rules.c	Thu Jan  2 13:12:03 2003
> +++ net/ipv4/fib_rules.c	Thu Jan  2 13:35:16 2003
> @@ -466,6 +466,7 @@ void do_fib_del_vrf(struct fib_rule *rul
>  
>  int fib_del_vrf(unsigned char vrf) {
>  
> +	if (vrf >= VRF_MAX) return -EINVAL;
>  	if (!vrf || fib_rules[vrf] == NULL) {
>  		return 0;
>  	}
> @@ -484,6 +485,7 @@ int fib_add_vrf(unsigned char vrf) {
>  	struct fib_rule *main_rule;
>  	struct fib_rule *loc_rule;
>  
> +	if (vrf >= VRF_MAX) return -EINVAL;
>  	if (fib_rules[vrf]) return -EEXIST;
>  
>  	df_rule = kmalloc(sizeof(struct fib_rule),GFP_KERNEL);


-- 
James R. Leu

[linux-vrf-core] [PATCHLET] Check ioctl parameters.

[Yon U. <hav...@gm...>]

Hi,

Do not happily overwrite memory. A better solution could be to just
#define VRF_MAX 256
and forget about it (there is cast in the af_inet.c call, so the check
would be redundant). Wasted memory is not an issue ( less than 1Kbyte).

And a happy new year,
 yon

Re: [linux-vrf-core] [PATCH] connected routes.

[James R. L. <jl...@mi...>]

Applied (with formating changes)

On Sun, Dec 15, 2002 at 07:39:36AM +0100, Yon Uriarte wrote:
> Hi,
> 
>  When moving an interface to a new VRF the connected routes
> stay on the old VRF and no connected routes are added to the
> the new VRF.
> 
>  Somewhat brute force. This will work for any program changing
> the dev->vrf, not just iproute2 with jorge's patch.
> 
> c ya,
>  yon
> 

> --- orig/net/core/dev.c	Sun Dec 15 06:25:08 2002
> +++ local/net/core/dev.c	Sun Dec 15 07:17:28 2002
> @@ -2016,8 +2016,28 @@
>  			return 0;
>  	
>  		case SIOCSIFVRF:	/* Set the VRF for a device */
> -			dev->vrf = ifr->ifr_flags;
> -			return 0;
> +		  /*   Quick and dirty way to get all routes changed
> +		     automatically. In fact, it could be said that changing
> +		     the VRF is somewhat equal to down'ing the interface
> +		     (in the original VRF), and up'ing it in the new VRF.
> +		     Another nice side effect is getting a netlink message
> +		     (which could be generated via netdev_state_change()),
> +		     so there is no need to poll to get VRF changes.
> +		      Even adding a NETDEV_CHANGEVRF to the notifier events
> +		     might be a more elegant solution. --yon */
> +
> +		    if (dev->vrf != ifr->ifr_flags)
> +		      {
> +			int flags = dev->flags;
> +			if (flags&IFF_UP)
> +			  dev_change_flags (dev, flags^IFF_UP);
> +
> +		        dev->vrf = ifr->ifr_flags;
> +
> +			if (flags&IFF_UP)
> +			  dev_change_flags (dev, flags);
> +		      }
> +		    return 0;
>  
>  		case SIOCGIFHWADDR:
>  			memcpy(ifr->ifr_hwaddr.sa_data,dev->dev_addr, MAX_ADDR_LEN);


-- 
James R. Leu

[linux-vrf-core] [PATCH] connected routes.

[Yon U. <hav...@gm...>]

Hi,

 When moving an interface to a new VRF the connected routes
stay on the old VRF and no connected routes are added to the
the new VRF.

 Somewhat brute force. This will work for any program changing
the dev->vrf, not just iproute2 with jorge's patch.

c ya,
 yon

[linux-vrf-core] [PATCH] locking too long -> panic

[Yon U. <hav...@gm...>]

Hi,

fib_add_vrf()
 {

   ... write_lock_bh(...);
     -> cpu_bh_disable(...)
     -> -> irq_stats.__local_bh_count++
  ...
     3x __fib_new_table();
     -> fib_hash_init
      -> -> kmalloc(, GFP_KERNEL) /*  allocs from the 256 bytes pool */
 }

eventually (aint randomness fun) the slab cache entry for 256 must grow,
and it hits:

  if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
                BUG();

in_interrupt() checks for "(... +irq_stats.__local_bh_count) != 0"

Anyway, now for my voodoo explanation of locking:

 On SMP the function is protected by lock_kernel()
(in inet_ioctl()), on UP no write access can happen, 'cos
this is user context and it is unpreemptable, and no BH will
write-access the values. So basically, only the last assigment
needs to be protected (not the "kmalloc"s ), and the check for
        if (fib_rules[vrf]) return -EEXIST;
is outside the protected region anyway.

enjoy,
 yon

[linux-vrf-core] [PATCH] NULL deref on SIOCDELVRF

[Yon U. <hav...@gm...>]

Hi,

uml-4:~ # vrfctl -d <non existant VRF number>

Cause:
ioctl() ...
  case SIOCDELVRF:
fib_del_vrf  No check for fib_rules[vrf] != NULL and then
do_fib_del_vrf bombs when dereferencing NULL.



 Non tested patch:

--- net/ipv4/fib_rules.c~       Wed Nov 27 04:56:23 2002
+++ net/ipv4/fib_rules.c        Wed Dec 11 19:12:04 2002
@@ -466,7 +466,7 @@

 int fib_del_vrf(unsigned char vrf) {

-       if (!vrf) {
+       if (!vrf || fib_rules[vrf] == NULL) {
                return 0;
        }
        write_lock_bh(&fib_rules_lock[vrf]);

[linux-vrf-core] next release

[Robert M. <ro...@ip...>]

Hi James,

You mention below that you were planning to make the next release for
linux-vrf last week... Out of curiousity, do you have any guidance for when
this might be appearing..?

Thanks,
-Robert.


> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of James R.
> Leu
> Sent: Friday, October 25, 2002 8:52 AM
> To: Robert May
> Cc: lin...@li...
> Subject: Re: [linux-vrf-core] "ip route show vrf X"
>
>
> Thank you for your bug reports.  The next release will contain the fixes.
> I expect to make the next release early next week.
>
>
> On Fri, Oct 25, 2002 at 07:38:05AM -0700, Robert May wrote:
> >
> > Hi all,
> >
> > While testing the iproute2 patch, I discovered the following behavior:
> >
> > Giving command "ip route show vrf X" causes ip utility to
> display all routes
> > for all VRFs, regardless of vrf SELECTOR.  In other words, it
> ignores the
> > selector.  I think that if "vrf X" selector is not given, all
> routes should
> > be shown.  If provided, it should only display the routes for that VRF.
> >
> > Attached patch provides the fix for this.  It should be applied after
> > linux-vrf iproute2 patch.
> >
> > Best regards,
> > -Robert.
>
>
>
> --
> James R. Leu
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> linux-vrf-core mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-core
>
>

Re: [linux-vrf-core] [PATCH] Lets get rid of vrfctl :)

[James R. L. <jl...@mi...>]

I will apply this patch so as to kill vrfctl, but I want to move to a
netlink interface for creating/deleting VRFs and for gathering info
about them.  I won't have time to work on it this weekend, but if
someone else were to implement before I get to it next week, I would
gladly accept the patch ;-)

Laters


On Fri, Oct 25, 2002 at 07:33:39PM +0200, Jorge Boncompte [DTI2] wrote:
> diff -uNr --exclude *.o iproute-20010824/ip/Makefile
> iproute-20010824-jorge/ip/Makefile
> --- iproute-20010824/ip/Makefile Wed Oct 23 15:03:17 2002
> +++ iproute-20010824-jorge/ip/Makefile Wed Oct 23 15:03:28 2002
> @@ -1,6 +1,6 @@
>  IPOBJ=ip.o ipaddress.o iproute.o iprule.o \
>      rtm_map.o iptunnel.o ipneigh.o iplink.o ipmaddr.o \
> -    ipmonitor.o ipmroute.o
> +    ipmonitor.o ipmroute.o ipvrf.o
> 
>  RTMONOBJ=rtmon.o
> 
> diff -uNr --exclude *.o iproute-20010824/ip/ip.c
> iproute-20010824-jorge/ip/ip.c
> --- iproute-20010824/ip/ip.c Wed Oct 23 15:09:18 2002
> +++ iproute-20010824-jorge/ip/ip.c Wed Oct 23 15:09:42 2002
> @@ -39,7 +39,7 @@
>  {
>   fprintf(stderr,
>  "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
> -"where  OBJECT := { link | addr | route | rule | neigh | tunnel |\n"
> +"where  OBJECT := { link | addr | route | rule | neigh | tunnel | vrf |\n"
>  "                   maddr | mroute | monitor }\n"
>  "       OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |\n"
>  "                    -f[amily] { inet | inet6 | ipx | dnet | link }
> | -o[neline] }\n");
> @@ -132,6 +132,8 @@
>    return do_ipneigh(argc-1, argv+1);
>   if (strcmp(basename, "iplink") == 0)
>    return do_iplink(argc-1, argv+1);
> + if (strcmp(basename, "ipvrf") == 0)
> +  return do_ipvrf(argc-1, argv+1);
>   if (strcmp(basename, "iptunnel") == 0)
>    return do_iptunnel(argc-1, argv+1);
>   if (strcmp(basename, "ipmonitor") == 0)
> @@ -153,6 +155,8 @@
>     return do_ipneigh(argc-2, argv+2);
>    if (matches(argv[1], "link") == 0)
>     return do_iplink(argc-2, argv+2);
> +  if (matches(argv[1], "vrf") == 0)
> +   return do_ipvrf(argc-2, argv+2);
>    if (matches(argv[1], "tunnel") == 0 ||
>        strcmp(argv[1], "tunl") == 0)
>     return do_iptunnel(argc-2, argv+2);
> diff -uNr --exclude *.o iproute-20010824/ip/ip_common.h
> iproute-20010824-jorge/ip/ip_common.h
> --- iproute-20010824/ip/ip_common.h Sun Apr 16 19:42:50 2000
> +++ iproute-20010824-jorge/ip/ip_common.h Wed Oct 23 15:07:39 2002
> @@ -5,6 +5,7 @@
>  extern int ipaddr_list_link(int argc, char **argv);
>  extern int iproute_monitor(int argc, char **argv);
>  extern void iplink_usage(void) __attribute__((noreturn));
> +extern void ipvrf_usage(void) __attribute__((noreturn));
>  extern void iproute_reset_filter(void);
>  extern void ipaddr_reset_filter(int);
>  extern void ipneigh_reset_filter(void);
> @@ -15,6 +16,7 @@
>  extern int do_ipneigh(int argc, char **argv);
>  extern int do_iptunnel(int argc, char **argv);
>  extern int do_iplink(int argc, char **argv);
> +extern int do_ipvrf(int argc, char **argv);
>  extern int do_ipmonitor(int argc, char **argv);
>  extern int do_multiaddr(int argc, char **argv);
>  extern int do_multiroute(int argc, char **argv);
> --- iproute-20010824/ip/ipvrf.c Thu Jan  1 01:00:00 1970
> +++ iproute-20010824-jorge/ip/ipvrf.c Fri Oct 25 19:27:18 2002
> @@ -0,0 +1,106 @@
> +/*
> + * ipvrf.c  "ip vrf".
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU General Public License
> + *  as published by the Free Software Foundation; either version
> + *  2 of the License, or (at your option) any later version.
> + *
> + * Authors: Alexey Kuznetsov, <ku...@ms...>
> + *   Hacked by: Jorge Boncompte, <jo...@dt...>
> + *
> + */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <unistd.h>
> +#include <errno.h>
> +#include <sys/socket.h>
> +#include <linux/sockios.h>
> +#include <sys/ioctl.h>
> +
> +#include "utils.h"
> +
> +void ipvrf_usage(void)
> +{
> + fprintf(stderr, "Usage: ip vrf list\n");
> + fprintf(stderr, "       ip vrf {add | del} VRFID\n");
> + fprintf(stderr, "       ip vrf show\n");
> + exit(-1);
> +}
> +
> +static void usage(void)
> +{
> + ipvrf_usage();
> +}
> +
> +static int do_vrf(int action, int argc, char **argv)
> +{
> +    int fd=0;
> +    int vrf=-1;
> +
> + if (vrf != -1)
> +  duparg("vrf", *argv);
> + if (get_integer(&vrf, *argv, 0))
> +  invarg("Invalid \"vrf\" value\n", *argv);
> +
> + if (vrf > VRF_MAX) {
> +  fprintf(stderr, "VRF ID out of range (1-%d)\n", VRF_MAX);
> +  exit(-1);
> + }
> + if (vrf != -1) {
> +  if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
> +   perror("opening socket");
> +   exit(-1);
> +  }
> +  if(ioctl(fd, action, vrf) < 0){
> +   perror("ioctl");
> +   exit(-1);
> +  }
> + }
> + close(fd);
> + return 0;
> +}
> +
> +int ipvrf_list(int argc, char **argv)
> +{
> +    int fd=0, vrf;
> +
> + if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
> +  perror("opening socket");
> +  exit(-1);
> + }
> + for (vrf=1;vrf<=VRF_MAX;vrf++){
> +  if(ioctl(fd, SIOCGETVRF, vrf) < 0){
> +   if (errno != ENOENT){
> +    perror("ioctl");
> +    exit(-1);
> +   }
> +  } else {
> +   /* FIXME: List the interfaces attached to the VRF */
> +   printf("VRF ID=%d\n", vrf);
> +  }
> + }
> + close(fd);
> + return 0;
> +}
> +
> +int do_ipvrf(int argc, char **argv)
> +{
> + if (argc > 0) {
> +  if (matches(*argv, "add") == 0)
> +   return do_vrf(SIOCADDVRF, argc-1, argv+1);
> +  if (matches(*argv, "del") == 0)
> +   return do_vrf(SIOCDELVRF, argc-1, argv+1);
> +  if (matches(*argv, "show") == 0 ||
> +      matches(*argv, "lst") == 0 ||
> +      matches(*argv, "list") == 0)
> +   return ipvrf_list(argc-1, argv+1);
> +  if (matches(*argv, "help") == 0)
> +   usage();
> + } else
> +  return ipvrf_list(0, NULL);
> +
> + fprintf(stderr, "Command \"%s\" is unknown, try \"ip vrf help\".\n",
> *argv);
> + exit(-1);
> +}
> 
>     -Jorge
> 
> ==============================================================
> Jorge Boncompte - Tecnico de sistemas
> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
> --------------------------------------------------------------
> C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
> Tlf: +34 957 761395 / FAX: +34 957 450380
> --------------------------------------------------------------
> jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
> ==============================================================
> - Sin pistachos no hay Rock & Roll...
> - Without wicker a basket cannot be done.
> ==============================================================
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> linux-vrf-core mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-core

-- 
James R. Leu

[linux-vrf-core] [PATCH] Another one

[Jorge B. [DTI2] <jo...@dt...>]

    Hi again,

    Kernel crash if you put an interface in a VRF that doesn't exist and the
you try to add the VRF, I think that this check has to be done in the kernel
in SIOCSIFVRF but fib_rules[vrf] is not accesible from core/dev.c and I
think it hasn't so I check in userspace. James any idea on how to do this?
    I set the interface down and up after changing the VRF of an interface
to move the routes between VRFs

diff -uNr --exclude *.o iproute-20010824/ip/iplink.c
iproute-20010824-jorge/ip/iplink.c
--- iproute-20010824/ip/iplink.c Sat Oct 19 00:23:25 2002
+++ iproute-20010824-jorge/ip/iplink.c Fri Oct 25 19:27:40 2002
@@ -41,7 +41,7 @@
  fprintf(stderr, "                      multicast { on | off } | txqueuelen
PACKETS |\n");
  fprintf(stderr, "                      name NEWNAME |\n");
  fprintf(stderr, "                      address LLADDR | broadcast LLADDR
|\n");
- fprintf(stderr, "                      mtu MTU | vrf NUMBER }\n");
+ fprintf(stderr, "                      mtu MTU | vrf VRFID }\n");
  fprintf(stderr, "       ip link show [ DEVICE ]\n");
  exit(-1);
 }
@@ -181,10 +181,19 @@
  memset(&ifr, 0, sizeof(ifr));
  strcpy(ifr.ifr_name, dev);
  ifr.ifr_flags = vrf;
- if (ioctl(s, SIOCSIFVRF, &ifr) < 0) {
-  perror("SIOCSIFVRF");
-  close(s);
-  return -1;
+ if(ioctl(s, SIOCGETVRF, vrf) == 0){
+  if (ioctl(s, SIOCSIFVRF, &ifr) < 0) {
+   perror("SIOCSIFVRF");
+   close(s);
+   return -1;
+  }
+ } else {
+      if (errno != ENOENT){
+   perror("ioctl");
+   exit(-1);
+  } else {
+   fprintf(stderr, "VRF %d does not exist.\n", vrf);
+  }
  }
  close(s);

@@ -394,7 +403,16 @@
  }
  if (vrf != -1) {
   if (set_vrf(dev, vrf) < 0)
-   return -1;
+   return -1;
+  /* HACK HACK HACK */
+  /* Setting the interface down and up moves the routes
+  between the old and new VRF */
+  mask |= IFF_UP;
+  flags &= ~IFF_UP;
+  do_chflags(dev, flags, mask); /* DOWN */
+  mask |= IFF_UP;
+  flags |= IFF_UP;
+  do_chflags(dev, flags, mask); /* UP */
  }
  if (newaddr || newbrd) {
   if (newbrd) {


    -Jorge

==============================================================
Jorge Boncompte - Tecnico de sistemas
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
--------------------------------------------------------------
jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be done.
==============================================================

[linux-vrf-core] [PATCH] Lets get rid of vrfctl :)

[Jorge B. [DTI2] <jo...@dt...>]

diff -uNr --exclude *.o iproute-20010824/ip/Makefile
iproute-20010824-jorge/ip/Makefile
--- iproute-20010824/ip/Makefile Wed Oct 23 15:03:17 2002
+++ iproute-20010824-jorge/ip/Makefile Wed Oct 23 15:03:28 2002
@@ -1,6 +1,6 @@
 IPOBJ=ip.o ipaddress.o iproute.o iprule.o \
     rtm_map.o iptunnel.o ipneigh.o iplink.o ipmaddr.o \
-    ipmonitor.o ipmroute.o
+    ipmonitor.o ipmroute.o ipvrf.o

 RTMONOBJ=rtmon.o

diff -uNr --exclude *.o iproute-20010824/ip/ip.c
iproute-20010824-jorge/ip/ip.c
--- iproute-20010824/ip/ip.c Wed Oct 23 15:09:18 2002
+++ iproute-20010824-jorge/ip/ip.c Wed Oct 23 15:09:42 2002
@@ -39,7 +39,7 @@
 {
  fprintf(stderr,
 "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
-"where  OBJECT := { link | addr | route | rule | neigh | tunnel |\n"
+"where  OBJECT := { link | addr | route | rule | neigh | tunnel | vrf |\n"
 "                   maddr | mroute | monitor }\n"
 "       OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |\n"
 "                    -f[amily] { inet | inet6 | ipx | dnet | link }
| -o[neline] }\n");
@@ -132,6 +132,8 @@
   return do_ipneigh(argc-1, argv+1);
  if (strcmp(basename, "iplink") == 0)
   return do_iplink(argc-1, argv+1);
+ if (strcmp(basename, "ipvrf") == 0)
+  return do_ipvrf(argc-1, argv+1);
  if (strcmp(basename, "iptunnel") == 0)
   return do_iptunnel(argc-1, argv+1);
  if (strcmp(basename, "ipmonitor") == 0)
@@ -153,6 +155,8 @@
    return do_ipneigh(argc-2, argv+2);
   if (matches(argv[1], "link") == 0)
    return do_iplink(argc-2, argv+2);
+  if (matches(argv[1], "vrf") == 0)
+   return do_ipvrf(argc-2, argv+2);
   if (matches(argv[1], "tunnel") == 0 ||
       strcmp(argv[1], "tunl") == 0)
    return do_iptunnel(argc-2, argv+2);
diff -uNr --exclude *.o iproute-20010824/ip/ip_common.h
iproute-20010824-jorge/ip/ip_common.h
--- iproute-20010824/ip/ip_common.h Sun Apr 16 19:42:50 2000
+++ iproute-20010824-jorge/ip/ip_common.h Wed Oct 23 15:07:39 2002
@@ -5,6 +5,7 @@
 extern int ipaddr_list_link(int argc, char **argv);
 extern int iproute_monitor(int argc, char **argv);
 extern void iplink_usage(void) __attribute__((noreturn));
+extern void ipvrf_usage(void) __attribute__((noreturn));
 extern void iproute_reset_filter(void);
 extern void ipaddr_reset_filter(int);
 extern void ipneigh_reset_filter(void);
@@ -15,6 +16,7 @@
 extern int do_ipneigh(int argc, char **argv);
 extern int do_iptunnel(int argc, char **argv);
 extern int do_iplink(int argc, char **argv);
+extern int do_ipvrf(int argc, char **argv);
 extern int do_ipmonitor(int argc, char **argv);
 extern int do_multiaddr(int argc, char **argv);
 extern int do_multiroute(int argc, char **argv);
--- iproute-20010824/ip/ipvrf.c Thu Jan  1 01:00:00 1970
+++ iproute-20010824-jorge/ip/ipvrf.c Fri Oct 25 19:27:18 2002
@@ -0,0 +1,106 @@
+/*
+ * ipvrf.c  "ip vrf".
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ *
+ * Authors: Alexey Kuznetsov, <ku...@ms...>
+ *   Hacked by: Jorge Boncompte, <jo...@dt...>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <sys/socket.h>
+#include <linux/sockios.h>
+#include <sys/ioctl.h>
+
+#include "utils.h"
+
+void ipvrf_usage(void)
+{
+ fprintf(stderr, "Usage: ip vrf list\n");
+ fprintf(stderr, "       ip vrf {add | del} VRFID\n");
+ fprintf(stderr, "       ip vrf show\n");
+ exit(-1);
+}
+
+static void usage(void)
+{
+ ipvrf_usage();
+}
+
+static int do_vrf(int action, int argc, char **argv)
+{
+    int fd=0;
+    int vrf=-1;
+
+ if (vrf != -1)
+  duparg("vrf", *argv);
+ if (get_integer(&vrf, *argv, 0))
+  invarg("Invalid \"vrf\" value\n", *argv);
+
+ if (vrf > VRF_MAX) {
+  fprintf(stderr, "VRF ID out of range (1-%d)\n", VRF_MAX);
+  exit(-1);
+ }
+ if (vrf != -1) {
+  if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
+   perror("opening socket");
+   exit(-1);
+  }
+  if(ioctl(fd, action, vrf) < 0){
+   perror("ioctl");
+   exit(-1);
+  }
+ }
+ close(fd);
+ return 0;
+}
+
+int ipvrf_list(int argc, char **argv)
+{
+    int fd=0, vrf;
+
+ if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
+  perror("opening socket");
+  exit(-1);
+ }
+ for (vrf=1;vrf<=VRF_MAX;vrf++){
+  if(ioctl(fd, SIOCGETVRF, vrf) < 0){
+   if (errno != ENOENT){
+    perror("ioctl");
+    exit(-1);
+   }
+  } else {
+   /* FIXME: List the interfaces attached to the VRF */
+   printf("VRF ID=%d\n", vrf);
+  }
+ }
+ close(fd);
+ return 0;
+}
+
+int do_ipvrf(int argc, char **argv)
+{
+ if (argc > 0) {
+  if (matches(*argv, "add") == 0)
+   return do_vrf(SIOCADDVRF, argc-1, argv+1);
+  if (matches(*argv, "del") == 0)
+   return do_vrf(SIOCDELVRF, argc-1, argv+1);
+  if (matches(*argv, "show") == 0 ||
+      matches(*argv, "lst") == 0 ||
+      matches(*argv, "list") == 0)
+   return ipvrf_list(argc-1, argv+1);
+  if (matches(*argv, "help") == 0)
+   usage();
+ } else
+  return ipvrf_list(0, NULL);
+
+ fprintf(stderr, "Command \"%s\" is unknown, try \"ip vrf help\".\n",
*argv);
+ exit(-1);
+}

    -Jorge

==============================================================
Jorge Boncompte - Tecnico de sistemas
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
--------------------------------------------------------------
jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be done.
==============================================================

[linux-vrf-core] More patches

[Jorge B. [DTI2] <jo...@dt...>]

    Hi James,

    More patches here and more on the way... BTW My setup is working
wonderfully  :)

- Patch to netkit-telnet-0.17 (I myself use debian too), added support to
tell what VRF we want to use, usefull to test and configure routers ;)
- Patch to kernel to add a SIOCGETVRF, yes I know it's a hack but I like to
known what VRFs exists.

    Best regards,

    -Jorge

==============================================================
Jorge Boncompte - Tecnico de sistemas
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5   14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
--------------------------------------------------------------
jo...@dt... _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be done.
==============================================================

diff -uNr netkit-telnet-0.17/telnet/commands.cc
netkit-telnet-0.17-jorge/telnet/commands.cc
--- netkit-telnet-0.17/telnet/commands.cc Fri Oct 25 18:36:18 2002
+++ netkit-telnet-0.17-jorge/telnet/commands.cc Fri Oct 25 18:00:18 2002
@@ -89,6 +89,7 @@
 #if defined(HAS_IPPROTO_IP) && defined(IP_TOS)
 int tos = -1;
 #endif /* defined(HAS_IPPROTO_IP) && defined(IP_TOS) */
+int vrf = -1;

 static unsigned long sourceroute(char *arg, char **cpp, int *lenp);

@@ -1786,7 +1787,7 @@
       NI_NUMERICHOST | NI_NUMERICSERV);

  printf("Trying %s...\n", name);
- x = nlink.connect(debug, tmpaddr, srp, srlen, tos);
+ x = nlink.connect(debug, tmpaddr, srp, srlen, tos, vrf);
  if (!x)
      goto err;
  else if (x==1)
diff -uNr netkit-telnet-0.17/telnet/main.cc
netkit-telnet-0.17-jorge/telnet/main.cc
--- netkit-telnet-0.17/telnet/main.cc Fri Oct 25 18:36:18 2002
+++ netkit-telnet-0.17-jorge/telnet/main.cc Fri Oct 25 18:31:22 2002
@@ -84,7 +84,7 @@
     fprintf(stderr, "Usage: %s %s%s%s%s\n",
      prompt,
      "[-4] [-6] [-8] [-E] [-L] [-a] [-d] [-e char] [-l user]",
-     "\n\t[-n tracefile]",
+     "\n\t[-n tracefile] [-Z vrf]",
 #ifdef TN3270
      "\n\t"
      "[-noasynch] [-noasynctty] [-noasyncnet] [-r] [-t transcom]\n\t",
@@ -108,7 +108,7 @@
  int ch;
  char *user;
  int family;
-
+
  tninit();  /* Clear out things */
 #if defined(CRAY) && !defined(__STDC__)
  _setlist_init(); /* Work around compiler bug */
@@ -127,7 +127,7 @@
  rlogin = (strncmp(prompt, "rlog", 4) == 0) ? '~' : _POSIX_VDISABLE;
  autologin = -1;

- while ((ch = getopt(argc, argv, "468EKLS:X:ade:k:l:n:rt:x")) != EOF) {
+ while ((ch = getopt(argc, argv, "468EKLS:X:Z:ade:k:l:n:rt:x")) != EOF) {
   switch(ch) {
   case '4':
    family = AF_INET;
@@ -173,6 +173,14 @@
    break;
   case 'X':
           // disable authentication type "optarg"
+   break;
+  case 'Z':
+   extern int vrf;
+   vrf = strtol(optarg, 0, 0);
+   if (vrf < 1 || vrf > 255) {
+    printf("vrf %u out of range\n", vrf);
+    exit(1);
+   }
    break;
   case 'a':
    autologin = 1;
Binary files netkit-telnet-0.17/telnet/main.o and
netkit-telnet-0.17-jorge/telnet/main.o differ
diff -uNr netkit-telnet-0.17/telnet/netlink.cc
netkit-telnet-0.17-jorge/telnet/netlink.cc
--- netkit-telnet-0.17/telnet/netlink.cc Fri Oct 25 18:36:18 2002
+++ netkit-telnet-0.17-jorge/telnet/netlink.cc Fri Oct 25 18:08:39 2002
@@ -82,7 +82,7 @@
 }

 int netlink::connect(int debug, struct addrinfo *addr,
-       char *srcroute, int srlen, int tos)
+       char *srcroute, int srlen, int tos, int vrf)
 {
     int on=1;

@@ -117,6 +117,10 @@

     if (debug && setsockopt(net, SOL_SOCKET, SO_DEBUG, &on, sizeof(on)) <
0) {
  perror("setsockopt (SO_DEBUG)");
+    }
+
+    if (vrf && setsockopt(net, SOL_SOCKET, SO_VRF, (char *)&vrf,
sizeof(vrf)) < 0) {
+ perror("setsockopt (SO_VRF)");
     }

     if (::connect(net, addr->ai_addr, addr->ai_addrlen) < 0) {
diff -uNr netkit-telnet-0.17/telnet/netlink.h
netkit-telnet-0.17-jorge/telnet/netlink.h
--- netkit-telnet-0.17/telnet/netlink.h Fri Oct 25 18:36:18 2002
+++ netkit-telnet-0.17-jorge/telnet/netlink.h Fri Oct 25 17:57:02 2002
@@ -8,7 +8,7 @@

     int connect(int debug, struct addrinfo *hostaddr,
   char *srcroute, int srlen,
-  int tos);
+  int tos, int vrf);
     void close(int doshutdown);

     int setdebug(int debug);

diff -uNr linux-2.4.20pre11/include/linux/sockios.h
linux-2.4.20pre11-jorge/include/linux/sockios.h
--- linux-2.4.20pre11/include/linux/sockios.h Fri Oct 18 19:52:15 2002
+++ linux-2.4.20pre11-jorge/include/linux/sockios.h Wed Oct 23 17:30:50 2002
@@ -110,6 +110,7 @@

 #define SIOCADDVRF      0x8986  /* add VRF   */
 #define SIOCDELVRF      0x8987  /* del VRF    */
+#define SIOCGETVRF      0x8988  /* get VRF    */

 /* bonding calls */

diff -uNr linux-2.4.20pre11/net/ipv4/af_inet.c
linux-2.4.20pre11-jorge/net/ipv4/af_inet.c
--- linux-2.4.20pre11/net/ipv4/af_inet.c Fri Oct 18 19:52:15 2002
+++ linux-2.4.20pre11-jorge/net/ipv4/af_inet.c Wed Oct 23 18:06:54 2002
@@ -132,6 +132,7 @@
 extern void ip_mc_drop_socket(struct sock *sk);
 extern int fib_add_vrf(unsigned char vrf);
 extern int fib_del_vrf(unsigned char vrf);
+extern int fib_get_vrf(unsigned char vrf);

 #ifdef CONFIG_DLCI
 extern int dlci_ioctl(unsigned int, void*);
@@ -935,6 +936,12 @@
   case SIOCDELVRF:
    lock_kernel();
    err = fib_del_vrf((unsigned char)arg);
+   unlock_kernel();
+   return err;
+
+  case SIOCGETVRF:
+   lock_kernel();
+   err = fib_get_vrf((unsigned char)arg);
    unlock_kernel();
    return err;

diff -uNr linux-2.4.20pre11/net/ipv4/fib_rules.c
linux-2.4.20pre11-jorge/net/ipv4/fib_rules.c
--- linux-2.4.20pre11/net/ipv4/fib_rules.c Fri Oct 18 19:52:15 2002
+++ linux-2.4.20pre11-jorge/net/ipv4/fib_rules.c Wed Oct 23 19:24:30 2002
@@ -476,6 +490,18 @@

  write_unlock_bh(&fib_rules_lock[vrf]);

+ return 0;
+}
+
+int fib_get_vrf(unsigned char vrf) {
+
+ if (vrf < 0 || vrf > VRF_MAX) {
+  return -EBADF;
+ }
+ if (!fib_rules[vrf]) {
+  return -ENOENT;
+ }
+
  return 0;
 }

RE: [linux-vrf-core] "ip route show vrf X"

[Robert M. <ro...@ip...>]

Hi James,

Please see inline...

> -----Original Message-----
> From: James R. Leu [mailto:jl...@mi...]
> Sent: Friday, October 25, 2002 9:46 AM
> To: Robert May
> Cc: lin...@li...
> Subject: Re: [linux-vrf-core] "ip route show vrf X"
>
>
> Hello,
>
> On Fri, Oct 25, 2002 at 08:31:33AM -0700, Robert May wrote:
> >
> > Hi James,
> >
> > One other behavior I observed is that periodically, my system seems to
> > freeze for 1-2 seconds.  As far as I know, I am not executing
> anything to
> > initiate this behavior.
> >
> > Has anyone else encountered this ?
>
> You're the first one to report this bug :-)
>
> > Have you introduced any blocking calls into the kernel patch ?
>
> Not that I know, but I do modify some search code associated with
> TCP, UDP, and raw sockets.  Were you running any aplications that would
> have been creating new sockets at these times?  Now when you say
> 'periodically'
> how often?  At regualr intervals?  I'm wondering if there is some sort of
> TCP timer that is firing and executing a long search with a lock held.

It seems to be occurring somewhat randomly from what I can tell.  I am not
running any other applications that are creating sockets.

The only event I can think that might be causing this is traffic received on
one of the interfaces.  I have one Windows PC that's connected to one of the
networks, and if it's gateway is down (say, if I unplug the ethernet cable),
it starts spitting lots of traffic onto the internal network.  I will try to
see if I can duplicate the problem this way..

>
> > When compiling my kernel, I have only enabled the following (other then
> > defaults):
> >  * Networking Options -> Advanced Router -> Policy Routing
> >  * Networking Options -> GRE tunneling support (loadable module)
> >  * Network Device Support -> Approp. NIC support
>
> Just for for a sanity check: what NIC are you using, and have you
> run this same kernel version without VRF support?

I'm using 3c900 series drivers.  I have used this build several times,
though never with the 2.4.19 kernel specifically.

>
> Thanks!
>
> >
> > Thanks,
> > -Robert.
> >
> >
> > > -----Original Message-----
> > > From: lin...@li...
> > > [mailto:lin...@li...]On Behalf
> Of James R.
> > > Leu
> > > Sent: Friday, October 25, 2002 8:52 AM
> > > To: Robert May
> > > Cc: lin...@li...
> > > Subject: Re: [linux-vrf-core] "ip route show vrf X"
> > >
> > >
> > > Thank you for your bug reports.  The next release will
> contain the fixes.
> > > I expect to make the next release early next week.
> > >
> > >
> > > On Fri, Oct 25, 2002 at 07:38:05AM -0700, Robert May wrote:
> > > >
> > > > Hi all,
> > > >
> > > > While testing the iproute2 patch, I discovered the
> following behavior:
> > > >
> > > > Giving command "ip route show vrf X" causes ip utility to
> > > display all routes
> > > > for all VRFs, regardless of vrf SELECTOR.  In other words, it
> > > ignores the
> > > > selector.  I think that if "vrf X" selector is not given, all
> > > routes should
> > > > be shown.  If provided, it should only display the routes
> for that VRF.
> > > >
> > > > Attached patch provides the fix for this.  It should be
> applied after
> > > > linux-vrf iproute2 patch.
> > > >
> > > > Best regards,
> > > > -Robert.
> > >
> > >
> > >
> > > --
> > > James R. Leu
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Influence the future
> > > of Java(TM) technology. Join the Java Community
> > > Process(SM) (JCP(SM)) program now.
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> > > _______________________________________________
> > > linux-vrf-core mailing list
> > > lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linux-vrf-core
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> > _______________________________________________
> > linux-vrf-core mailing list
> > lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-vrf-core
>
> --
> James R. Leu
>
>

Re: [linux-vrf-core] "ip route show vrf X"

[James R. L. <jl...@mi...>]

Hello,

On Fri, Oct 25, 2002 at 08:31:33AM -0700, Robert May wrote:
> 
> Hi James,
> 
> One other behavior I observed is that periodically, my system seems to
> freeze for 1-2 seconds.  As far as I know, I am not executing anything to
> initiate this behavior.
> 
> Has anyone else encountered this ?

You're the first one to report this bug :-)

> Have you introduced any blocking calls into the kernel patch ?

Not that I know, but I do modify some search code associated with
TCP, UDP, and raw sockets.  Were you running any aplications that would
have been creating new sockets at these times?  Now when you say 'periodically'
how often?  At regualr intervals?  I'm wondering if there is some sort of
TCP timer that is firing and executing a long search with a lock held.

> When compiling my kernel, I have only enabled the following (other then
> defaults):
>  * Networking Options -> Advanced Router -> Policy Routing
>  * Networking Options -> GRE tunneling support (loadable module)
>  * Network Device Support -> Approp. NIC support

Just for for a sanity check: what NIC are you using, and have you
run this same kernel version without VRF support?

Thanks!

> 
> Thanks,
> -Robert.
> 
> 
> > -----Original Message-----
> > From: lin...@li...
> > [mailto:lin...@li...]On Behalf Of James R.
> > Leu
> > Sent: Friday, October 25, 2002 8:52 AM
> > To: Robert May
> > Cc: lin...@li...
> > Subject: Re: [linux-vrf-core] "ip route show vrf X"
> >
> >
> > Thank you for your bug reports.  The next release will contain the fixes.
> > I expect to make the next release early next week.
> >
> >
> > On Fri, Oct 25, 2002 at 07:38:05AM -0700, Robert May wrote:
> > >
> > > Hi all,
> > >
> > > While testing the iproute2 patch, I discovered the following behavior:
> > >
> > > Giving command "ip route show vrf X" causes ip utility to
> > display all routes
> > > for all VRFs, regardless of vrf SELECTOR.  In other words, it
> > ignores the
> > > selector.  I think that if "vrf X" selector is not given, all
> > routes should
> > > be shown.  If provided, it should only display the routes for that VRF.
> > >
> > > Attached patch provides the fix for this.  It should be applied after
> > > linux-vrf iproute2 patch.
> > >
> > > Best regards,
> > > -Robert.
> >
> >
> >
> > --
> > James R. Leu
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> > _______________________________________________
> > linux-vrf-core mailing list
> > lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-vrf-core
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> linux-vrf-core mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-core

-- 
James R. Leu

RE: [linux-vrf-core] "ip route show vrf X"

[Robert M. <ro...@ip...>]

Hi James,

One other behavior I observed is that periodically, my system seems to
freeze for 1-2 seconds.  As far as I know, I am not executing anything to
initiate this behavior.

Has anyone else encountered this ?

Have you introduced any blocking calls into the kernel patch ?

When compiling my kernel, I have only enabled the following (other then
defaults):
 * Networking Options -> Advanced Router -> Policy Routing
 * Networking Options -> GRE tunneling support (loadable module)
 * Network Device Support -> Approp. NIC support

Thanks,
-Robert.


> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of James R.
> Leu
> Sent: Friday, October 25, 2002 8:52 AM
> To: Robert May
> Cc: lin...@li...
> Subject: Re: [linux-vrf-core] "ip route show vrf X"
>
>
> Thank you for your bug reports.  The next release will contain the fixes.
> I expect to make the next release early next week.
>
>
> On Fri, Oct 25, 2002 at 07:38:05AM -0700, Robert May wrote:
> >
> > Hi all,
> >
> > While testing the iproute2 patch, I discovered the following behavior:
> >
> > Giving command "ip route show vrf X" causes ip utility to
> display all routes
> > for all VRFs, regardless of vrf SELECTOR.  In other words, it
> ignores the
> > selector.  I think that if "vrf X" selector is not given, all
> routes should
> > be shown.  If provided, it should only display the routes for that VRF.
> >
> > Attached patch provides the fix for this.  It should be applied after
> > linux-vrf iproute2 patch.
> >
> > Best regards,
> > -Robert.
>
>
>
> --
> James R. Leu
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> linux-vrf-core mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-core
>
>

Re: [linux-vrf-core] "ip route show vrf X"

[James R. L. <jl...@mi...>]

Thank you for your bug reports.  The next release will contain the fixes.
I expect to make the next release early next week.


On Fri, Oct 25, 2002 at 07:38:05AM -0700, Robert May wrote:
> 
> Hi all,
> 
> While testing the iproute2 patch, I discovered the following behavior:
> 
> Giving command "ip route show vrf X" causes ip utility to display all routes
> for all VRFs, regardless of vrf SELECTOR.  In other words, it ignores the
> selector.  I think that if "vrf X" selector is not given, all routes should
> be shown.  If provided, it should only display the routes for that VRF.
> 
> Attached patch provides the fix for this.  It should be applied after
> linux-vrf iproute2 patch.
> 
> Best regards,
> -Robert.



-- 
James R. Leu

[linux-vrf-core] "ip route show vrf X"

[Robert M. <ro...@ip...>]

Hi all,

While testing the iproute2 patch, I discovered the following behavior:

Giving command "ip route show vrf X" causes ip utility to display all routes
for all VRFs, regardless of vrf SELECTOR.  In other words, it ignores the
selector.  I think that if "vrf X" selector is not given, all routes should
be shown.  If provided, it should only display the routes for that VRF.

Attached patch provides the fix for this.  It should be applied after
linux-vrf iproute2 patch.

Best regards,
-Robert.

[linux-vrf-core] "vrfctl -d 1" crashes kernel if vrf 1 doesn't exist

[Robert M. <ro...@ip...>]

Hi all,

I found that trying to delete a VRF that doesn't exist causes kernel to
crash.  I think the problem is probably in linux kernel changes, not in
vrfctl.c.

Perhaps in ../linux-2.4.19/net/ipv4/fib_rules.c in function fib_del_vrf() ?

Best regards,
-Robert.

Re: [linux-vrf-core] First code release

[James R. L. <jl...@mi...>]

I think this goes along with my uncertainty of how to handle the loopback
interface.  I think there are two ways to think about these: 

1. Each host (no matter how many virtual servers or vrfs) is still a single
host.  It has to have a single identity to prevent from affecting all of
the system software the depends on the hosts identity.

2. The whole point of vrf and virtual servers is to make each server or vrf
completly independent from each other therefore hostname etc should be
contained within the virtual server or vrf.

I'm not sure which way is the correct way yet.  I think that there
is a need and an application for both. *shrug*

Jim


On Mon, Mar 11, 2002 at 12:16:03AM -0500, Nick Eggleston wrote:
> 
> Another thought...
> 
> Along the line of the s_context work, it would be good to consider other
> kernel net global vars that should be moved into the vrf structure.
> "hostname" and "domainname" come immediately to mind.  There are
> probably others.
> 
> --Nick
> 

-- 
James R. Leu

Re: [linux-vrf-core] First code release

[James R. L. <jl...@mi...>]

Hello,

I agree with all of your suggestions.  I think we ca trim it down
to 3 big tasks (many details within task ;-).

-each process needs to be assigned to a vrf.  I was hoping to build on the
 "many virtual servers" by ja...@so...
-inter-vrf routing.  The current patch doesn't support this.  I think
 this is going to require a little re-working of the "next hop" code
 in the IP stack.  I already have to change this to support my mpls-linux
 work, so I will make sure linux-vrf benifits from it :-)
-aggregate VRF data structure.  Part of the purpose of this first patch was
 to identify all of the per VRF dependent structures.  I want to make sure
 we have found all of them (this will require digging into netfilter stuff
 a bit more).  Once they are all identified, then I would like to work on
 aggregating them into a common VRF structure.

On Sun, Mar 10, 2002 at 11:55:55PM -0500, Nick Eggleston wrote:
> Thanks Jim,
> 
> Here are my thoughts while reading the patch...
> 
> 1.  Processes need to have a vrf associated with them.  All
> sockets/packets generated by the process should by default be members of
> the vrf.  Special kernel calls (which you already created) should be
> needed to set particular sockets into particular vrfs.
> 
> We could then write a simple "chvrf" that works like chroot, allowing us
> to use "netstat" and suck without recoding them.
> 
> Once an interface is in a particular vrf, I think it (and member
> connections (via netstat)) should not be visible to processes from other
> vrfs.  At least, they shoud not be visible without special comands/perms.
> 
> 2.  Inter-vrf communication.  Once we get vrfs up and running, we need a
> way to selectivel allow traffic to pass between them.  Probably new route
> targets.  (maybe you did this already!)
> 
> 3.  Netfilter implications.  By default, we should probably virtualize the
> netfilter tables on a per-vrf basis, to continue the vision of having vrfs
> be transparent to most programs and systems.  Again, though, we might want
> to add some new code to make specific netfilter rules vrf-aware.
> 
> 
> 4.  Instead of var[vrf] (making fixed-size arrays out of single vars to
> support vrfs), I would strongly suggest moving to a a "struct vrf" model
> and dynamicaly allocating new ones upon vrf-creation.  That way, we
> collect all of the virtualized entities into a single struture.  Vrfs,
> then, would go from being "unsigned char" internally to "struct vrf *"
> 
> 5.  Once (if?) we move to dynamic structs, we could consider identifying
> vrfs by name instead of number.  This would be in keeping with the way
> that cisco defines and uses them.
> 
> Great work!!!
> 
> What do you think?
> 
> --nick
> 
> 
> On Wed, 6 Mar 2002, James R. Leu wrote:
> 
> > On Wed, Mar 06, 2002 at 04:16:43PM -0500, Nick Eggleston wrote:
> > > Jim,
> > >
> > > Could you take a few minutes and type up a note that describes from a
> > > system level the way you have implemented this?  How are you
> > > conceptualizing the kernel mods to support the vrfs?
> >
> > The base change of this implementation is make the fib_table array
> > a double index array.  Prior to this it was only indexed by the table id.
> > I added a vrf id.  So everywhere that create/gets/modifies a table had to
> > have an extra piece of info added to the call.
> >
> > The other change to the 'fib' is that the fib_rules are now index by vrf
> > as well.  fib_rules are the structuire behind maintaining the order in which
> > tables do route lookups.  (ie the local table alway is looked up before the
> > main table, whicb is before the default table).  By allowing VRFs to have
> > rules, policy routing and teh like still work within a VRF (I think
> > NAT will work as well!).
> >
> > The next large change is how the tcp/udp/raw sockets account for used port
> > numbers.  Every where a lookup or a comparison is made I add the vrf to
> > the mix.
> >
> > The other place where VRF show s up, the route cache, route messages,
> > link messages, rules messages, socket hash tables, skbs.
> >
> > This is a very quick overview.  I will try to come up with a better one
> > and add it to the README.  Maybe some of the questions you guys come back
> > with will hlep form this description.
> >
> > Jim
> >
> > > Thanks!
> > >
> > > Nick
> > >
> > > On Wed, 6 Mar 2002, James R. Leu wrote:
> > >
> > > > Hey guys,
> > > >
> > > > I know its been a LONG time since we talked about this, but I have been
> > > > thinking about it, and I've done some work.  I placed my first crack at a
> > > > VRF implementation for the kernel.  Take a look at the README inside it
> > > > then post questions :-)
> > > >
> > > > Jim
> > > >
> > >
> >
> >
> 
> -- 
> Nick Eggleston
> Consultant
> Data Communications Consulting, Inc.
> 6320 Rucker Road, Suite E
> Indianapolis, IN  46220
> 317/726-0295 x18
> 317/202-2445 (fax)
> 
> 
> 

-- 
James R. Leu

Re: [linux-vrf-core] First code release

[Nick E. <ni...@dc...>]

Another thought...

Along the line of the s_context work, it would be good to consider other
kernel net global vars that should be moved into the vrf structure.
"hostname" and "domainname" come immediately to mind.  There are
probably others.

--Nick

Re: [linux-vrf-core] First code release

[Nick E. <ni...@dc...>]

Thanks Jim,

Here are my thoughts while reading the patch...

1.  Processes need to have a vrf associated with them.  All
sockets/packets generated by the process should by default be members of
the vrf.  Special kernel calls (which you already created) should be
needed to set particular sockets into particular vrfs.

We could then write a simple "chvrf" that works like chroot, allowing us
to use "netstat" and suck without recoding them.

Once an interface is in a particular vrf, I think it (and member
connections (via netstat)) should not be visible to processes from other
vrfs.  At least, they shoud not be visible without special comands/perms.

2.  Inter-vrf communication.  Once we get vrfs up and running, we need a
way to selectivel allow traffic to pass between them.  Probably new route
targets.  (maybe you did this already!)

3.  Netfilter implications.  By default, we should probably virtualize the
netfilter tables on a per-vrf basis, to continue the vision of having vrfs
be transparent to most programs and systems.  Again, though, we might want
to add some new code to make specific netfilter rules vrf-aware.


4.  Instead of var[vrf] (making fixed-size arrays out of single vars to
support vrfs), I would strongly suggest moving to a a "struct vrf" model
and dynamicaly allocating new ones upon vrf-creation.  That way, we
collect all of the virtualized entities into a single struture.  Vrfs,
then, would go from being "unsigned char" internally to "struct vrf *"

5.  Once (if?) we move to dynamic structs, we could consider identifying
vrfs by name instead of number.  This would be in keeping with the way
that cisco defines and uses them.

Great work!!!

What do you think?

--nick


On Wed, 6 Mar 2002, James R. Leu wrote:

> On Wed, Mar 06, 2002 at 04:16:43PM -0500, Nick Eggleston wrote:
> > Jim,
> >
> > Could you take a few minutes and type up a note that describes from a
> > system level the way you have implemented this?  How are you
> > conceptualizing the kernel mods to support the vrfs?
>
> The base change of this implementation is make the fib_table array
> a double index array.  Prior to this it was only indexed by the table id.
> I added a vrf id.  So everywhere that create/gets/modifies a table had to
> have an extra piece of info added to the call.
>
> The other change to the 'fib' is that the fib_rules are now index by vrf
> as well.  fib_rules are the structuire behind maintaining the order in which
> tables do route lookups.  (ie the local table alway is looked up before the
> main table, whicb is before the default table).  By allowing VRFs to have
> rules, policy routing and teh like still work within a VRF (I think
> NAT will work as well!).
>
> The next large change is how the tcp/udp/raw sockets account for used port
> numbers.  Every where a lookup or a comparison is made I add the vrf to
> the mix.
>
> The other place where VRF show s up, the route cache, route messages,
> link messages, rules messages, socket hash tables, skbs.
>
> This is a very quick overview.  I will try to come up with a better one
> and add it to the README.  Maybe some of the questions you guys come back
> with will hlep form this description.
>
> Jim
>
> > Thanks!
> >
> > Nick
> >
> > On Wed, 6 Mar 2002, James R. Leu wrote:
> >
> > > Hey guys,
> > >
> > > I know its been a LONG time since we talked about this, but I have been
> > > thinking about it, and I've done some work.  I placed my first crack at a
> > > VRF implementation for the kernel.  Take a look at the README inside it
> > > then post questions :-)
> > >
> > > Jim
> > >
> >
>
>

-- 
Nick Eggleston
Consultant
Data Communications Consulting, Inc.
6320 Rucker Road, Suite E
Indianapolis, IN  46220
317/726-0295 x18
317/202-2445 (fax)

Re: [linux-vrf-core] First code release

[James R. L. <jl...@mi...>]

On Wed, Mar 06, 2002 at 04:16:43PM -0500, Nick Eggleston wrote:
> Jim,
> 
> Could you take a few minutes and type up a note that describes from a
> system level the way you have implemented this?  How are you
> conceptualizing the kernel mods to support the vrfs?

The base change of this implementation is make the fib_table array
a double index array.  Prior to this it was only indexed by the table id.
I added a vrf id.  So everywhere that create/gets/modifies a table had to
have an extra piece of info added to the call.

The other change to the 'fib' is that the fib_rules are now index by vrf
as well.  fib_rules are the structuire behind maintaining the order in which
tables do route lookups.  (ie the local table alway is looked up before the
main table, whicb is before the default table).  By allowing VRFs to have
rules, policy routing and teh like still work within a VRF (I think
NAT will work as well!).

The next large change is how the tcp/udp/raw sockets account for used port
numbers.  Every where a lookup or a comparison is made I add the vrf to
the mix.

The other place where VRF show s up, the route cache, route messages, 
link messages, rules messages, socket hash tables, skbs.

This is a very quick overview.  I will try to come up with a better one
and add it to the README.  Maybe some of the questions you guys come back
with will hlep form this description.

Jim

> Thanks!
> 
> Nick
> 
> On Wed, 6 Mar 2002, James R. Leu wrote:
> 
> > Hey guys,
> >
> > I know its been a LONG time since we talked about this, but I have been
> > thinking about it, and I've done some work.  I placed my first crack at a
> > VRF implementation for the kernel.  Take a look at the README inside it
> > then post questions :-)
> >
> > Jim
> >
> 

-- 
James R. Leu