VLAN Tagging adds packet overhead. Since the packets must go through
the CPU, there is no real speed benefit to using VLAN tagged interfaces
versus discrete physical interfaces. The extra bytes (wow, so many) per
packet and the overhead of processing VLAN tags is fairly minimal today.
If it's very sensitive information, don't trust 802.1Q to segregate your
traffic and use encryption if possible.
That all being said, latency and throughput given the scenario of up to
32mbps from the ADSL side and the same maximum from the LAN side should
have no problem being trunked if the link is 100mbps. Jitter should not
be a factor.
In terms of computer usage, the additional address space and devices on
the PCI bus for 7 discrete NICs will likely not exceed the internal PCI
bus bandwidth on a 4801. While there is overhead associated with both,
I believe that the native tax of additional PCI devices is not going to
hamper things here.
In other words, for the best packet performance and lowest latency,
discrete NICs should be used. However, it tends to become an academic
exercise given the capabilities of even low cost goods these days, such
that 100mbps of VLAN tagging is the norm to the point where it's expected.
In this scenario, it's probably cheaper to just get an add-on card, as
m0n0wall compatible QFE's can be purchased for $20+ on eBay.
I wouldn't count on having a lot of luck with QoS on a 4801 handling
that much bandwidth (at peak)... which is always when people seem to
notice when things fail...
The largest concern (like how I saved it for the bottom of my post?) is
that m0n0wall doesn't support source routing that I'm aware of. Is it a
requirement that Customers from LAN A have all of their traffic routed
to Gateway A/(ADSL A) and LAN B have all of their traffic routed to
Gateway B/(ADSL B) ?
Lonnie Abelbeck wrote:
> Chris,
>
> You might also consider a stock net4801 (3 NIC''s) with an HP Procurve
> 1800-8G with the opt1 (third) interface configured as a VLAN tagged port
> to the Procurve. Configure the Procurve accordingly to the untagged
> interfaces.
>
> My hunch is this approach would be more efficient than a add-on card,
> but I have no data to support that.
>
> Anyone here conduct such a test?
>
> Lonnie
>
> On Apr 26, 2007, at 4:11 PM, Chris Bagnall wrote:
>
>> Greetings list,
>>
>> I know there've been many discussions in the past about the routing
>> performance of Soekris boxes, but wonder if anyone's done any tests
>> with 7 interfaces. I'm not so worried about raw routing performance
>> between two interfaces, but I am concerned that the thing shouldn't
>> encounter excessive delay (latency) when routing between multiple
>> interfaces.
>>
>> Basically, I need to come up with a router (running m0n0 or pfSense -
>> undecided at this stage) that'll handle 3 independent LANs (3
>> companies in one building), and 4 ADSL connections. The 4 ADSLs will
>> *not* be load-balanced - there'll just be some custom routing to make
>> sure that traffic from company A's phone server goes out via ISP A, B
>> via B, etc. etc., so from a feature-set perspective it doesn't matter
>> whether it's pfSense or m0n0.
>>
>> The maximum speed each ADSL's going to hit is 8mbit (and that's
>> unlikely - 5mbit is more realistic) so raw throughput isn't an issue.
>> There should be no LAN -> LAN routing between the 3 companies' LANs.
>>
>> The primary concern here is latency for the phone servers. Oh, one
>> other quick thing - do folks recommend getting the
>> Soekris-manufactured 4xEthernet PCI card, or is it preferable to get
>> something like a 4-port Intel Pro/100?
>>
>> Any suggestions gratefully appreciated. The small form factor and lack
>> of moving parts of the Soekris appeals considerably, but before I can
>> use it, I do need to check it'll be up to the task.
>>
>>
>> Regards,
>>
>> Chris
>> --C.M. Bagnall, Director, Minotaur I.T. Limited
>> For full contact details visit http://www.minotaur.it/chris.html
>> This email is made from 100% recycled electrons
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>