Skip to contentSkip to conversation

RFC: Patch to add support for multiple multicast routing tables.

PATCH Ben Greear 2 participants 3 messages Jun 25, 2008

Subsystems (3)
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

In order to run multiple Xorp instances and treat different groups of interfaces as being in their own virtual router, I had to update the ipv4/ipmr.c logic to support multiple routing tables.

I will be attempting to push the cooresponding xorp changes to it's maintainers if this is accepted into the kernel. It should be fully backwards compatible with existing xorp and other multicast routing tools. It does change the procfs output slightly, adding a TableId column.

The original patch was written by me, and then Patrick McHardy fixed up my cruft and made it much smaller and with better locking. I then fixed a few bugs I found while testing with my modified xorp.

The attached patch is against 2.6.25.4 + hacks. It has a few rejects against 2.6.26.rc7, but I will fix those sooner rather than later if the patch is otherwise deemed worthy.

Please let me know if this stands a chance of inclusion.

Thanks,
Ben

Signature · 1 line
Ben Greear <[email protected]> Candela Technologies Inc  http://www.candelatech.com
include/linux/mroute.h +36 -0
index 35a8277..d6abe2a 100644
@@ -30,11 +30,16 @@
 #define SIOCGETSGCNT	(SIOCPROTOPRIVATE+1)
 #define SIOCGETRPF	(SIOCPROTOPRIVATE+2)
 
+#define SIOCGETVIFCNT_NG	(SIOCPROTOPRIVATE+3)
+#define SIOCGETSGCNT_NG		(SIOCPROTOPRIVATE+4)
+
 #define MAXVIFS		32	
 typedef unsigned long vifbitmap_t;	/* User mode code depends on this lot */
 typedef unsigned short vifi_t;
 #define ALL_VIFS	((vifi_t)(-1))
 
+#define DFLT_MROUTE_TBL RT_TABLE_MAIN
+
 /*
  *	Same idea as select
  */
@@ -60,6 +65,11 @@ struct vifctl {
 	struct in_addr vifc_rmt_addr;	/* IPIP tunnel addr */
 };
 
+struct vifctl_ng {
+	struct vifctl vif;
+	unsigned table_id;
+};
+
 #define VIFF_TUNNEL	0x1	/* IPIP tunnel */
 #define VIFF_SRCRT	0x2	/* NI */
 #define VIFF_REGISTER	0x4	/* register vif	*/
@@ -80,6 +90,18 @@ struct mfcctl
 	int	     mfcc_expire;
 };
 
+struct mfcctl_ng
+{
+	struct mfcctl mfc;
+	unsigned int table_id;
+};
+
+struct mrt_sockopt_simple
+{
+	unsigned int optval;
+	unsigned int table_id;
+};
+
 /* 
  *	Group count retrieval for mrouted
  */
@@ -93,6 +115,12 @@ struct sioc_sg_req
 	unsigned long wrong_if;
 };
 
+struct sioc_sg_req_ng
+{
+	struct sioc_sg_req req;
+	unsigned int table_id;
+};
+
 /*
  *	To get vif packet counts
  */
@@ -106,6 +134,12 @@ struct sioc_vif_req
 	unsigned long obytes;	/* Out bytes */
 };
 
+struct sioc_vif_req_ng
+{
+	struct sioc_vif_req vif;
+	unsigned int table_id;
+};
+
 /*
  *	This is the format the mroute daemon expects to see IGMP control
  *	data. Magically happens to be like an IP packet as per the original
@@ -156,6 +190,8 @@ struct vif_device
 	unsigned short	flags;			/* Control flags 		*/
 	__be32		local,remote;		/* Addresses(remote for tunnels)*/
 	int		link;			/* Physical interface index	*/
+	int		vif_index;		/* Index in vif_table		*/
+	unsigned int	table_id;               /* table-id that this vif belongs to */
 };
 
 #define VIFF_STATIC 0x8000
