Re: Problems with vlan + carp + alias

[Giulio Ferro]

Primeroz lists wrote:
What is tcpdump showing for ping on 192.168.10.11 
 ? can you see echo reply exiting vlan10 
interface ?


what if you try from your server to "ping -S 192.168.10.11 
 192.168.10.254 " ?





First of all I'm sorry for the late reply. Yesterday I could do some more
in-depth test to analyze this strange behavior of my firewall.

The 192.168.10.0/24 range I used in the previous example isn't the real
one, I just used it for simplicity´s sake.
The true range, the one which has been assigned by the ISP to my customer
is: x.y.z.128/27. (x.y.z corresponds to a true public IP address)

I've deactivated the firewall, so we have one less thing to worry about:
/etc/rc.d/pf stop
This is a pure network configuration issue.

Here is the relevant part in /etc/rc.conf:
---
...
ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0"
...
cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 
carp30 carp40 carp128"

...
ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 
vlandev bce0"

...
ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255"
ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255"
ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255"
ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255"
ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255"
ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255"
ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255"
ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255"
ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255"
ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255"
...
defaultrouter="x.y.z.129"
---

On my managed switch I've set 2 ports:
1) the one where the bce0 interface is plugged in : mode trunk with all 
the vlans above

2) the one where the ISP internet is plugged in : mode access with vlan 128

I've also set the ip interface of my switch to x.y.z.155 vlan 128


Here is the relevant part of netstat -rn on my machine
---
defaultx.y.z.129UGS 013966 vlan12
x.y.z/27 link#11UC  00 vlan12
x.y.z.132x.y.z.132UH  00 carp12
x.y.z.133x.y.z.133UH  00 carp12
x.y.z.134x.y.z.134UH  00 carp12
x.y.z.135x.y.z135UH  00 carp12
x.y.z.136x.y.z.136UH  00 carp12
x.y.z.137x.y.z.137UH  00 carp12
x.y.z.138x.y.z.138UH  00 carp12
x.y.z.139x.y.z.139UH  00 carp12
x.y.z.140x.y.z.140UH  00 carp12
x.y.z.141x.y.z.141UH  00 carp12
x.y.z.15500:1e:c9:90:4a:c0  UHLW18 vlan12   1183

---



Here come the tests.
1) From the firewall : basic
I can ping both the default gateway (x.y.z.129) and the switch interface 
(x.y.z.155)

I can ping a generic internet address (a.b.c.d)
With tcpdump I can see the packets leaving as x.y.z.157 and coming with 
the same

address

2) from the switch : basic
I can ping the firewall's vlan address (x.y.z.157)
I can ping _ALL_ the carp interfaces, base and alias:
   ping x.y.z.157 -> OK
   ping x.y.z.132 -> OK
   ping x.y.z.133 -> OK
   ...
   ping x.y.z.141 -> OK

3) from the internet : basic
From an external internet address I can ping the vlan address:
   ping x.y.z.157 -> OK

4) from the firewall : advanced
From the firewall I can ping the switch address from one of the carp
base and aliased address:
   ping -S x.y.z.132 x.y.z.155 -> OK
   ping -S x.y.z.133 x.y.z.155 -> OK

I _cannot_ ping the default router from one of the carp addresses:
   ping -S x.y.z.132 x.y.z.129 -> NOT OK
   ping -S x.y.z.133 x.y.z.129 -> NOT OK
By using tcpdump on the vlan128 interface I can see the packets
_BOTH_ leaving and coming from the carp addresses. It just seems
that the carp interfaces can't process the packets properly.

5) from the internet : advanced
From an external internet address I _cannot_ ping the carp addresses
(x.y.z.132 and up)
As above, I can see the incoming packets with
tcpdump -i vlan128 -n icmp


Ok, that was long. I hope someone can help to shed light into this, to see
whether this is a bug or not.
I stress again that the _same_ configuration works as it should on a 
physical

(non-vlan) interface.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Use lagg(4) or Use Layer-4 Load Balancing?

[Vince Hoffman]

Martes G Wigglesworth wrote:

I was attempting to find good information on how to achieve a type of
bonding using advanced routing on FreeBSD, such as with layer-4 routers,
that can bond multiple sources into a single overall larger source for
logical backbone creation for networks.



You could have a look at ng_one2many(4) I've never used it but it sounds 
like it could be what you are after according to the manpage.



Vince



On Wed, 2008-06-18 at 13:22 -0400, Andrew Thompson wrote:

On Tue, Jun 17, 2008 at 04:32:03AM -0400, Martes G Wigglesworth wrote:

Greetings all.

