multiple routing tables review patch ready for simple testing.
The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src a kernel needs to be created with the option ROUTETABLES=N e.g. +optionsROUTETABLES=2 # max 16. 1 is back compatible. leaving this out will result in just a single routing table as per normal. the max is 16 but I have an artificial (even lower) at 8 but that may be gone by the time people try it :-) I ws informed early in this project that kernel routing tables should now be refered to as FIBs (forwarding Information base?). the new command setfib sets teh default fib for a process and all its decendents The ipfw command has been enhanced with fib and setfib commands netstat has been tweaked to cope with 1 table if used with setfib.. ipfw and setfib have man pages to look at. e.g. [EMAIL PROTECTED]:setfib -2 netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 127.0.0.1 127.0.0.1 UH 00lo0 172.28.0.0/24 link#3 UC 00 fxp0 172.28.0.1 00:c0:9f:41:cd:3c UHLW10 fxp0 1189 172.28.10.0/24 link#2 UC 00 bge1 [EMAIL PROTECTED]:setfib -0 netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default172.28.0.1 UGS 0 20 fxp0 10.1.1.209 172.28.0.1 UGHS00 fxp0 127.0.0.1 127.0.0.1 UH 0 20lo0 172.28.0.0/24 link#3 UC 00 fxp0 172.28.0.1 00:c0:9f:41:cd:3c UHLW30 fxp0 1188 172.28.10.0/24 link#2 UC 00 bge1 [EMAIL PROTECTED]: Currently it is IPV4 ONLY (other protocols will ignore the existance of other tables) there are two new sysctls. net.my_fibnum: 0 net.fibs: 3 Give it a test drive if you have any reason to want to do policy based routing or have multiple ISPs for different workloads etc. I'd like to get it out to a wider audience. all comments welcome. please read the file http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txtREV=5 for notes before using it. Julian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: RE: kern/123166: [re] CARP messages filtered by Realtek driver on 6.2]
The following reply was made to PR kern/123166; it has been noted by GNATS. From: Gavin Atkinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: [Fwd: RE: kern/123166: [re] CARP messages filtered by Realtek driver on 6.2] Date: Tue, 29 Apr 2008 09:13:29 +0100 Forwarded Message From: Auke Zaaiman [EMAIL PROTECTED] Date: Mon, 28 Apr 2008 22:27:32 +0200 Hi, Below the output of pciconf -l: [EMAIL PROTECTED]:8:0: class=0x02 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x02 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 And yes, we are able and willing to establish exactly which change has broken the card. Can you give me details on where I can fetch the source I need to update to? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: OS throws away large packets
Hi all,
I'm trying to implement Large Recieve Offload for an
Ethernet driver
on FreeBSD 6.3, but all my MTU packets are being thrown
by the OS.
I'm using mbuf chains in this imlpementation, each mbuf is
a cluster
of MCLBYTES bytes. They are linked by the m_next pointer.
The first packet being thrown away is 2945 bytes long.
Wireshark shows
the packet that is being passed to the OS is correct.
Do I need to set some OS parameter to make it recieve mbuf chains?
Please help.
Hi Yony,
I seem to remember some discussion about this list last
year see the
following threads:
http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm
l
http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm
l
From my limited reading of these threads just now and possibly bad
memory. It would seem that the MRU to MTU relationship is
defined in
the nic driver rather than
enforced further up the stack or at least that seamed to
be the case
with the bce driver.
Hope this is helpful,
Tom
Hi Tom,
From what I understand these threads are referring to the bce
hardware
configuration (bus configuration) and driver mbuf
allocation size. Am
I correct?
In my case I'm not trying to receive packets MTU from the
HW, but to
chain mbuf clusters, each is MCLBYTES long, and pass the
mbuf chain to
the OS.
Since tcpdump (analyzed by wireshark) catches the packets above the
driver and reports a good packet (and 2945 bytes long), I assume my
driver functionality is ok. From what I know tcpdump is supposed to
immitate the way the stack sees the packet, yet it is discarded.
My logic says there is an OS parameter handled by the
driver (at net
device init time for example) that will set the OS to receive large
mbuf chains, or a kernel tcp parameter. Is the tcp stack
submitted to
the mtu somehow?
I don't see where you've identified what version of the os you're
working with. There's a check in the 802.3 input path on earlier
systems to discard frames mtu. This was removed not too long ago
with LRO in mind; check the history of sys/net/if_ethersubr.c.
Sam
Hi Sam, I have mentioned working on 6.3.
FreeBSD 6.2 had this check in if_ethersubr.c / ether_input:
539 if (m-m_pkthdr.len
540 ETHER_MAX_FRAME(ifp, etype, m-m_flags M_HASFCS)) {
541 if_printf(ifp, discard oversize frame
542 (ether type %x flags %x len %u
max %lu)\n,
543 etype, m-m_flags, m-m_pkthdr.len,
544 ETHER_MAX_FRAME(ifp, etype,
545 m-m_flags
M_HASFCS));
546 ifp-if_ierrors++;
547 m_freem(m);
548 return;
549 }
Patching it was explained by neterion in
http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD.
This check no longer exists in 6.3, nor any other oversize packet
handling (I couldn't find any so far).
I also get no error prints from the OS.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [bfe] [panic] Serious error: bfe failed to map RX buffer
Hi, sorry for long delay, was too busy. So, I recheck return code of bus_dmamap_load(9) and its exactly ENOMEM. Here are fresh patch with your suggestions (diff with HEAD) Best Regards, Oleg Dolgov. 2008/4/17, Pyun YongHyeon [EMAIL PROTECTED]: On Thu, Apr 17, 2008 at 12:43:53AM +0300, quad wrote: Hi, FreeBSD amd64 7.0-RELEASE, ULE, SMP. On heavy loads bfe network driver after few messages Serious error: bfe failed to map RX buffer Serious error: bfe failed to map RX buffer Serious error: bfe failed to map RX buffer ... make kernel panic. Here patch. It would be even better if you can show me the return code of bus_dmamap_load(9). If the error code is not ENOMEM it requires more bus_dma(9) clean up(bfe(4) needs lots of bus_dma(9) fixing and I had no time so far.) Since the caller of bfe_list_newbuf() expects 0 or ENOBUFS it would be even better to return ENOBUFS for failure case instead of returning error code of bus_dmamap_load(9). -- Regards, Pyun YongHyeon if_bfe.diff Description: Binary data ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
I've been waiting for something like this. Linux has done policy routing for many many years and is very good at it. I prefer to use FreeBSD for routing though and this is a feature I have been waiting for :) Mainly to use with BGP , having multiple BGP routing tables. I would like it to be similar to Cisco's VRF or Juniper's routing instance, but maybe that's asking too much. We use it on our hardware routers for implementations such as having multiple bgp route tables and having customer bandwidth pricing change based on which routing table their traffic gets , say.. value customers, premium customers, customers who want only certain carriers in their bandwidth mix, etc. Would be fun to have support for FBSD with quagga/openbgpd etc.. and be able to use dscp for marking or any other policy based rule (source ip for instance). Thanks Julian.. This is a step forward in the right direction :) Julian Elischer wrote: Wilkinson, Alex wrote: 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: A little progress report From a recently installed (6.3) machine (plus patches) Ok, being ignorant to this, possibly a silly question: Why would i want or need multiple routing tables ? any time you wnat to base a route upon something other than just the destination address. It's basically called Policy based routing. Trivial examples: You have two ISPs and you want to send all SMTP via one link and all other traffic via the other. You have 3 ISPs and want all traffic from the accounting department to go via a particular path (that is encrypted) but regular office chatter to go via another. I have other more complex examples in my work. I'm sure others have more solid examples as well. google for policy routing. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
Paul wrote: I've been waiting for something like this. Linux has done policy routing for many many years and is very good at it. I prefer to use FreeBSD for routing though and this is a feature I have been waiting for :) Mainly to use with BGP , having multiple BGP routing tables. I would like it to be similar to Cisco's VRF or Juniper's routing instance, but maybe that's asking too much. We use it on our hardware routers for implementations such as having multiple bgp route tables and having customer bandwidth pricing change based on which routing table their traffic gets , say.. value customers, premium customers, customers who want only certain carriers in their bandwidth mix, etc. Would be fun to have support for FBSD with quagga/openbgpd etc.. and be able to use dscp for marking or any other policy based rule (source ip for instance). Thanks Julian.. This is a step forward in the right direction :) The interaction with routing daemons is something I don't know enough about. I need someone who knows routing daemons to tell how to correctly tweek code that sends routing events. I think it is possible that events from a particular FIB should only be reported to routing sockets that are associated with that FIB. but I'm not sure about this. This would mean running a separate instance of the routing daemon for each FIB (VRF?). Does this sound right to people? Julian Elischer wrote: Wilkinson, Alex wrote: 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: A little progress report From a recently installed (6.3) machine (plus patches) Ok, being ignorant to this, possibly a silly question: Why would i want or need multiple routing tables ? any time you wnat to base a route upon something other than just the destination address. It's basically called Policy based routing. Trivial examples: You have two ISPs and you want to send all SMTP via one link and all other traffic via the other. You have 3 ISPs and want all traffic from the accounting department to go via a particular path (that is encrypted) but regular office chatter to go via another. I have other more complex examples in my work. I'm sure others have more solid examples as well. google for policy routing. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123166: [re] CARP messages filtered by Realtek driver on 6.2 (regression)
Synopsis: [re] CARP messages filtered by Realtek driver on 6.2 (regression) Responsible-Changed-From-To: freebsd-net-gavin Responsible-Changed-By: gavin Responsible-Changed-When: Tue Apr 29 18:13:53 UTC 2008 Responsible-Changed-Why: I'll try and get further info from the submitter. To submitter: Firstly, does ifconfig re0 promisc make any difference? Secondly, you could try getting the most recent versions of the driver files from: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/re/if_re.c?rev=1.46.2.39;content-type=text%2Fplain http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/pci/if_rlreg.h?rev=1.51.2.13;content-type=text%2Fplain put the first into /usr/src/sys/dev/re and the second into /usr/src/sys/pci, recompile the kernel and test. Thirdly, if that hasn't fixed it, we need to establish when the breakage happened. The easiest way is to try different kernels (you shouldn't need to recompile the userland for this), and basically try to establish when the breakage was introduced to 6.x. Assuming you are using csup or cvsup to update your system, add the following line: *default date=2007.07.14.00.00.00 Then csup will bring sources down as they were on the 1st of August. Recompile, and see if CARP still works with that kernel. If so, move the date forward, and if not, go backwards in time. Some useful dates to try will probably be: 2007.02.01.00.00.00 2007.04.20.00.00.00 2007.05.01.00.00.00 2007.08.01.00.00.00 2007.09.20.00.00.00 2007.12.01.00.00.00 i.e. in the worst case, you may have to recompile your kernel three times to figure out between which of the above dates the breakage occured. (For reference, 6.2 was released on 2007.01.15, with 6.3 on 2008.01.18) http://www.freebsd.org/cgi/query-pr.cgi?pr=123166 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote: Paul wrote: I've been waiting for something like this. Linux has done policy routing for many many years and is very good at it. I prefer to use FreeBSD for routing though and this is a feature I have been waiting for :) Mainly to use with BGP , having multiple BGP routing tables. I would like it to be similar to Cisco's VRF or Juniper's routing instance, but maybe that's asking too much. We use it on our hardware routers for implementations such as having multiple bgp route tables and having customer bandwidth pricing change based on which routing table their traffic gets , say.. value customers, premium customers, customers who want only certain carriers in their bandwidth mix, etc. Would be fun to have support for FBSD with quagga/openbgpd etc.. and be able to use dscp for marking or any other policy based rule (source ip for instance). Thanks Julian.. This is a step forward in the right direction :) The interaction with routing daemons is something I don't know enough about. I need someone who knows routing daemons to tell how to correctly tweek code that sends routing events. I think it is possible that events from a particular FIB should only be reported to routing sockets that are associated with that FIB. but I'm not sure about this. This would mean running a separate instance of the routing daemon for each FIB (VRF?). Does this sound right to people? OpenBSD added[1] a field to the rt_msghdr to indicate/select the source/destination table. If we were to do the same at least OpenBGPB should work with fairly minimal changes. I think it's a sensible approach, too. A routing daemon wouldn't have to select over a dozen sockets to do what is needed and it will be much easier as well. If easily done, a way to bind a route socket to a table id would also be nice as it would easily make things work with multi table oblivious daemons. [1]http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/route.h.diff?r1=1.44r2=1.45f=h Julian Elischer wrote: Wilkinson, Alex wrote: 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote: A little progress report From a recently installed (6.3) machine (plus patches) Ok, being ignorant to this, possibly a silly question: Why would i want or need multiple routing tables ? any time you wnat to base a route upon something other than just the destination address. It's basically called Policy based routing. Trivial examples: You have two ISPs and you want to send all SMTP via one link and all other traffic via the other. You have 3 ISPs and want all traffic from the accounting department to go via a particular path (that is encrypted) but regular office chatter to go via another. I have other more complex examples in my work. I'm sure others have more solid examples as well. google for policy routing. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
Max Laier wrote: On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote: Paul wrote: I've been waiting for something like this. Linux has done policy routing for many many years and is very good at it. I prefer to use FreeBSD for routing though and this is a feature I have been waiting for :) Mainly to use with BGP , having multiple BGP routing tables. I would like it to be similar to Cisco's VRF or Juniper's routing instance, but maybe that's asking too much. We use it on our hardware routers for implementations such as having multiple bgp route tables and having customer bandwidth pricing change based on which routing table their traffic gets , say.. value customers, premium customers, customers who want only certain carriers in their bandwidth mix, etc. Would be fun to have support for FBSD with quagga/openbgpd etc.. and be able to use dscp for marking or any other policy based rule (source ip for instance). Thanks Julian.. This is a step forward in the right direction :) The interaction with routing daemons is something I don't know enough about. I need someone who knows routing daemons to tell how to correctly tweek code that sends routing events. I think it is possible that events from a particular FIB should only be reported to routing sockets that are associated with that FIB. but I'm not sure about this. This would mean running a separate instance of the routing daemon for each FIB (VRF?). Does this sound right to people? OpenBSD added[1] a field to the rt_msghdr to indicate/select the source/destination table. If we were to do the same at least OpenBGPB should work with fairly minimal changes. I would like someone who knows routing daemons to add this or tell me what needs to be done. I think it's a sensible approach, too. A routing daemon wouldn't have to select over a dozen sockets to do what is needed and it will be much easier as well. If easily done, a way to bind a route socket to a table id would also be nice as it would easily make things work with multi table oblivious daemons. I already have a socket option that works on routing sockets to bind them to a FIB. and /usr/bin/setfib can be used to make a fib-unaware process bind by default to a set fib. e.g. setfib -2 routed [args] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
-net added to broaden the conversation Paul wrote: The routing daemons run linked separate instances and create their own RIB. Take a look at Cisco's VRF implementation. You can even have interfaces assigned to the other routing instance so you could have em0.001 on routing instance 1 and em0.002 on routing instance 2 and without using any policies or firewall rules it would know that everything coming on em0.002 uses the #2 instance and routes accordingly. Same with Juniper. that's coming.. have patience.. we will have vimage (check google) plus multiple FIBS in each vimage.. for now use a firewall classifier. Then you can export RIB entries , say you have 5 BGP peers and you want to export 2 or 3 or all of them into the 'main' routing instance you can set up a policy to add those learned routes into the main instance and v-v. Linux behaves a little bit differently as you have to make an 'ip rule' entry for it but it doesn't use the firewall. for now this code asks you to use a firewall to classify incoming packets.. e.g. 100 setfib 2 ip from any to any in recv em0 I wish FreeBSD made a routing daemon that had total interactivity between the OS and daemon which would be great.. Quagga is good but the interaction is very annoying. Quagga has no idea what is going on on the kernel level and the kernel has no idea what is going on with quagga. I'm not a routing daemon expert.. Ex: if I add or remove a route from the kernel using 'route' command it does not remove it in quagga. Would be great to have a BGP/OSPF combo integrated into the kernel somehow. Sounds like Quagga needs to be made aware of routing events by listening for them on routing sockets. They are available. [chop] I have need for many many gigabit firewalls to put in front of many servers and the cost for the hardware firewall devices is way too much to deploy in the quantity that I need :/ Paul If you have a roadmap, then get involved.. :-) We need end user quidance on some of this stuff. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multiple routing tables review patch ready for simple testing.
Kevin Oberman wrote: Date: Tue, 29 Apr 2008 00:44:18 -0700 From: Julian Elischer [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src a kernel needs to be created with the option ROUTETABLES=N e.g. +optionsROUTETABLES=2 # max 16. 1 is back compatible. leaving this out will result in just a single routing table as per normal. the max is 16 but I have an artificial (even lower) at 8 but that may be gone by the time people try it :-) I ws informed early in this project that kernel routing tables should now be refered to as FIBs (forwarding Information base?). the new command setfib sets teh default fib for a process and all its decendents I have been working with big routers in my day job for years and it's really frustrating to not have this sort of capability when I work with FreeBSD, but I don't expect a general purpose OS to ever have the routing capabilities of a dedicated router. I think this will really, really be nice for my needs, though. As terminology goes, I think you have it slightly off. Modern routers have two classes of tables to move packets between interfaces: the RIB Routing information base) and the FIB (Forwarding Information Base). A router has multiple RIBs, usually one for each network layer protocol (IPv4 and IPv6, both unicast and multicast) and added RIBs for policy based routes. They may be further broken up by the protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static, connected, ...) The RIBs exports data, as needed to a single FIB which is used by the ASICs (hardware forwarding engines) to do the actual forwarding of the packets. In a real router, the forwarding of almost all packets is done in hardware with no real involvement by the processor that determines the routes. (N.B. This is a gross simplification of what modern routers do or can do, but I don't want to send a book to the list.) A general purpose OS is a different beast as it has no physical equivalent of the FIB. It may have multiple routing tables, though, to I think setrib would be a term less likely to cause confusion then setfib even though, in the case of your FreeBSD patches, it's really both. The way I see it the routing daemons (e.g. quagga) have the RIBS and the kernel has FIBS because it doesn't really know the big picture. If we need to change the terminology now is the time.. I asked for comments on terminology before and this is what we came up with.. but once it gets committed it gets set in stone. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/118975: [bge] [patch] Broadcom 5906 not handled by FreeBSD
Synopsis: [bge] [patch] Broadcom 5906 not handled by FreeBSD State-Changed-From-To: open-patched State-Changed-By: jhb State-Changed-When: Tue Apr 29 19:48:06 UTC 2008 State-Changed-Why: Patch committed to HEAD with minor tweaks. Responsible-Changed-From-To: freebsd-net-jhb Responsible-Changed-By: jhb Responsible-Changed-When: Tue Apr 29 19:48:06 UTC 2008 Responsible-Changed-Why: Patch committed to HEAD with minor tweaks. http://www.freebsd.org/cgi/query-pr.cgi?pr=118975 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple routing tables in action...
Julian Elischer wrote: The interaction with routing daemons is something I don't know enough about. I need someone who knows routing daemons to tell how to correctly tweek code that sends routing events. As long as it doesn't break anything... I think it is possible that events from a particular FIB should only be reported to routing sockets that are associated with that FIB. but I'm not sure about this. Please look at the Linux rtnetlink socket, they use a tag-length-value protocol for just this reason. It seems reasonable that PF_ROUTE messages have some kind of filter applied to them until a more complete story can be realised for this. Most PF_ROUTE clients are savvy enough to ignore message types on the socket that they don't understand. If there is a need to announce route adds and deletes on the socket on a per-fib basis, it seems reasonable to stash it in one of the unused fields (if we've got any of those..urp) and change the rtm_type field for now. However it does take us further down a route (no pun intended) of incremental growth which has real risk (lack of or insufficiently rich test cases, requirements drift etc) and seems to be incumbent with open source in general. This would mean running a separate instance of the routing daemon for each FIB (VRF?). Does this sound right to people? Sounds crap! You really, really don't want to be doing that if you can avoid it. Of course a lot of what's out there is not geared up to deal with it (and why would it be?) so it's fine for the time being, but it really, really can't be considered a complete, production-quality solution until the missing parts exist. cheers BMS P.S. I am impressed by the scope and ambition of your work even if I haven't had a chance to digest it fully yet, and I hope that my concern about production quality open source here is not misinterpreted as nay-saying or disapproval by anyone. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: A general purpose OS is a different beast as it has no physical equivalent of the FIB. It may have multiple routing tables, though, to I think setrib would be a term less likely to cause confusion then setfib even though, in the case of your FreeBSD patches, it's really both. If we need to change the terminology now is the time.. I asked for comments on terminology before and this is what we came up with.. but once it gets committed it gets set in stone. The kernel forwarding table is not a RIB. In the past some apps have tried to use it as one. They really shouldn't do that. There are implementation constraints on the inter-process communication involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a place for routing daemons to exchange routes, particularly when the system is under load, or running near load limits, as would be the case with a tightly engineered embedded system. I understand folk went down that road in the past, as a means to get something up and running quickly as a working demo, or as a hangover from the days when they were the only tools around, but it isn't the way to build a comms infrastructure. These days general purpose OSes are getting closer to specialised comms equipment in terms of what they can do, but more importantly, so are people's expectations of them -- and thus people's concern about whether or not it works tends to follow. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multiple routing tables review patch ready for simple testing.
Bruce M. Simpson wrote: Julian Elischer wrote: A general purpose OS is a different beast as it has no physical equivalent of the FIB. It may have multiple routing tables, though, to I think setrib would be a term less likely to cause confusion then setfib even though, in the case of your FreeBSD patches, it's really both. If we need to change the terminology now is the time.. I asked for comments on terminology before and this is what we came up with.. but once it gets committed it gets set in stone. The kernel forwarding table is not a RIB. In the past some apps have tried to use it as one. They really shouldn't do that. There are implementation constraints on the inter-process communication involved (PRC_ATOMIC, etc) which make it inherently unsuitable as a place for routing daemons to exchange routes, particularly when the system is under load, or running near load limits, as would be the case with a tightly engineered embedded system. I understand folk went down that road in the past, as a means to get something up and running quickly as a working demo, or as a hangover from the days when they were the only tools around, but it isn't the way to build a comms infrastructure. These days general purpose OSes are getting closer to specialised comms equipment in terms of what they can do, but more importantly, so are people's expectations of them -- and thus people's concern about whether or not it works tends to follow. basically what I've implemented is similar to cisco VRF in nature. Interfaces are not however assigned to FIB instance. each FIB may contain entries for each interface, and by default they do, but you can delete teh entries associated with a particular interface from a particular FIB so that fib will never use that interface. An interface may however be present in entries from multiple FIBs in which case the INCOMING packets on that interface need to be disambiguated with respect to which FIB they belong to. This is a job for an outside entity (from the fibs). In this case a packet classifier such as pf or ipfw is ideal for the job. providing an outside mechanism for implementing whatever policy the admin wants to set up. I find it is convenient to envision each routing FIB as a routing plane, in a stack of such planes. Each plane may know about the same interfaces or different interfaces. When a packet enters a routing plane it is routed according to the internal rules of that plane. Irrespective of how other planes may act. Each plane can only route a packet to interfaces that are know about on that plane. Incoming packets on an interface don't know what plane to go to and must be told which to use by the external mechanism. It IS possible that an interface in the future might have a default plane, but I haven't implemented this. if you have several alias addresses on an interface it is possible that some FIBS know about some of them and others know about other addresses. New addresses when added are added to each FIB and whatever is adding them shoudl remove them from the ones that don't need it. This may change but it fits in with how the current code works and keeps the diff to a manageable size. (and it suits what I need for work where a route manager daemon knows to do this.) cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [bfe] [panic] Serious error: bfe failed to map RX buffer
On Tue, Apr 29, 2008 at 08:25:13PM +0300, Oleg wrote: Hi, sorry for long delay, was too busy. So, I recheck return code of bus_dmamap_load(9) and its exactly ENOMEM. Here are fresh patch with your suggestions (diff with HEAD) Patch committed with minor changes(if_bfe.c rev 1.45). Thanks a lot! -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
