[Asterisk-Users] re hardware requirement - asterisk

Rich Adamson radamson at routers.com
Thu Jan 15 06:04:14 MST 2004


> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>          address: 00:02:55:30:54:28
>          media: Ethernet autoselect (100baseTX full-duplex)
>          status: active
>          inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>          inet6 fe80::202:55ff:fe30:5428%fxp0 prefixlen 64 scopeid 0x1
> xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>          address: 00:01:02:78:11:e8
>          media: Ethernet autoselect (10baseT)
>          status: active
>          inet 203.219.167.126 netmask 0xfffffffc broadcast 203.219.167.127
>          inet6 fe80::201:2ff:fe78:11e8%xl0 prefixlen 64 scopeid 0x2
> 
> For fxp0, the internal interface although the nic can do full-duplex it 
> seems to me that it is only running simplex!!
> 
> Same for xl0, the external interface. It is running 10BaseT but again it 
> is simplex.
> 
> Does that affect my voip performance? Is it true that every step of the 
> way the network has to be full-duplex?

There are no RFC standards on "how" duplex settings are negotiated across
a cat 5 cable, etc. Most vendors support auto-negotiate, but somewhere
near 50% of the time, its negotiated incorrectly. Part of the problem is
that both ends of the cable attempt to negotiate at roughly the same time,
one end locks into full while the other locks into half.

When that happens, the end that "thinks" full duplex is fine steps all over
the packets being sent from the half-duplex end, causing damaged packets,
etc. Since we're talking about UDP traffic, that's Not A Good Thing.

The system will run fine if both ends are operating at half duplex, however
bandwidth (and performance) will be limited to something below about 30%
utilization. In many systems, that is more then adequate. However, on a
heavily loaded system, statically locking the interfaces (at both ends)
to full duplex will allow utilizations up towards 90% without degradation.

Rich





More information about the asterisk-users mailing list