I have been attempting to research what  I have been informed is
actually accomplished with layer-4 load balancing.  I have seen many
articles and reviews that indicate that lagg(4) will accomplish the
teaming of multiple internet access sorces into a single logical pipe,
however, I have tried this using a dumb switch two nic interfaces and
this simply is not the case.  


I am new and may not have enough cool equipment around, however, aside
from using the fail-over mode for redundancy, and lacp on a supported
switch, then if lagg(4) could really combine multiple sources into one
for use as a larger overall backbone, then I should be able to get
doulbed bandwidth using two separate ports on an unmanaged switch using
some option on the lagg(4) driver, which is not the cast.(if this is
wrong I would be happy to get the correct information, however I have a
few network engineer references that say that you cannot do anything
more than layer-2 lacp with appropriate equipment to create an
isp-supported trunk)  Even in the on-lamp interview the 7.0 developer
implies that you can do what I am attempting to research however, it is
not possible at layer 2 without an end-point.

How are you testing this? You need to have multiple IP flows in order to
fully utilise the multiple links. See this snippet from the handbook
(i'll put it in the man page too).

"Since frame ordering is mandatory on Ethernet links then any traffic
between two stations always flows over the same physical link limiting
the maximum speed to that of one interface. The transmit algorithm
attempts to use as much information as it can to distinguish different
traffic flows and balance across the available interfaces."


Does that answer your question, you will not get more speed on a single
download.


Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Seeking help understanding my "emX: watchdog timeout" messages

[Rudy]

Reading if_em.h

 77  * EM_TIDV - Transmit Interrupt Delay Value
 78  * Valid Range: 0-65535 (0=off)
 79  * Default Value: 64
 80  *   This value delays the generation of transmit interrupts in units of
 81  *   1.024 microseconds. Transmit interrupt reduction can improve CPU
 82  *   efficiency if properly tuned for specific network traffic. If the
 83  *   system is reporting dropped transmits, this value may be set too high
 84  *   causing the driver to run out of available transmit descriptors.


seems to indicate that 'dropped transmits' may be due to the 'tx_int_delay' being too high.  So, I 
lowered the Transmit Interrupt Delay Values 33 useconds.  I will report if this helps.

Does anyone have experience using tuning these values?

 dev.em.2.tx_int_delay: 33
 dev.em.2.tx_abs_int_delay: 33


The Intel docs explain the tx_int_delay vs the tx_abs_int_delay:
"In [high traffic] situations, the absolute timer is the source of most
 device interrupts. Under light loads or brief bursts of traffic, the
 packet timers are the primary source of interrupts.  In these situations,
 the packet timers determine the latency suffered by most packets. The
 packet timers also determine the minimum traffic rate required to trigger
 the absolute timer interrupts. For example, if the traffic rate is high
 enough to prevent the packet timer from ever expiring, then the GbE
 controller does not interrupt until the absolute timer has expired."

That is why I picked a tx_abs_int_delay == tx_int_delay.

The source code references running out of available transmit descriptors...
Is there a way to bump up the number of available transmit descriptors or to change the packet 
buffer size?  here is the dev.em.2.debug info:


 kernel: em2: Adapter hardware address = 0xc4d91224
 kernel: em2: CTRL = 0x400c0241 RCTL = 0x8002
 kernel: em2: Packet buffer = Tx=16k Rx=32k
 kernel: em2: Flow control watermarks high = 30720 low = 29220
 kernel: em2: tx_int_delay = 32, tx_abs_int_delay = 32
 kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 66
 kernel: em2: fifo workaround = 0, fifo_reset_count = 0
 kernel: em2: hw tdh = 41, hw tdt = 41
 kernel: em2: hw rdh = 130, hw rdt = 129
 kernel: em2: Num Tx descriptors avail = 254 (Can I increase?)
 kernel: em2: Tx Descriptors not avail1 = 15 (Why not available?)
 kernel: em2: Tx Descriptors not avail2 = 0
 kernel: em2: Std mbuf failed = 0
 kernel: em2: Std mbuf cluster failed = 0
 kernel: em2: Driver dropped packets = 0
 kernel: em2: Driver tx dma failure in encap = 0

(not sure why tx_int_delay is 32 when I set it to 33... starts counting at 0?)


Rudy



Reference for if_em.h:
  http://fxr.watson.org/fxr/source/dev/em/if_em.h?v=FREEBSD7
Referenve for Absolute vs Packet timer:
  http://www.intel.com/design/network/applnots/ap450.pdf  (page 12)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd

[mav]

Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd

State-Changed-From-To: patched->closed
State-Changed-By: mav
State-Changed-When: Sun Jun 22 22:26:06 UTC 2008
State-Changed-Why: 
Patches merged, no more feedback received.

http://www.freebsd.org/cgi/query-pr.cgi?pr=123741
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"