Alfred Perlstein wrote:
Ok, I'm not really sure what to do here. At Juniper we have approx
20 additional entries for AF_ constants. We also have theoretical
but not practical "problems" with spareness and utility of this
list, meaning we have plenty of arrays in our version of ifnets and
route
Ivo Vachkov wrote:
panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114
ether_demux() at ether_demux+
my_func() at my_func+
rtalloc_ign() at rtalloc_ign+
_mtx_lock_flags() at _mtx_lock_flags+
panic() at panic+
I do not include GIANT_REQUIRED in my code. Can you propose
Alfred Perlstein wrote:
Can you merge them into the list in such a way that AF_MAX does not need
to slide forward?
Or do they need to be referenced from within the kernel tree itself?
They are refenced inside the kernel.
Let me rephrase that: are protocol domains attached in the kern
The following reply was made to PR kern/116077; it has been noted by GNATS.
From: Bruce M Simpson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking
client
Date: Tue, 04 Sep 2007 14:17:53 +0100
I wrote this, but
Rui Paulo wrote:
Well, I was asking for comments regarding on the usage of these flags.
I was hoping to commit ip.h along with TCP ECN.
This doesn't really need to be before the branch, I think.
Looks fine to me. ECN would be a useful feature to have. AFAIK nothing
else uses these flags.
A
Ivo Vachkov wrote:
My lookup code looks like the following:
struct sockaddr_in6 *dst = NULL;
struct route_in6 out_rt;
/* ... */
dst = (struct sockaddr_in6 *)&out_rt.ro_dst;
bzero(dst, sizeof(*dst));
dst->sin6_len = sizeof(struct sockaddr_in6);
Jack Vogel wrote:
I had an idea, I was debugging a problem on my new 10G driver a week back,
and found I had the hardware vlan filter enabled by accident, this led me to
wonder about supporting this hardware feature in the driver...
I have done some experimentation, and find that when the vlan d
Alfred Perlstein wrote:
Bruce, I haven't heard back from you on this. can you please comment?
I'd like to add the policy to the header.
I'm not 100% happy with this suggestion, however, it is a loosely
working compromise.
I would be happier if the static index dependency on AF_MAX is ir
Tom Judge wrote:
Hi,
While making some changes to the routing table on one of our routers
today I noticed that "route add" was showing some strange behaviour.
When adding a route for 128/8 to the table rather than adding
128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works correctly.
Folks have been asking about XORP in this thread.
XORP can take a full BGP feed just fine as long as you have enough
memory.; for a full default-free-zone feed, you are looking at in the
region of 1GB - 1.5GB, perhaps less if you use aggregation.
If you look at the NSDI '05 paper you'll see t
LiuJiusheng wrote:
Linux takes 6.6.6.2 as gateway for route 4.4.4/24. But some Oses have the
gateway 2.2.2.2. (treat 4.4.4/24 as a recursive route).
Is there any standard for this?
No, this is entirely implementation specific. Some implementations of IP
forwarding resolve the next-hop recur
Nikos Vassiliadis wrote:
flakey fingers...
On Friday 26 October 2007 10:06:30 Kim Shrier wrote:
Other people successfully use this modem to connect to their ISP
when the ISP accepts pppoe connections and the modem is configured
as a bridge. Unfortunately, my ISP doesn't support pppoe, only
Jon,
Thanks for the patch.
Jon Otterholm wrote:
I was wondering about the possibility of adding support for QinQ
("Double tagged frames" / "Nested vlans"). Attached is a patch against
-STABLE to add this support. I have not tested this but was told it
should work.
Would it be possible to get t
Matus Harvan wrote:
Hi,
I was wondering if I could get some feedback about the patch and
whether others think it could be committed.
Thanks for your hard work on mtund. I'm not keen on this patch going
into a mainline kernel, though.
It stomps on bandwidth limitation if that's in effect
Matus Harvan wrote:
Hi,
I was wondering if I could get some feedback about the patch and
whether others think it could be committed.
The UDP catchall patch as submitted here clashes with the blackhole
functionality, and also bypasses the update of the protocol statistics
and unreachable p
Matus Harvan wrote:
Hi,
I was wondering if I could get some feedback about the patch and
whether others think it could be committed. A slightly update version
of the patch is at the end of this email.
I have mixed feelings about this patch.
The idea of a TCP socket which magically loses
Bruce M. Simpson wrote:
The relay port idea I pointed out in my message about udp catchall
would be especially applicable here -- we may not always want
catchalls for the entire 16-bit tcp port space.
...
How will inp_tlistenall appear in netstat output? Perhaps assigning a
LISTEN_ALL state
Ermal Luçi wrote:
I was wondering why this implementation of MPLS isn't integrated into FreeBSD?!
http://www.info.ucl.ac.be/~iannone/Files/MPLS-Complete.zip
At least two reasons spring to mind:
1. It seems to be targeted at FreeBSD 4.2, which is very old indeed.
2. No mention of it in GNATS
Brooks Davis wrote:
While I think this idea has some merit, I think we specifically want
the current wildcard ability to allow for a system that requires
minimal configuration. The problem with a range is that it doesn't
allow disjoint sets and it requires that if you really do want all the
port
Brian Hawk wrote:
Then what would be the reason to bind a connection to a specific
source address? We do
ping -S A.B.C.D x.y.z.t
to make ping send packets to x.y.z.t over A.B.C.D's interface (and
source address) or
telnet -s A.B.C.D x.y.z.t
I believe binding an IP's source address to an inter
mosaic wrote:
I would like to ask, whether there are any plans to implement multiple
route tables, like OpenBSD did:
http://archives.neohapsis.com/archives/openbsd/2006-10/2665.html
Yup, we're aware of these changes.
[The feature you're referring to is actually the ability to have
multipl
I'm very pleased to see ECN finally being implemented in FreeBSD.
Whilst I can't offer technical assistance in testing or review at this
time, I would like to thank you for the clearly professional level of
effort you have put into this.
regards,
BMS
__
Bjoern,
Thanks very much for tracking down and fixing this regression.
When I originally worked on tcp-md5 around 4 years ago, I didn't have
the luxury of fast enough machines to run VMs, and open source VMs were
considerably less mature.
One idea that's occurred to me, working on my current
Andrew Alcheyev wrote:
I have recently examined the keep-alive mechanism in FreeBSD's TCP
stack and found out that it has no tunable variables for keep-alive on
a per-socket basis.
Is anyone interested in a patch like this one?
http://mail-index.netbsd.org/tech-net/2007/06/19/0001.html
Alternati
Len Gross wrote:
I have built a "user land" prototype of a custom network protocol for an RF
network. It is based on Netgraph and using Ethernet rather than real RF.
Eventually, all the code will go into a special piece of hardware, but the
first hardware really will look like an Ethernet card
My shot from the hip, although I'm pretty much away from this stuff at
the moment.
Randy Bush wrote:
# ifconfig bridge0 addm ath0 addm vr1 up
ifconfig: BRDGADD ath0: Invalid argument
ath0 is IFT_ETHER, so it should be OK to attach it to the bridge --
although you won't
get the 802.11 frame
Julian Elischer wrote:
I think that breaking the arp code from the routing code
need to proceed.
I agree wholeheartedly. The coupling of the ARP code to the forwarding
code in the BSDs has been largely historical. Other implementations have
done this, and it generally simplifies the layer 3
Julian Elischer wrote:
I need a word to use to describe the network view one is currently on..
e.g. if you are usinghe second routing table, you could say I've set
xxx to 1
(0 based)..
current;y in my code I'm using 'universe' but I don't like that..
I would really really like it if we cou
How about "setfib"?
I strongly believe we should deprecate the use of the term "routing"
where the BSD forwarding plane is concerned, whilst familiar to many it
is misleading as to what that part of the system is actually doing.
2c
BMS
___
freebsd-n
Hi,
Just to chime in and agree with Bjoern, I'm finishing up a routing
protocol right now so this discussion is somewhat timely.
I disagree that this is a "bikeshed", quite the contrary -- the visual
and the verbal have to live together, and it's easy for those of us who
have the semantic ma
Julian Elischer wrote:
What I'm implementing is, as Qing said, a form of policy based forwarding
i.e. you can use a broad set of criteria to select a "FIB" (to use the
terms here) dependent on a number of criteria.
Criteria include source socket (for local connections) which
is derived from pro
Niki Denev wrote:
Hello,
Is this possible?
I've tried adding IFT_BRIDGE next to IFT_ETHER and IFT_L2VLAN in ip_carp.c
but this probably is not enough. Any ideas?
CARP is 'special' in that it needs to add its own MAC addresses to your
interface, needs a bit of special cooperation between th
Julian,
First of all, thank you very much for starting this work in a much
needed area.
Julian Elischer wrote:
This is a call for review for a change that is part of a
longer term project.
This implements multiple routing tables. Eventually the implementation
will be much cleaner but
the f
Tom Judge wrote:
I guess that there will be more than one VRRP implementation that does
not generate packets with a header the same size as the carp header.
I will look into generating a patch for this over the weekend,
however any thoughts/suggestions would be appreciated before I start
wor
Max Laier wrote:
Alternatively you could change IPPROTO_CARP in netinet/in.h to another
unused protocol number. This is really the preferred way of dealing with
mixed CARP and VRRP environments as the CARP packets might in turn
irritate the VRRP routers, too.
This sounds like a common use c
Andre Oppermann wrote:
So far the PPS rate limit has primarily been the cache miss penalties
on the packet access. Multiple CPUs can help here of course for bi-
directional traffic. Hardware based packet header cache prefetching as
done by some embedded MIPS based network processors at least do
Bruce M. Simpson wrote:
The problem which caused Thomas to raise the PR, is that of allowing
the prefix route for 192.168.1.0/24 to float over to the other
interface which *can* reach that prefix.
I should also point out that the problem exists at Layer 2 and Layer 3.
To be sure, if a
Hi there,
I have been cleaning up my PRs.
The last PR I have remaining in my queue is directly related to the
multipath work you are doing:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71474
The problem which caused Thomas to raise the PR, is that of allowing the
prefix route for 192.1
Andre Oppermann wrote:
Haven't looked at the multicast code so I can't comment. The other
stuff is just talk so far. No work in progress, at least from my side.
Insofaras rmlocks and cache line size vs rtentry size applies to multicast:
I know there are implementations out there which use th
Crist J. Clark wrote:
Anyone up for adding text to the scopeid field in the ifconfig(8)
output for IPv6 addresses? Other OSes do. To avoid too much
disruption to the current format, the text is appended after the
currently printed hexadecimal field.
Example:
fxp0: flags=8843 mtu 1500
op
Vadim Goncharov wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops only.
In multicast, next-hops are normally just inte
Julian Elischer wrote:
OK, but we should think about it in the future. In theory, routing
socket's messages are easily extendable with FIB number in uint16_t,
as message keeps it's length...
I will do that with the advice of people who know that protocol better
than I do.
I'm afraid Linux
Julian Elischer wrote:
Andre Oppermann wrote:
People with the ultimate need for speed have to maintain their own
trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford
to cut some more corners anyway.
We are trying to get away from that. We are trying to get more BACK
from th
Bjoern A. Zeeb wrote:
I'd go with something number+space+text as that going to least likely
break existing scripts (unless they match on line end;).
Another thing I am worried about is the output getting more likely 80
chars which is a bit of a pain.
Drop 'prefixlen' and use / instead:
Vadim Goncharov wrote:
Compare it with a scheme where for EVERY forwarded packet, there is a
need for DOUBLE lookup - after a routing one, do another in L2 table.
ARP lookups will generally use a cheap hash once split. What's the problem?
The PATRICIA lookups are more expensive, to be sure. Do
SnaiX wrote:
So it would run 1-4. but it reports EADDRINUSE after bind.
Why?
The stack assumes that SO_REUSEADDR is never cleared on a socket after
it gets set.
How to resolve it? Should I dup() the fd?
Did you close the affected socket in (5) ?
Presumably you are still trying to use
Hi,
This is ironic because I've been up against a similar problem with
255.255.255.255 on my current project, which also requires a 'bump in
the stack', and the same code you've posted the patch for, I found
myself reading yesterday to answer another chap's query.
Fredrik Lindberg wrote:
Hi
Fredrik Lindberg wrote:
I would expect this _without_ IP_MULTICAST_IF set, however as I said
the interface had been explicitly set with IP_MULTICAST_IF in all 4
cases, so there indeed is enough information in the stack to send
the packet.
Correct. You found a bug. Well done.
If IP_MULTICAST
Tom Judge wrote:
Hi,
I have just started experimenting with OpenLLDP and come across a
little bit of a nasty. When it opens the interface, it puts it into
PROMISC mode, which I don't really want to happen. Is there any way
to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface ma
Tom Judge wrote:
Thanks for the response. I have a quick grep of the src tree to find
an example of this being used and only found the following from
wpa_supplicant and I have a few questions:
* I am presuming that this will do what I want, am I correct?
Yes, it will attempt to add the
Tom Judge wrote:
Ok, so if I can safely assume that the process sending/receiving the
LLDP frames should always be running would it be safe to use a helper
program to add the mac on system startup so it is always registered on
particular interfaces for the uptime of the system rather than hav
Alexandre Vieira wrote:
Hello all,
I remember that there was a port (net/hoststated) where I could install
hoststated to use with PF. Anyone can shed a light on what is the status of
this software implementation on 7.0?
Perhaps ports/net/ifstated is the answer?
BMS
Enovation Technologies wrote:
i configure with sysinstall my second nic , but when i restart my box i have
this message
arp: 10.200.1.1 is on re0 but got reply from 00:50:7f:b0:a0:f8 on re1
my question is how to configure 2 nics with different ip on same box in the
same subnet.
Config
Yousif Hassan wrote:
ifwatchd has not been ported to FreeBSD - does FreeBSD have anything
similar?
Try ports/net/ifstated (from OpenBSD).
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscrib
Ingo Flaschberger wrote:
Hi,
linux does already support tcp-md5 checks for incomming connections,
but freebsd not.
I would like to implement this feature into freebsd.
Any hints/wishes/considerations that I should consider?
Someone(tm) keeps threatening to do this every 9-12 months, but I'v
The bigger issue w/tcp-md5 is getting security policy 'right'.
bz has more IPSEC hacking experience than I, so I defer to his advice in
this area.
The way the socket option was originally specified was that once it was
set, all further activity on the socket had to be tcp-md5'd. For an
outgoi
lysergius2001 wrote:
Hi
Recently installed AMD64 6.3-stable and I am having a problem with
devfs.conf and /dev. I understand the entries in devfs.conf should modify
the permissions on devices in /dev. For some reason or other this is not
happening. Can anyone shed some light on this? What am
Rui Paulo wrote:
On Feb 17, 2008, at 9:30 PM, Rui Paulo wrote:
Hi,
The attached patch ports a traceroute functionality from FreeBSD
called AS path.
I mean, "ported from NetBSD".
AS lookup is already in the NANOG traceroute in ports -- however I like
the look of this patch better, it looks
Tom Judge wrote:
However FreeBSD's routing table does not currently support policy
routing without some help from the firewall. The only way to achieve
your goal is to use one of the firewalls (pf/ipfw/ipf) to do the
policy routing for you.
If anyone wants to take this on, start looking at
Nick Barnes wrote:
I want packets from address A1 to be sent via gateway G1, but packets
from address A2 to be sent via gateway G2.
How do I do this? Can I just have more than one default route? I'm
remote from the machine in question, so I don't want to tinker with
the default route until I'm
Rob Watt wrote:
Hi.
We recently upgraded some of our machines to 6.3-RELEASE and we have been
plagued by repeatable panics when our multi-cast client applications exit.
Our machines have Intel X5365 processors, LSI MegaSAS 1064R cards, and Intel
Pro 1000 MF nic cards (although we have seen this
Jeremie Le Hen wrote:
In summary, favor wired connectivity over the wireless one, at any time:
could this be at boot time or not.
I'm pretty sure I'm not the only one who wants this kind of setup. So
how did you achieve this setup?
The forwarding code needs to be changed to support the notion
I just noticed that whilst the socket code appears to support
IPV6_TCLASS, we don't document it.
I haven't raised a PR for this issue yet nor have I written a patch.
This came up when I started hacking support for setting IP_TOS into
something else.
cheers
BMS
__
Wes Peters wrote:
I see a number of people have replied to this message offering
solutions of how to accomplish your migration, using a variety of
tools available to you in FreeBSD. I've always found this community
very supportive in this fashion, and I'm glad they've jumped in to
help you in
James Snow wrote:
I'm trying to use link-local for the cross-over interface between a pair
of FreeBSD boxes running pf, pfsync, and CARP. These firewalls will
need to be able to route for the whole of RFC1918, and carving off a
piece of that address space isn't an option.
This seemed to be a pe
[EMAIL PROTECTED] wrote:
At Wed, 20 Feb 2008 18:25:05 +,
Bruce M Simpson wrote:
I just noticed that whilst the socket code appears to support
IPV6_TCLASS, we don't document it.
I haven't raised a PR for this issue yet nor have I written a patch.
Please do both :-)
Paul Schmehl wrote:
--On Thursday, February 21, 2008 11:41:05 -0800 Tony Coon
<[EMAIL PROTECTED]> wrote:
I am looking for a way to flush IP addresses, particularly IPv6, from an
interface and have it repeat the initialization process that the
interface
goes through on boot, including IPv6
I looked at this very briefly.
It's gnarly because in_canforward() is a candidate for inlining and is a
predicate which is being overloaded with different meanings by
ip_forward()/ip_input() and icmp_reflect().
So whilst the fix is most likely a 3 liner, it risks making the code
look crap. W
Eric Anderson wrote:
I guess my biggest question is, why do the IPs .128, .129, .130, .131
appear in the routing tables where they're NOT defined? I don't get it?
You are not seeing forwarding table entries. You are seeing ARP entries
- the LLINFO flag is set (L). This is a legacy behaviour w
Hi,
I had to use a search engine to figure out what the acronym NFC was, and
I assume you mean this:
http://en.wikipedia.org/wiki/Near_Field_Communication
It helps if you give more background information when asking a more
general audience for feedback.
zDen wrote:
1) As the NFC device
+1 on increasing the threshold, 1024 is way too low.
Also consider the folk who depend on the existing behaviour: a
predictable ephemeral port range is useful, if for some reason you need
to apply a NAT policy to that traffic, with no other knowledge about how
the applications you must NAT act
Willem Jan Withagen wrote:
£ukasz Bromirski wrote:
Wouldn't it be a case for use of multicast vs unicast? Hardware
is always better anyway, so why not invest in some switch that
can do unicast/multicast in hardware?
Usefull suggestion, only this is going to be in an overlay cloud where
we do n
Robert Watson wrote:
One of those issues is that we need to demonstrate to ourselves that
exclusive access contention is managed as well with rwlocks as with
sleep mutexes, as these locks would continue to be fairly highly
contended in TCP. The other issue is that rwlocks don't support full
p
Sean C. Farley wrote:
I have noticed that with a Linux-based Netgear DG834G (DSL modem)
frequent pauses (example[1]) between external systems and 7-STABLE
(March 14th). At first, I thought it was ipfilter or ipnat, but I took
those out of the picture by activating telnet on the router and
connec
It has come to my attention that the default configuration of PF in
FreeBSD will block legitimate outgoing IGMP messages.
PF is currently not the default firewall in FreeBSD. Anyone using
multicast in any way, even for link-scope multicasts (224.x.x.x/24),
will be affected by this issue if the
Eugene Grosbein wrote:
On Sat, Mar 29, 2008 at 03:43:44PM -0500, Brooks Davis wrote:
I was using following command in FreeBSD 6.2:
# ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
In FreeBSD 7.0 I got an error:
# ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
ifconfig
Hi all,
Just to follow up on my message last week.
If I don't hear further feedback, I am likely to commit code which
allows IP Router Alert options through the pf firewall by default.
For further background read on.
cheers
BMS
The lack of support for allowing the IP Route
Dontcha just hate broken vendor NAT?
Yes, it seems reasonable that SACK is the sacrificial victim.
Considering folk normally configure TCP-MD5 between routers which are
usually directly connected on the same switch, doing away with SACK
should be fine.
Funny, I was staring at that define mom
Hi,
I am doing some protocol testing, and I just saw something very odd on
6.3-RELEASE.
If I try to inject multicast traffic via bpf with fxp, bpf will report
that it went out OK, however it never makes it out onto the wire. I have
ruled out firewalls, switches and other layer 2 behaviour.
Just off the top of my head...
...has anyone run into problems with the scalability of this call?
One of the XORP users needs to create »1000 interfaces in Linux, and I'm
wondering if any FreeBSD users need to create that amount of network
interfaces.
As such the getifaddrs() call is likely t
[EMAIL PROTECTED] wrote:
Hi All,
I am working on implementing MPLS in FreeBSD at the moment. I was wondering if
anyone had some links to any references I could use, or recommend any books I
can use to help me in that. Failing that, I am struggling with trying to work
out how to initialise my
Julian Elischer wrote:
Seen ayame? http://www.ayame.org/
looks like a stalled affort.. things stop in 2002
[greater-than] From what I've read of the code, it seems close to KAME
and BSD style, and could actually get merged. With a little bit more
work, the userland could slot into XORP's B
tmm wrote:
So, can anyone suggest how I can send a limited broadcast (on an
interface that has been initalized with an IP and a subnet)?
Use the IP_ONESBCAST option and send to the network broadcast address
for that subnet. The stack will change it into 255.255.255.255 on
output. See man page
Martin Garon wrote:
I am looking for a FreeBSD release with IGMPv3 and was surprised to find
none.
I know the KAME project added support for IGMPv3. Anyone knows why this was
not imported back into the current sources? I was wondering if it had
anything to do with reliability or rather with busi
Maksim Yevmenkin wrote:
please try the following patch. if there is no objections, i will commit it
beetle# diff -u if_tap.c.orig if_tap.c
--- if_tap.c.orig 2007-04-05 10:58:39.0 -0700
+++ if_tap.c2008-04-14 09:42:42.0 -0700
@@ -404,6 +404,7 @@
struct ifnet
Hi,
I noticed a strange issue with tap(4) and if_bridge(4) where the bridge
seems not to be forwarding frames.
6.3-RELEASE, btw.
I have this setup where I use the two to bootstrap QEMU virtual machines.
Up until now I've been using dhcpd for this. This has only ever worked
right for me if I
Christopher Arnold wrote:
Anyone looing at supporting the netfpga card on FreeBSD?
I would love to do that project myself, my time is scarse right now.
I believe there was some interaction between other XORP members and the
NetFPGA people, although I don't know if this resulted in any outcome.
Ingo Flaschberger wrote:
So we are looking for a tool that inject and verify packet with faked
IPs. We want to generate fake traffic between A-B A-C B-C in both
directions.
The aim is to evaluate the routing capacity of openbgpd/freebsd.
We currently didn't find any tool that fit our needs. D
The following reply was made to PR kern/122839; it has been noted by GNATS.
From: "Bruce M. Simpson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Tue, 22 Apr 200
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 partic
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
bo
Julian Elischer wrote:
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.
Yes, there is no way the forwarding code alone can do this.
It should not be expected
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.
2) If that decis
Bruce M. Simpson wrote:
Wouldn't it make sense to treat each alias as on a separate
logical interface? Then each logical interface belongs to
exactly one FIB. On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address. That reduces conf
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't changed any of that.. Basi
John Hay wrote:
The linux guys seems to have multiple fibs (or whatever they call them)
which they can chain together by giving them different priorities. The
effect seems to be that a packet will be matched through the highest
priority fib to the lowest until a route match is found en then is us
Julian Elischer wrote:
OLSR is an overlay network
Nope -- the express intention was that it could be used for basic IP
connectivity, for mobile devices. In OLSR, every node is a potential IP
forwarder unless it explicitly advertises itself as being unwilling to
forward.
and any machine th
John Hay wrote:
You don't need to go to the kernel for this sort of thing unless you
specifically need to implement route policy based on which interface(s)
a packet came in on.
Yes I know that. But in the world of adhoc wireless mesh networking
there are very few non-linux people, so the
Paul wrote:
Is there a list of patches that have been applied to -STABLE since
the -RELEASE ?
I can't seem to find a simple organized list of applied patches
(something similar to linux kernel changelog).
I want to know if anything has been fixed or udpated in the network
area to see if it w
Julian Elischer wrote:
you could implement a whole new protocol family of which there
was a single protocol.. divert.
That's sheer overkill for what Edwin needs to be able to do. We already
have a bunch of apps which use divert sockets in the IPv4 space, why
should the existing semantics chang
101 - 200 of 613 matches
Mail list logo
