Mike Tancsa writes:
> At 08:44 PM 10/15/2001 -0700, Archie Cobbs wrote:
> >This makes sense.. and that's is exactly what queues are for:
> >absorbing bursts. If you have big bursts then you'll need big
> >queues.. in general this is the only reason to have them.
>
> The only mystery I didnt solve
At 08:44 PM 10/15/2001 -0700, Archie Cobbs wrote:
>This makes sense.. and that's is exactly what queues are for:
>absorbing bursts. If you have big bursts then you'll need big
>queues.. in general this is the only reason to have them.
The only mystery I didnt solve in the end was what was genera
Mike Tancsa writes:
> >> Is it better for the networking layer to deal with this (potentially
> >> introducing some latency) as opposed to letting the application ?
> >
> >But no, the network should just do "best effort".. that is, unless
> >you are a telco type in which case, go back to your X.2
[Quoting Archie Cobbs, I think:]
>> There is probably a good paper somewhere outlining the "best effort"
>> philosophy but I don't know what it is.
That would be ``End-to-End Arguments in System Design'' by Jerry
Saltzer, Dave Reed, and Dave Clark, one of the most influential papers
ever written
Hi,
On Mon, 15 Oct 2001, Matthew Emmerton wrote:
> The problem I'm having is that I cannot connect to the mail server on
> network A (10.0.0.2) from any machine behind the NAT gateway on network B.
The mailserver is BEHIND the NAT box on network A? If so does your NAT do
any form of forwarding?
On Mon, 15 Oct 2001 23:00:27 + (UTC), in sentex.lists.freebsd.net you
wrote:
>Mike Tancsa writes:
>> >If the forwarding path is maxed out, then it is the application layer's
>> >responsibility to back off (think TCP).
>>
>> Is it better for the networking layer to deal with this (potentially
> On Mon, Oct 15, 2001 at 07:28:49PM -0400, Matthew Emmerton wrote:
> > I've got two networks -- A (10.0.0.0/24) and B (192.168.0.0/24), both
> > behind NAT gateways.
> >
> > The problem I'm having is that I cannot connect to the mail server on
> > network A (10.0.0.2) from any machine behind the
Matthew Emmerton wrote:
> I've got two networks -- A (10.0.0.0/24) and B (192.168.0.0/24), both
> behind NAT gateways.
>
> The problem I'm having is that I cannot connect to the mail server on
> network A (10.0.0.2) from any machine behind the NAT gateway on network B.
> However, any system on
I've got two networks -- A (10.0.0.0/24) and B (192.168.0.0/24), both
behind NAT gateways.
The problem I'm having is that I cannot connect to the mail server on
network A (10.0.0.2) from any machine behind the NAT gateway on network B.
However, any system on network B can successfully ping the g
Mike Tancsa writes:
> >If the forwarding path is maxed out, then it is the application layer's
> >responsibility to back off (think TCP).
>
> Is it better for the networking layer to deal with this (potentially
> introducing some latency) as opposed to letting the application ?
Oops, can substi
>If I remember correct VLANs are not
>even in ifTable, since they are not interfaces
Why not? My reading of RFC 2863's section 3.1 says that although
the VLAN multiplexing was not explicitly considered, it fits the
ifStack model perfectly, and satisfies the requirements for defining
a layer (n
At 10.10.2001, you wrote:
>On Tue, Oct 09, 2001 at 10:19:09PM -0700, Bill Fenner wrote:
>
> > (ifSpeed says "For a sub-layer which has no concept of bandwidth, this
> > object should be zero." I'd argue that this describes VLAN interfaces.)
>
>not that the vendor is always right or anything, but
> But the definition of threshhold TTL says that a
>incoming multicast packets will be forwarded out of an
>interface only if it has the TTL value >= threshold
>TTL of that interface. Am I right?
No. Zero is special, and means do not forward. If you have
the kernel source, check out the ip_mdq
[a rather delayed response to this posting]
In message <[EMAIL PROTECTED]>, Garrett Wollman write
s:
>In looking over mbuf handling for TCP some more, I noticed a puzzling
>omission. When sosend() is handed an mbuf chain rather than a uio, it
>makes no effort to check whether the chain would ac
After 2 or 3 minutes it does work, the
weird thing is that it was working No problem for 2 years and then suddenly it
stopped working. Yes, our modem pool IP addresses all have PTR records, just
not forward DNS (we aren't that stupid). When I specify a few of the non working
hosts in /etc/
I have
seen a similar timeout problem, though not with dial up. The problem was
with the ident protocol talking to other mail servers. When I turned off
this check, performance improved greatly.
In the
sendmail.cf file, I changed the ident timeout to zero to disable
it.
O
Timeout.i
After the 2 or 3 minute delay, does it work?
Looked in /var/log/maillog for reject causes? Are all the hosts you want
to allow to send specified in /etc/mail/relay-domains? If you want to try
to see if dns is the cause, specify a few of the non working hosts in
/etc/hosts. Personally as
Hi, I've had this problem for
a few days now, we have a small dial-up ISP and when users dial into one of our
cities they get a 209.xxx.xxx.xxx IP and our mail server responds normally, we
have another modem pool in that city that consists of 206.xxx.xxx.xxx IP
addresses, if a user gets a 2
This actually sounds like a problem I hit once where the default
settings actually restrict the number of ports.
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.first: 1024
net.inet.ip.portrange.last: 5000
net.inet.ip.portrange.hifirst: 49152
net.ine
Hi all,
I am using mrouted (release 3.8) code on my system.
In the code I find that for non-member interfaces of a
multicast group, threshold TTL is set to 0.
Like this.
prun_add_ttls(gt)
struct gtable *gt;
{
struct uvif *v;
vifi_t vifi;
for (vifi = 0, v = uvifs; vifi < nu
20 matches
Mail list logo
