Subject: Re: Re: Routing issue with atalkd

From: "Konstantin Reznitsky" <[email-masked]>
Date: Fri, 02 Jun 2000 13:08:10 +0000 (GMT)

On Fri, 2 Jun 2000 Patrik Schindler  wrote:
> At 19:30 Uhr +0000 01.06.2000, Konstantin Reznitsky wrote:
> 
> >I have a strong feeling that your primary interfaces on the routing linux
> >boxes a set to the outside networks (NOT on the link in between)
> 
> I know the term "primary interface" only with MarsNWE. Could you explain this further?

The first interface you define becomes the primary one. Afpd by default will bind to the first zone on this interface unless 
forced othewise in the startup of the afpd itself (something like server_name@zone_name).

> 
> > > asun recomended to upgrade to the latest by then kernel, but that did not help.
> 
> He wrote that to me, too.

But with me it was RH-6.1 and I think kernel 2.2.12 :) awhile ago...

> 
> > > I also had to force the afpds to the zones I wanted (not default). I'm still not sure
> > how all this will work in a chain with more then two routing linux boxes (luckely
> > I never needed this).
> 
> Badly enough, it seems that multicasting (used for broadcasting nbp information) won't
really work (reliable) further away than one hop.
> 
> I'll have a look at atalkd but I don't have much hope to get this fixed.

If you really can deal with the code of atalkd (I'm not good enough, sorry) I can give you couple more tips:
1. Could get it working not only when both primary interfaces were set for the link, but also with only one being on the link and 
another one on the external network (this might be the way to get it working in the longer chain);
2. I want to confirm what you said about routing, rtmp and zip are actually working the problem seems to be in the propagation 
of the nbp information;
3. My experiment was not really clean - one of the boxes had different types (3Com PCI and ISA NE2000) of the network 
adapters and that seemed to affect the situation as well ( in the mater of swapping the network interfaces it was giving 
different results).
4. The final layout of the network was a star consisting of 12 dual-homed routing servers. Primary interfaces were set inside,
afpds bound to the zones on the outside, so they were showing up in their local zones in the chooser. Worked good for about 
6 months, then was replaced with appletalk routing gigabit switches (just for the bandwidth reasones), servers are still there, 
but as just servers. 
So I never had chance to play with a chain of routers, but in the nearest future I might have to, network is still growing 
(that's why I'm interested in the solution). 
Sorry, almost forgot! When the linux routing structure was still in place it also included the Caman's Gator boxes with 
ethernet connection to the local networks and their own localtalk segments. The network was completely transparent from 
any location. Gator box is not a linux router, but there we had a system with max 4(!) hops.

I hope this will give you something...
 
> :wq! PoC
I'm also still interesed in the information on the appletalk routing. I asked this question before and got contrary answers.
It has to do with redundant routing and equal cost multipath, is it doable with appletalk? Any Ideas?

Konstantin

---

From: Patrik Schindler <[email-masked]>
Date: Sat, 3 Jun 2000 00:03:38 +0200

>forced othewise in the startup of the afpd itself (something like server_name@zone_name).

Okay. But is that important if I configure all interfaces as seeding and allow routing?

eth0 -seed -phase 2 -net 40-49 -addr 41.1 -zone "PoC-Net"
eth1 -seed -phase 2 -net 50-59 -addr 51.1 -zone "PoC-Net"
tap1 -seed -phase 2 -net 5 -addr 5.2 -zone "PoC-Net"

>But with me it was RH-6.1 and I think kernel 2.2.12 :) awhile ago...

I used Kernel 2.0.33 this time. :-)

>another one on the external network (this might be the way to get it working in the longer chain);

Uhm. I'm thinking that it's not important where actually afpd binds to if one uses atalkd as a router.
In the example above, tap1 is the last device. But a nbplkup shows:

                          leela:AFPServer                          5.2:130
                      QMS-Spool:LaserWriter                        5.2:128
                          leela:netatalk                           5.2:4
                          leela:Workstation                        5.2:4

So it binds all to the last defined interfaces.

>2. I want to confirm what you said about routing, rtmp and zip are actually working the problem seems to be in the propagation 

I confirmed that with (t)ethereal. Listening to the link (tap) device shows the nbp-requests from the remote side. Listening to any other interface (eth0 or eth1) doesn't show up the nbp-requests. So it's quite clear that forwarding nbp requests won't actually happen with atalkd (as it should do).

Let me citate from README.ASUN:

>problems with appletalk:
>        certain ethernet card/drivers don't deal well with the fact
>        that appletalk aggressively uses hardware multicast. here are
>        a few ones that may cause problems:
>            ne2000 clones
>            3Com501 cards (maybe others)
>            intel etherexpress/pro
>              set multicast_filter_limit=3 in linux if you're having
>              problems with this card. to do that, add the following
>              line to /etc/conf.modules:
>                 options eepro100 multicast_filter_limit=3

>(that's why I'm interested in the solution). 

Quite clear :-)

>I hope this will give you something...

Not to much but may thanks for your explanations!

>It has to do with redundant routing and equal cost multipath, is it doable with appletalk? Any Ideas?

I didn't test it but as stated in my answer to your question a time ago, I think it should work.

:wq! PoC