Multiple reasons:
a) MAC addresses can be spoofed. (and are only 48 bit long). Session ID is
64 bit.
b) A real reason is that you can have multiple PPPoE sessions to different
ISPs from same MAC addr.m
-alex
On Thu, 24 Jan 2002, Tony Williams wrote:
>
> Hi,
>
> I have a question regarding P
On Tue, 28 Aug 2001, Garrett Wollman wrote:
> < said:
>
> > Disagree. Packet is either a runt or not a runt. It cannot be
> > inconsistently bridged it to one (trunk) interface but not to (access)
> > interface.
>
> Runt-ness is not a property of the contents of the frame, it's a
> property of
On Tue, 28 Aug 2001, Garrett Wollman wrote:
> < said:
>
> > But doesn't the switch have to assume that the VLAN will be attached to
> > some non-trunked ports, in which case the packets must be an appropriate
> > length.
>
> The minimum length needs to be enforced at the output interface.
> (A
In cisco terminology, 'tcp intercept' is what the 'ip and tcp reassembly'
part of ipnat does (without port/address rewriting). For example, a router
in the middle which is doing the intercept will have to buffer/reassemble
tcp stream and only forward packets after they are confirmed good.
Example
On Sun, 1 Apr 2001, Brett Glass wrote:
> >I'm hacking on a 'magic box' solution, which will essentially listen for
> >ARP packets from box A to box B, reply with its own MAC, and then forward
> >ethernet packets back onto the same wire, rewriting the MACs
> >appropriately.
>
> Sort of like static
On Sun, 1 Apr 2001, Brett Glass wrote:
> At 07:27 AM 4/1/2001, Wes Peters wrote:
>
> >Why use PPPoE -- you really prefer to toss away gobs of bandwidth?
>
> I don't see why it should be that inefficient. In fact, I've been
> thinking that due to header compression it might even be a bit
> fast
On Sat, 17 Mar 2001, Garrett Wollman wrote:
> That's the way Internet routing is supposed to work. If your routing
> table says a packet supposed to go one way, and it really needs to go
> another way, that's *user error* -- if you misconfigure your routing,
> FreeBSD will do what you ask it to;
haring (nameservers for domain are usually
queried randomly) and reliability (if one connection is down, everything
still works, because the other "half" of nameserver is still running and
giving out IPs on the correct interface).
--
--
Alex Pilosov| http://www.acecape.com/dsl
CT
te: On local network, you'll be essentially having two logical
networks (different IPs, subnet, etc) on the same wire. Its not clean, but
its perfectly supported.
Now, assume you have IPs 11.1.1.* from ISP B, and 11.1.2.* from ISP B. You
configure both IPs to machines on your 'local' n
te2' which does support it, by having
multiple routing tables, and a ruleset that decides which routing table to
use based on packet details.
With policy routing, you indeed will be able to multihome, without any
cooperation of your upstream (assuming strict filters on their ingress
interfaces) an
On Fri, 9 Feb 2001, Chris Dillon wrote:
> On Fri, 9 Feb 2001, Dan Nelson wrote:
> Cool, if thats all it will take, I'll give it a try. But, whatever
> method Compaq/Intel is using doesn't require me to set up the ports on
> the switch as being part of a trunk. It "just works". And IIRC, when
On Thu, 8 Feb 2001, Andrea Venturoli wrote:
> My wonderings are: _ "mediaopt full-duplex" does not work, while it's
> documented in the rl man page; isn't this a bug?
According to your email, mediaopt full-duplex works, but only if it is
specified concurrently with media keyword. half-duplex doe
On Tue, 23 Jan 2001, Bruce R. Montague Brucem wrote:
> Does anyone have a way to run multiple PC emulators,
> each running FreeBSD (of course) on a single FreeBSD
> machine? And then cluster the virtual machines using
> a virtual network driver/simulator? The intent here
> is to literally run mul
Actually answer to original question is here:
http://synscan.nss.nu/programs.php
I am not sure if it works on fbsd, last time I looked at it, it had a few
linuxisms hardcoded...
-alex
On Tue, 23 Jan 2001, Renaud Waldura wrote:
> An amusing trick to populate the ARP table is to ping the broadc
On Wed, 3 Jan 2001, C. Stephen Gunn wrote:
> I agree that you could educate ifconfig in the ways of netgraph
> and hide it all behind the command interface you propose. It's a
> migration to a broader view of interfaces for ifconfig(8). Right
> now, ifconfig(8) is basically a front-end for ioct
On Tue, 2 Jan 2001, C. Stephen Gunn wrote:
> For example, you would no longer simply ``ifconfig xl'', but
> associate a netgraph link-layer node on top of the xl interface,
> and a netgraph interface node on top of the link-layer node, which
> would function (mostly) like xl does now.
Interesting
16 matches
Mail list logo