include/linux/netdevice.h +9 -0
index 30064d7..c4761f1 100644
@@ -43,6 +43,10 @@
 
 #include <net/net_namespace.h>
 
+#ifdef CONFIG_IP_MROUTE
+struct ipmr_table;
+#endif
+
 struct vlan_group;
 struct ethtool_ops;
 struct netpoll_info;
@@ -728,6 +732,11 @@ struct net_device
 				     */
 	long dflt_skb_mark; /* Specify skb->mark for pkts received on this interface. */
 
+#ifdef CONFIG_IP_MROUTE
+	/* IPv4 Multicast Routing Table for tis device. */
+	struct ipmr_table* mrt_entry;
+#endif
+
 	/* bridge stuff */
 	struct net_bridge_port	*br_port;
 	/* macvlan */
net/core/dev.c +1 -0
index 617a49a..02b7f41 100644
@@ -120,6 +120,7 @@
 #include <linux/err.h>
 #include <linux/ctype.h>
 #include <linux/if_arp.h>
+#include <linux/mroute.h>
 
 #include "net-sysfs.h"
 
net/ipv4/ipmr.c +501 -232

1,448 lines not on this page · raw message

#1 lore raw
Quoted 20 lines · On Tue, 24 Jun 2008 17:50:51 -0700 Ben Greear <[email protected]> wrote:

In order to run multiple Xorp instances and treat different groups of interfaces as being in their own virtual router, I had to update the ipv4/ipmr.c logic to support multiple routing tables.

I will be attempting to push the cooresponding xorp changes to it's maintainers if this is accepted into the kernel. It should be fully backwards compatible with existing xorp and other multicast routing tools. It does change the procfs output slightly, adding a TableId column.

The original patch was written by me, and then Patrick McHardy fixed up my cruft and made it much smaller and with better locking. I then fixed a few bugs I found while testing with my modified xorp.

The attached patch is against 2.6.25.4 + hacks. It has a few rejects against 2.6.26.rc7,
but I will fix those sooner rather than later if the patch is otherwise deemed
worthy.

Quoted 4 lines

Please let me know if this stands a chance of inclusion.

Thanks,
Ben

Ben private ioctl's make it hard to handle 32bit/64bit compatiablity, and routing is better managed through rtnetlink. Doesn't XORP do netlink?

author
#2 lore raw
Quoted 24 lines · Stephen Hemminger
Quoted 20 lines · On Tue, 24 Jun 2008 17:50:51 -0700 Ben Greear <[email protected]> wrote:

In order to run multiple Xorp instances and treat different groups of interfaces as being in their own virtual router, I had to update the ipv4/ipmr.c logic to support multiple routing tables.

I will be attempting to push the cooresponding xorp changes to it's maintainers if this is accepted into the kernel. It should be fully backwards compatible with existing xorp and other multicast routing tools. It does change the procfs output slightly, adding a TableId column.

The original patch was written by me, and then Patrick McHardy fixed up my cruft and made it much smaller and with better locking. I then fixed a few bugs I found while testing with my modified xorp.

The attached patch is against 2.6.25.4 + hacks. It has a few rejects against 2.6.26.rc7, but I will fix those sooner rather than later if the patch is otherwise deemed worthy.

Please let me know if this stands a chance of inclusion.

Quoted 8 lines
Quoted 3 lines

Thanks,
Ben

Ben private ioctl's make it hard to handle 32bit/64bit compatiablity, and routing is better managed through rtnetlink. Doesn't XORP do netlink?

It seemed the path of least resistance, less the patch become even larger.

Xorp does use netlink, but not for multicast (or, at least, not for the part of multicast that talks to ipv4/ipmr.c). The patch to xorp to support multiple routing tables is not too large, and is backwards compat with older kernels (and bsd-ish systems I suppose.)

For 32/64 compat, how about we make the structs passed in 'attribute packed' ?

We can also make the table-id 'u32' or similar to guarantee the size of the member.

Thanks,
Ben

Signature · 1 line
Ben Greear <[email protected]> Candela Technologies Inc  http://www.candelatech.com