ifconfig description
descr[0]!=0 ) {
+ printf("descr: %s\n", ifrd.ifrd_descr);
+ }
+
close(s);
return;
}
***
*** 1051,1056
--- 1075,1081
DEF_CMD("noicmp", IFF_LINK1, setifflags),
DEF_CMD_ARG("mtu", setifmtu),
DEF_CMD_ARG("name", setifname),
+ DEF_CMD_ARG("descr",setifdescr),
};
static __constructor void
--
Best regards,
bart mailto:[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ifconfig description
Hello, previous patches had problem with quagga/zebra. here are set of patches for 5.4 that work fine. I also have patch for quagga to show interface descriptions in "sh int" command Best regards, Alex Bartolomey___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ifconfig description
*** sys/net/if.c.orig Fri Apr 15 07:52:03 2005
--- sys/net/if.cSat Nov 26 17:34:41 2005
***
*** 1072,1077
--- 1072,1078
{
struct ifreq *ifr;
struct ifstat *ifs;
+ struct ifdescreq *ifrd;
int error = 0;
int new_flags;
size_t namelen, onamelen;
***
*** 1214,1219
--- 1215,1232
EVENTHANDLER_INVOKE(ifnet_arrival_event, ifp);
/* Announce the return of the interface. */
rt_ifannouncemsg(ifp, IFAN_ARRIVAL);
+ break;
+
+ /* bartp */
+
+ case SIOCSIFDESCR:
+ ifrd = (struct ifdescreq *)data;
+ strlcpy(ifp->if_descr, ifrd->ifrd_descr, MAXIFDESCRSIZE);
+ break;
+
+ case SIOCGIFDESCR:
+ ifrd = (struct ifdescreq *)data;
+ strlcpy(ifrd->ifrd_descr, ifp->if_descr, MAXIFDESCRSIZE);
break;
case SIOCSIFMETRIC:
*** sys/net/if.h.orig Tue Mar 1 03:03:13 2005
--- sys/net/if.hTue Nov 29 17:21:13 2005
***
*** 72,77
--- 72,80
char*ifcr_buffer; /* buffer for cloner names */
};
+ #define MAXIFDESCRSIZE 48
+
+
/*
* Structure describing information about an interface
* which may be of interest to management entities.
***
*** 269,274
--- 272,282
struct sockaddr ifra_addr;
struct sockaddr ifra_broadaddr;
struct sockaddr ifra_mask;
+ };
+
+ structifdescreq {
+ charifrd_name[IFNAMSIZ];/* if name, e.g. "en0" */
+ charifrd_descr[MAXIFDESCRSIZE]; /* interface description */
};
struct ifmediareq {
*** sys/net/if_var.h.orig Sun May 8 13:00:16 2005
--- sys/net/if_var.hSat Nov 26 17:34:06 2005
***
*** 200,205
--- 200,206
int if_afdata_initialized;
struct mtx if_afdata_mtx;
struct task if_starttask; /* task for IFF_NEEDSGIANT */
+ charif_descr[MAXIFDESCRSIZE];
};
typedef void if_init_f_t(void *);
*** sbin/ifconfig/ifconfig.c.orig Mon Mar 21 21:05:33 2005
--- sbin/ifconfig/ifconfig.cFri Nov 25 15:29:35 2005
***
*** 175,180
--- 175,181
c_funcsetifflags, setifmetric, setifmtu, setifcap;
c_funcclone_destroy;
c_funcsetifname;
+ c_funcsetifdescr;
void clone_create(void);
***
*** 310,315
--- 311,317
{ "noicmp", IFF_LINK1, setifflags },
{ "mtu",NEXTARG,setifmtu },
{ "name", NEXTARG,setifname },
+ { "descr", NEXTARG,setifdescr },
{ 0,0, setifaddr },
{ 0,0, setifdstaddr },
};
***
*** 1008,1013
--- 1010,1031
(*afp->af_getaddr)(addr, DSTADDR);
}
+ static void
+ setifdescr(const char *val, int dummy __unused, int s,
+ const struct afswtch *afp)
+ {
+ struct ifdescreq ifrd;
+
+ strlcpy( ifrd.ifrd_name, ifr.ifr_name, sizeof(ifr.ifr_name) );
+ strlcpy( ifrd.ifrd_descr, val, sizeof(ifrd.ifrd_descr) );
+
+ if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifrd) < 0) {
+ warn("ioctl (set descr)");
+ return;
+ }
+ }
+
+
/*
* Note: doing an SIOCIGIFFLAGS scribbles on the union portion
* of the ifreq structure, which may confuse other parts of ifconfig.
***
*** 1121,1126
--- 1139,1145
struct rt_addrinfo info;
int allfamilies, s;
struct ifstat ifs;
+ struct ifdescreq ifrd;
if (afp == NULL) {
allfamilies = 1;
***
*** 1219,1224
--- 1238,1250
#endif
)
warnx("%s has no %s interface address!", name, afp->af_name);
+
+ /* bartp */
+
+ strncpy(ifrd.ifrd_name, name, sizeof ifrd.ifrd_name);
+ if (ioctl(s, SIOCGIFDESCR, (caddr_t)&ifrd) == 0 &&
ifrd.ifrd_descr[0]!=0 ) {
+ printf("descr: %s\n", ifrd.ifrd_descr);
+ }
close(s);
return;
*** sys/sys/sockio.h.orig Wed Apr 7 10:19:49 2004
--- sys/sys/sockio.hFri Nov 25 15:07:55 2005
***
*** 80,85
--- 80,90
#define SIOCSIFMAC _IOW('i', 39, struct ifreq)/* set IF MAC
label */
#define SIOCSIFNAME _IOW('i', 40, struct ifreq)/* set IF name
*/
+ /* bartp */
+ #define SIOCSIFDESCR _IOW('i', 41, struct ifdescreq) /* set IF
descr */
+ #define SIOCGIFDESCR_IOWR('i', 42, struct ifdescreq) /* get IF
descr */
+
+
#define SIOCADDMULTI _IOW('i', 49, struct ifreq)/* add m'cast
addr */
#define SIOCDELMULTI _IOW('i', 50, struct ifreq)/* del m'cast
addr */
#define SIOCGIFMTU _IOWR('i', 51, struct ifreq)/* get IF mtu */
___
mtu on gif devices
Hi all, first of all, could you please cc any replies to me ? (I'm not on this list). Last time I checked (around fbsd4.3) , I was unable to set the mtu of a gif device higher then 1280. I just cvs'ed from 4.4 to 4.5, and saw that i was able to set the mtu of the gif device to 1500 (and saw that my 4.4 box could do the same). The weird thing is, though, that since i've upgraded to 4.5, ssh connections from my irix and bsd box in my network (which have public ip's tunneled from work) die spontaniously. They either die when i give it a lot of input, or when i idle for a bit. It smells like a mtu problem to me, but i can't find the problem. When i ssh directly from my router trough the tunnel to work, i get a stable connection, so i figured the home-router itself is the source of the problem. Set up is like this: colo (gif with mtu 1500) -> gif tunnel -> home-router (gif with mtu 1500/ interfaces with mtu 1500) -> irix box (mtu 1200) / bsd box (mtu 1500). Both the irix and bsd box have the problem. The problem was also occuring when the mtu of both gif devices were set to 1280. It all started when i upgraded my home router from 4.4 to 4.5. Any suggestions are welcome. With regards, Bart -- Bart Matthaei [EMAIL PROTECTED] Support wildlife -- vote for an orgy. msg04953/pgp0.pgp Description: PGP signature
Re: mtu on gif devices
On Fri, Feb 22, 2002 at 08:26:52PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > Sorry for the delayed response, > > How did you configure (particularly the default) routes on the host > "colo"? I've seen several reports that the default route on a tunnel > link has somehow become bogus. > > BTW: if the problem happens regardless of the MTU value, the MTU > setting may not be the reason. Jinmei, The problem has already been fixxed. NAT + Gif tunnel is known to cause mtu problems. I overlooked that. I didn't have this problem in 4.4, so obviously something changed. (I also get a weird traceroute output when i trace something in my homenet from the outside world since my update to 4.5. If you want to hear this issue, let me know.) Regards, Bart -- Bart Matthaei [EMAIL PROTECTED] Support wildlife -- vote for an orgy. msg05124/pgp0.pgp Description: PGP signature
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul / Ingo, > >> I tried all of this :/ still, 256/512 descriptors seem to work the >> best. Happy to let you log into the machine and fiddle around if you >> want :) I've been watching this thread closely, since I'm in a very similair situation. A few questions/remarks: Does ULE provide better performance than 4BSD for forwarding? Did you try freebsd4 as well? This thread had a report about that quite opposite to my own experiences, -4 seemed to be a lot faster at forwarding than anything else I 've tried so far. Obviously the thing I'm interested in is IMIX - and 64byte packets. Does anyone have any benchmarks for DragonFly? I asked around on IRC, but that nor google turned up any useful results. > I don't think you will be able to route 64byte packets at 1gbit > wirespeed (2Mpps) with a current x86 platform. Are there actual hardware related reasons this should not be possible, or is this purely lack of dedicated work towards this goal? >Theres a "sun" used at quagga dev as bgp-route-server. >http://quagga.net/route-server.php >(but they don't answered my question regarding fw-performance). the Quagga guys are running a sun T1000 (niagara 1) route server - I happen to have the machine in my racks, please let me know if you want to run some tests on it, I'm sure they won't mind ;-) It should also make a great testbed for SMP performance testing imho (and they're pretty cheap these days) Also, feel free to use me as a relay for your questions, they're not always very reachable. > Perhaps you have some better luck at some different hardware systems > (ppc, mips, ..?) or use freebsd only for routing-table-updates and > special network-cards (netfpga) for real routing. The netfpga site seems more or less dead - is this project still alive? It does look like a very interesting idea, even though it's currently quite linux-centric (and according to docs doesn't have VLAN nor ip6 support, the former being quite a dealbreaker) Paul: I'm looking forward to the C2D 32bit benchmarks (maybe throw in a freebsd4 and/or dragonfly bench if you can..) - appreciate the lots of information you are providing us :) Met vriendelijke groet / With kind regards, Bart Van Kerckhove http://friet.net/pgp.txt -BEGIN PGP SIGNATURE- iQA/AwUBSG/tMgoIFchBM0BKEQKUSQCcCJqsw2wtUX7HQi050HEDYX3WPuMAnjmi eca31f7WQ/oXq9tJ8TEDN3CA =YGYq -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> Good news is using iptables only adds a few percentage onto the CPU >> usage. But still, what's with that.. >> So far FreeBSD got the highest pps rating for forwarding. I haven't >> tried bridge mode. Ipfw probably takes a big hit in that too though. >> Looking for an 82575 to test.. > > P.S. It was a nice chat, but what we can expect from the future? Any > plans, patches etc? > Someone suggested to install 8-current and test with it as this is the > "fast" way to have something included in FreeBSD. > I can do this - I can install 8-current, patch it and put it under > load and report results, but need patches :) > I guess Paul is in the same situation .. I'm in the same situation as well. Would anyone be interested in very specific work aimed at improving IP forwarding? I would happily put out a bounty for this, and I'm quite sure I'm not alone. PS Paul: idd you get around to testing C2D ? Kind regards, Met vriendelijke groet / With kind regards, Bart Van Kerckhove http://friet.net/pgp.txt "There are 10 kinds of ppl; those who read binary and those who don't" -BEGIN PGP SIGNATURE- iQA/AwUBSHdqOQoIFchBM0BKEQJSPQCfQKKgD8+xrX088+o0IKmPDdDD0XoAnAv+ SqgNdjkKsEstDYqnFDNUQuK3 =ft58 -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Feature requests / inquiries.
Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) Met vriendelijke groet / With kind regards, Bart Van Kerckhove [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Feature requests / inquiries.
Hi,> > if_bridge has been imported into FreeBSD 6.0 and I believe will be > > merged to 5.x before 5.5. > A candidate MFC patchset is at: > http://people.freebsd.org/~thompsa/if_bridge-5stable.diff and is believed > to > be production quality (judging from the reports for RELENG_6 so far). > There > might be minor problems and/or yet undiscovered problems, but only testing > gets it there. Andrew is certainly thankful for any feedback! Ok, that's great info. Thanks guys.> > I can't speak for ECMP. That's a pity, we've had lots of issues when running redundant setups with VRRP, where VRRP tried to add the same route (on another interface) before the failed/old one got deleted (by OSPFd). This resulted in a faillure to add the new route, afterwards OSPF deletes the 'old' route, and you end up with no valid route at all.This is one of the major problems people are experiencing when running GNU/Zebra/Quagga in a redundant setup afaik. Current fixes in those circles consist of dirty hacks, such as shutting down and restarting OSPFd whenever VRRP acts. I feel it should be possible to resolve this at kernel level, eliminating the need for userlevel hacks.So i'll simply repeat the proposal: anyone willing to develop support for ECMP (or just routes with metrics on them, not doing ECMP, but allowing multiple routes to the same prefix, on different/the same interface, with unique metrics)?As stated before, I'm very much willing to sponsor its development.> > > > LACP is supported by ng_fec. The fact that you don't like it is a > > seperate issue. FWIW, ng_fec only uses netgraph for configuration. > > It's not really a netgraph node. I'd personally like to see OpenBSD's > > if_trunk imported and LACP added, but I certainly don't have time. Well, when referring to not liking the NetGraph approach, i was specifically talking about NG_ONE2MANY(4) - which is a dirty hack (imho) to have some of the goodies of ECMP support.I'm not seeing ng_fec on freebsd4.11, but 5.x is an option, so problem solved with regards to LACP.Kind regards,Met vriendelijke groet / With kind regards,Bart Van [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: OT - Quagga/CARP
Bart Van Kerckhove <[EMAIL PROTECTED]> wrote: > >>> mfd(config)# int vlan59 >>> mfd(config-if)# ip address 10.197.66.97/27 >>> % Can't set interface IP address: File exists. >>> mfd(config-if)# >> >> It's FreeBSD's behavior >> >> [EMAIL PROTECTED] route add 10.0.0.0/30 192.168.1.1 >> add net 10.0.0.0: gateway 192.168.1.1 >> [EMAIL PROTECTED] ifconfig vlan100 10.0.0.1/30 >> ifconfig: ioctl (SIOCAIFADDR): File exists >> > Yes it is, found that out the hard way too when we tried similar > things before. > Is this by design, or just lack of time/interest? > If anyone feels up to the task of fixing/implementing what's needed > to make this work, we'd be happy to sponsor its development. > > Met vriendelijke groet / With kind regards, > > Bart Van Kerckhove > [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: OT - Quagga/CARP
>> mfd(config)# int vlan59 >> mfd(config-if)# ip address 10.197.66.97/27 >> % Can't set interface IP address: File exists. >> mfd(config-if)# > > It's FreeBSD's behavior > > [EMAIL PROTECTED] route add 10.0.0.0/30 192.168.1.1 > add net 10.0.0.0: gateway 192.168.1.1 > [EMAIL PROTECTED] ifconfig vlan100 10.0.0.1/30 > ifconfig: ioctl (SIOCAIFADDR): File exists > Yes it is, found that out the hard way too when we tried similar things before. Is this by design, or just lack of time/interest? If anyone feels up to the task of fixing/implementing what's needed to make this work, we'd be happy to sponsor its development. Met vriendelijke groet / With kind regards, Bart Van Kerckhove [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: OT - Quagga/CARP
Bruce M Simpson <[EMAIL PROTECTED]> wrote: > On Thu, Mar 16, 2006 at 07:35:20PM +0100, Bart Van Kerckhove wrote: >> Is this by design, or just lack of time/interest? >> If anyone feels up to the task of fixing/implementing what's needed >> to make this work, we'd be happy to sponsor its development. > > This is a collision between the connected route implicitly created > by configuring an interface which has the same prefix length as > an existing route in the FreeBSD FIB. > > This is a known issue and is by design. > > Most BSD-derived implementations have this limitation. It needs to be > resolved in preparation for equal-cost multipath. > ECMP was indeed one of the features i was looking for at that time, which i found to be impossible. I just don't like the idea of moving towards another platform just for this reason, since I'm very happy with freebsd's performance. There used to be a patch for ECMP, but it was a huge hack. very dirty at best. > Sadly whilst I'd be more than happy to work on this (with or without > funding), I don't have the free time to do so, but I may be able to > eke out spare time to look at patches. Any quick hacks you have in mind that could allow multiple copies of the same route / pfxlen in the freebsd routingtable? Doesn't even need to have metrics in kernel-level, the point of the whole thing (for now) would be to be able to insert an additional route with the same prefix, and delete the previousy set route *afterwards*. Which is what ospfd/zebra would do. Any insights / hacks / other dirty things are very appreciated. For all others following this thread: "we'd be happy to sponsor its development" still is in effect ;) Met vriendelijke groet / With kind regards, Bart Van Kerckhove [EMAIL PROTECTED] http://www.it-ss.be - "Solid Solutions for your IT needs" "There are 10 kinds of ppl; those who read binary and those who don't" smime.p7s Description: S/MIME cryptographic signature
Re: OT - Quagga/CARP
Bruce M Simpson <[EMAIL PROTECTED]> wrote: > On Thu, Mar 16, 2006 at 10:36:20PM +0100, Bart Van Kerckhove wrote: >> ECMP was indeed one of the features i was looking for at that time, >> which i found to be impossible. >> I just don't like the idea of moving towards another platform just >> for this reason, since I'm very happy with freebsd's performance. >> There used to be a patch for ECMP, but it was a huge hack. very >> dirty at best. > > itojun recently committed a set of ECMP related changes to OpenBSD. > Unfortunately I have not had free time to review them in any detail. > What approach did they take? The ecmp patch i encountered for freebsd didn't lift the limitation regarding 1 route/pfx/pfxlen in the fib. Is this the case here too? Or did they take a new approach? > I hope andre@ is watching this thread, it's probably on his laundry > list too. I believe other parties may have implemented the hack you > are referring to. He is watching :) (lucky me/us ;]) Met vriendelijke groet / With kind regards, Bart Van Kerckhove [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: OT - Quagga/CARP
Brad <[EMAIL PROTECTED]> wrote: > On Thu, Mar 16, 2006 at 09:52:07PM +, Bruce M Simpson wrote: >> On Thu, Mar 16, 2006 at 10:36:20PM +0100, Bart Van Kerckhove wrote: >>> ECMP was indeed one of the features i was looking for at that time, >>> which i found to be impossible. >>> I just don't like the idea of moving towards another platform just >>> for this reason, since I'm very happy with freebsd's performance. >>> There used to be a patch for ECMP, but it was a huge hack. very >>> dirty at best. >> >> itojun recently committed a set of ECMP related changes to OpenBSD. >> Unfortunately I have not had free time to review them in any detail. >> >> I hope andre@ is watching this thread, it's probably on his laundry >> list too. I believe other parties may have implemented the hack you >> are referring to. > > Heh. At first I read this and wasn't sure what ECMP was, I've never > seen anyone use that acronym before. Hmm, sorry if I used a non-common term there, it's the only abbreviation i know of ;> > The code Itojun commited to the > OpenBSD tree consisted of code to add multipath support for radix > trees. The routing code still needs to be modified to use this new > support though. > > > radix tree with multipath support. from kame. deraadt ok > user visible changes: > - you can add multiple routes with same key (route add A B then route > add A C) > - you have to specify gateway address if there are multiple entries > on the table (route delete A B, instead of route delete A) > kernel change: > - radix_node_head has an extra entry > - rnh_deladdr takes extra argument I have looked into KAME before, and was puzzled to see it was in KAME, but not in *bsd :-> > > TODO: > - actually take advantage of multipath (rtalloc -> rtalloc_mpath) > > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix.c > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix_mpath.c I have no kernel coding experience whatsoever. How hard would it be to merge this with freebsd? -Bart ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ng_netflow documentation
Dear list, I have been looking into ng_netflow lately for traffic analyzing. It seems that this would do everything i'd ever need - though I have a hard time tracking down (working) examples, or FAQ's/howto's/documentation. I've done the most obvious things, googled it, searched the -net lists, but to no (useful) effect. I was wondering if this list could provide me with any useful links or info regarding ng_netflow. That would be greatly appreciated! Met vriendelijke groet / With kind regards, Bart Van Kerckhove [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: OT - Quagga/CARP
Andre Oppermann <[EMAIL PROTECTED]> wrote: > > Lets discuss this. Claudio (@openbsd.org and my employee) have a > couple of ideas on how to do this the best way. Andre, do you have any further updates/insights to share on this topic? With kind regards, Bart Van Kerckhove [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: OT - Quagga/CARP
Michael DeMan <[EMAIL PROTECTED]> wrote: > Hi, Hi gents and ladies, > > See inline... ditto > > On Mar 30, 2006, at 11:11 PM, Dima Dorfman wrote: > >> Michael DeMan <[EMAIL PROTECTED]> wrote: >>> So, if you already have a route to 10.100.100.0/24 via OSPF to >>> another machine, then try to... >>> >>> ip address 10.100.100.55/24 >>> >>> You get an error. >> >> Is that the only problem? Someone was talking about funding >> development to fix something--surely there must be something more >> severe than the inability to use the "ip address" interface command? >> I thought the problem was about encoutering broken ingress paths if >> one of the routers loses connectivity to the destination network. Hmm no, it is not the inability to use "ip address" inside any quagga soft, afaik the freebsd userland tools can't get the route-setting done eiter. Not when an alternate route for the same prefix is in the kernel route table. >> > > My understanding is that my issue is just one symptom of a general > limitation in the kernel routing tables or something, and that fixing > this problem would also allow multi-path routing for FreeBSD, which > is probably a bigger 'win' for the community overall. This is exactly the thing we need to get around. Multi-path (and notably equal-cost multipath) would be a major gain. Yes it is possible currently, but it requires ugly hacks (ipfw comes to mind). ECMP does not belong in a firewall imHo - but that's just me ;o) This is a place where freebsd really is lagging behind the other BSD's (and to not state the obvious, that tux o/s). Is this because there is no general need for these features? Lack of development time? (hence the sponsoring proposal...) FreeBSD has a nice rep going for it with regards to its ipstack ... ;-> > >> Does the combination of CARP and quagga OSPF work once it's >> configured using system tools? > > Yes, it will work then. However, I still have to kill and restart > the zebra and ospf processes entirely for them to pick things up > correctly. My understanding is that restarting en ospfd daemon is bad. restarting zebra is even worse - and must not be done. > >> >>> It is possible to force the interface configuration via 'ifconfig' >>> on the UNIX command line, but for this equipment I want all >>> interface configuration and routing driven out of Quagga. >> >> It would be cool if that was possible, but it's not really practical. >> My systems tend to have a lot of very custom configuration that >> quagga will never be able to express. If I had a cookie-cutter >> configuration, I'd probably be using a C or J box. >> While I've found bgpd and ospfd to be very stable, the zebra part >> that interacts with the kernel has had various problems over >> time--routes not being installed correctly, or going away, or having >> incorrect flags. I wouldn't trust it to configure the entire network >> subsystem. I don't use zebra to configure anything on our production machines. It merely reads out routes that are already set, and adds ospf/bgp ones. >> > > I've noticed some oddities with zebra too, but never anything that is > a show-stopper. There was some kind of bug with notifications of > interface 'up/down' not getting propogated correctly between zebra/ > kernel, but that seems to be fixed. There's lots of fixes being implemented on a daily basis, that much I know (from regular contact with the guys). > Met vriendelijke groet / With kind regards, Bart Van Kerckhove [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: LACP 802.3ad and ng_fec ?
Özkan KIRIK <[EMAIL PROTECTED]> wrote:
> Thanks for your reply,
>
> It seems that HP ProCurve 5400 series doesn't support fec trunking :
>
> hp(config)# trunk A3-a5 trk1 fec
> Invalid input: fec
>
> hp(config)# trunk A3-a5 trk1 ?
> trunk Do not use any protocol to create or maintain
> the trunk.
> lacp Use IEEE 802.1ad Link Aggregation protocol.
>
> hp(config)#
>
> Can ng_fec handshake with switch via "trunk" option instead of "fec" ?
According to HP docs, FEC should "work" with the 'trunk' setting.
It will loose all features tough, and just become a 'dumb' bonding-style
thing, with no redundancy and other features.
Met vriendelijke groet / With kind regards,
Bart Van Kerckhove
[EMAIL PROTECTED]
http://www.it-ss.be - "Solid Solutions for your IT needs"
"There are 10 kinds of ppl; those who read binary and those who don't"
>
> Antony Mawer yazmış:
>> On 22/09/2006 6:58 PM, Özkan KIRIK wrote:
>>> Does ng_fec module support Dynamic LACP (802.3ad) protocol ?
>>>
>>> i have an HP Procurve 5406 switch, i am trying to make a fail over
>>> connection between switch and freebsd.
>>> Does ng_fec support "Fail over" for links ?
>>
>> The ng_fec module doesn't support LACP (it would be really nice if it
>> did!!!), but you can configure it manually if you've got access to
>> the console of the switch. I setup exactly this configuration today
>> (although in this case it was for bandwidth aggregation rather than
>> fall-over) using an HP Procurve 5308xl.
>>
>> The procedure went something like this:
>>
>> 1) First, create a new startup script in /etc/rc.d/ to configure the
>> Netgraph interface on startup... this was a quick hack-up, but does
>> the job:
>>
>> begin /etc/rc.d/ngfec
>> $ cat /etc/rc.d/ngfec
>> #!/bin/sh
>> #
>> # PROVIDE: ngfec
>> # REQUIRE: root
>> # BEFORE: netif
>> # KEYWORD: nojail
>>
>> . /etc/rc.subr
>>
>> name="ngfec"
>> start_cmd="ngfec_start"
>> stop_cmd=":"
>>
>> # Netgraph FEC startup script
>> ngfec_start()
>> {
>> echo -n "Configuring netgraph FEC device: "
>> ngctl mkpeer fec dummy fec
>> ngctl msg fec0: add_iface '"em0"'
>> ngctl msg fec0: add_iface '"em1"'
>> echo "done."
>> }
>>
>> load_rc_config $name
>> run_rc_command "$1"
>>
>> end of /etc/rc.d/ngfec
>>
>>
>> 2) Configure the new fec0 interface in /etc/rc.conf:
>>
>> ifconfig_fec0="inet a.b.c.d netmask w.x.y.z"
>>
>>
>> 3) Telnet to the HP switch, and do the following:
>>
>> i) Type "show trunk" and identify what trunk group names are
>>already in use. These will be in the format of "TrkN", eg.
>> Trk1,Trk2,...
>>
>> ii) Identify which ports are to be configured as part of trunk
>> (eg. in my case, C1 and C2)
>>
>> iii) Select the next available trunk group name (eg. Trk7), and
>>configure the trunk by typing:
>>
>>switch# config t
>>switch(config)# trunk C1-C2 Trk7 fec
>>switch(config)# exit
>>
>> 4) Once the FreeBSD machine is rebooted, the link should be up
>>
>>
>> I'm not sure what the behaviour is when one of the links goes down...
>> I don't know if that interface is simply removed from the trunk group
>> and the remaining ones continue to operate?
>>
>> Hope this is useful to others out there, as I had trouble finding any
>> good documentation on how to do this :-) I owe thanks to lukem dot
>> freebsd at cse dot unsw dot edu dot au for the Netgraph commands for
>> getting the FreeBSD fec side of things up and running; the rcNG
>> script above is based on the commands he provided me with, put into
>> rcNG format so I could integrate it with the boot sequence easily.
>>
>> Cheers
>> Antony
>>
>>
> ___
> 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: LACP 802.3ad and ng_fec ?
Thanks for your reply, It seems that HP ProCurve 5400 series doesn't support fec trunking : hp(config)# trunk A3-a5 trk1 fec Invalid input: fec hp(config)# trunk A3-a5 trk1 ? trunk Do not use any protocol to create or maintain the trunk. lacp Use IEEE 802.1ad Link Aggregation protocol. hp(config)# Can ng_fec handshake with switch via "trunk" option instead of "fec" ? According to HP docs, FEC should "work" with the 'trunk' setting. It will loose all features tough, and just become a 'dumb' bonding-style thing, with no redundancy and other features. Yes, I was reading some HP docs yesterday and they implied that they were removing FEC on newer switches in favour of using the IEEE standards-based methods of trunking. I can NOT resist taking the bait here: HP has supported these standards for ages. In fact, the cisco-protocols were used to market their stuff as cisco-replacements. They ripped out functionality. IEEE Standards were already supported. Same for their SFP's. Vendor lock-in is a bitch, especially when that means you can't get stuff that was previously possible. (think cwdm gbics, etc) I wonder how dissimilar FEC and IEEE LACP are from one another? ie. how much of the code from ng_fec could be used to implement an ng_lacp... I honestly don't know :-/ I'm very interested in the whole topic though, as we're an all-HP (as in procurve) shop. I do know that will only last 'till the next boxes we buy, HP has let us down the past few years. -Bart (sorry for the ranting) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
