Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*neighbour\s+cache\s+vs\.\s+invalid\s+addresses\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*neighbour\s+cache\s+vs\.\s+invalid\s+addresses\s*$/: 22 ]

Total 22 documents matching your query.

1. neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sat, 29 Apr 2000 19:00:37 +0200 (MET DST); In non-broadcast multiple-access networks (NBMA) such as Classical IP over ATM (CLIP), neither broadcast nor multicast have any useful semantics. Right now, I catch this in neigh_table->constructor a; /archives/netdev/2000-04/msg00098.html (8,725 bytes)
2. Re: neighbour cache vs. invalid addresses (score: 1): Author: kuznet@xxxxxxxxxxxxx; Date: Sat, 29 Apr 2000 22:12:25 +0400 (MSK DST); Yes, it is right. In theory. And this is always right. They are right. These flags do not mean, that such packets are indeliverable. It is pure advise, and applications taking them seriously are bug; /archives/netdev/2000-04/msg00099.html (10,025 bytes)
3. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sat, 29 Apr 2000 20:29:13 +0200 (MET DST); Not nice for NBMA ... :-( If it has some means to read the ATMARP server's table, yes. Normal ATMARP (RFC1577) doesn't let it do this. The oracle has spoken ;-) My preferred way is of course to do as; /archives/netdev/2000-04/msg00100.html (9,102 bytes)
4. Re: neighbour cache vs. invalid addresses (score: 1): Author: kuznet@xxxxxxxxxxxxx; Date: Sat, 29 Apr 2000 22:40:49 +0400 (MSK DST); Why? ATMARP is not obliged even to know about this. Configure it to reply to address x.y.z.u with MAC ABCD. And order machine ABCD to relay broadcasts to all known peers or to some multicast group.; /archives/netdev/2000-04/msg00101.html (9,309 bytes)
5. Re: neighbour cache vs. invalid addresses (score: 1): Author: "James R. Leu" <jleu@xxxxxxxxxxxxxx>; Date: Sat, 29 Apr 2000 14:57:25 -0500; I hope you mean that it is not a trivial mapping to the current neigh_table setup. Broadcast and multicast do have defined meanings on CLIP interfaces, mapping this meaning to the neigh_table is wher; /archives/netdev/2000-04/msg00102.html (10,106 bytes)
6. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 00:30:35 +0200 (MET DST); RFC1577 and (RFC2225 update of 1577) have little encouragement for multicast (section 8 or 10) and make a rather fuzzy statement about broadcast (section 7 or 9). You probably mean MARS, RFC2022. Tha; /archives/netdev/2000-04/msg00103.html (9,343 bytes)
7. Re: neighbour cache vs. invalid addresses (score: 1): Author: "James R. Leu" <jleu@xxxxxxxxxxxxxx>; Date: Sat, 29 Apr 2000 18:41:40 -0500; I was actually thinking of the way Cisco handles broadcast and multicast over static point-to-point or point-to-multipoint ATM sub interfaces. <snip> So does this mean there isn't any talk of adding; /archives/netdev/2000-04/msg00104.html (9,556 bytes)
8. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 02:40:40 +0200 (MET DST); It would be good if an application could determine quickly if multicast or broadcast may actually work. If it comes back after trying for five minutes with a complaint about lack of connectivity or s; /archives/netdev/2000-04/msg00105.html (9,796 bytes)
9. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 02:49:25 +0200 (MET DST); That's PVCs, right ? With PVCs, it's simpler than with SVCs, because all hosts on the same LIS know must each other. With SVCs, only the ATMARP server knows that it knows everybody. Multi-/broadcast; /archives/netdev/2000-04/msg00106.html (8,999 bytes)
10. Re: neighbour cache vs. invalid addresses (score: 1): Author: "James R. Leu" <jleu@xxxxxxxxxxxxxx>; Date: Sat, 29 Apr 2000 20:59:18 -0500; So why doesn't ATM for Linux support this then (or does it and I'm just clueless?) All I want to do is have one PVC between two boxes, and send packets addressed to the multicast all routers address.; /archives/netdev/2000-04/msg00107.html (10,133 bytes)
11. Re: neighbour cache vs. invalid addresses (score: 1): Author: fuji@xxxxxxxxxxxxxxxxx>; Date: Sun, 30 Apr 2000 20:37:37 +0400 (MSK DST); It is reasonable in the highest extent. Until now it resulted only in more troubles. F.e. multicasts were used mainly by routing control apps, which were supposed to start in void state on bare iron; /archives/netdev/2000-04/msg00113.html (9,534 bytes)
12. neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sat, 29 Apr 2000 19:00:37 +0200 (MET DST); In non-broadcast multiple-access networks (NBMA) such as Classical IP over ATM (CLIP), neither broadcast nor multicast have any useful semantics. Right now, I catch this in neigh_table->constructor a; /archives/netdev/2000-04/msg00218.html (8,725 bytes)
13. Re: neighbour cache vs. invalid addresses (score: 1): Author: kuznet@xxxxxxxxxxxxx; Date: Sat, 29 Apr 2000 22:12:25 +0400 (MSK DST); Hello! Yes, it is right. In theory. And this is always right. They are right. These flags do not mean, that such packets are indeliverable. It is pure advise, and applications taking them seriously a; /archives/netdev/2000-04/msg00219.html (10,054 bytes)
14. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sat, 29 Apr 2000 20:29:13 +0200 (MET DST); Not nice for NBMA ... :-( If it has some means to read the ATMARP server's table, yes. Normal ATMARP (RFC1577) doesn't let it do this. The oracle has spoken ;-) My preferred way is of course to do as; /archives/netdev/2000-04/msg00220.html (9,173 bytes)
15. Re: neighbour cache vs. invalid addresses (score: 1): Author: kuznet@xxxxxxxxxxxxx; Date: Sat, 29 Apr 2000 22:40:49 +0400 (MSK DST); Hello! Why? ATMARP is not obliged even to know about this. Configure it to reply to address x.y.z.u with MAC ABCD. And order machine ABCD to relay broadcasts to all known peers or to some multicast g; /archives/netdev/2000-04/msg00221.html (9,338 bytes)
16. Re: neighbour cache vs. invalid addresses (score: 1): Author: "James R. Leu" <jleu@xxxxxxxxxxxxxx>; Date: Sat, 29 Apr 2000 14:57:25 -0500; I hope you mean that it is not a trivial mapping to the current neigh_table setup. Broadcast and multicast do have defined meanings on CLIP interfaces, mapping this meaning to the neigh_table is wher; /archives/netdev/2000-04/msg00222.html (10,164 bytes)
17. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 00:30:35 +0200 (MET DST); RFC1577 and (RFC2225 update of 1577) have little encouragement for multicast (section 8 or 10) and make a rather fuzzy statement about broadcast (section 7 or 9). You probably mean MARS, RFC2022. Tha; /archives/netdev/2000-04/msg00223.html (9,371 bytes)
18. Re: neighbour cache vs. invalid addresses (score: 1): Author: "James R. Leu" <jleu@xxxxxxxxxxxxxx>; Date: Sat, 29 Apr 2000 18:41:40 -0500; I was actually thinking of the way Cisco handles broadcast and multicast over static point-to-point or point-to-multipoint ATM sub interfaces. <snip> So does this mean there isn't any talk of adding; /archives/netdev/2000-04/msg00224.html (9,642 bytes)
19. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 02:40:40 +0200 (MET DST); It would be good if an application could determine quickly if multicast or broadcast may actually work. If it comes back after trying for five minutes with a complaint about lack of connectivity or s; /archives/netdev/2000-04/msg00225.html (9,882 bytes)
20. Re: neighbour cache vs. invalid addresses (score: 1): Author: Werner Almesberger <almesber@xxxxxxxxxxx>; Date: Sun, 30 Apr 2000 02:49:25 +0200 (MET DST); That's PVCs, right ? With PVCs, it's simpler than with SVCs, because all hosts on the same LIS know must each other. With SVCs, only the ATMARP server knows that it knows everybody. Multi-/broadcast; /archives/netdev/2000-04/msg00226.html (9,027 bytes)

Current List: 1 - 20
Page: [1] [2]