cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
525
Views
0
Helpful
2
Replies

Measuring TCP/IP packets - Sun or TCP/IP issue? Help!

pwijngaarden
Level 1
Level 1

Hi all,

I am working with my vendor on measuring the Gi interface, a TCP/IP output from our GSM standard GPRS (SGSN/GGSN) network element. Any helpful advice from anyone is appreciated! We have smart people working with us, but we are at the end of our tether...

Detailed description of problem follows:

Technical information:

Host: SunFire V210

PCI card: ce interface, board-model 501-6522

OS: Solaris 8, 02/04

Drivers: 111883-27 (ce), 113680-01 (bge)

No traffic detectable on external interface card

The interface cards are only supposed to capture traffic to feed into a monitoring system. The captured interface is Gi and the traffic is TCP/IP over fast ethernet (100BaseT). The monitoring point is located between an active tap and the SunFire V210. After plugging in the patch cable, usually you see the traffic when you do a snoop on this interface. We have the case, that nothing can be seen on the additional quad PCI card (ce interface), except from loop back packets from the cisco switch (Catalyst 2950). When the same links are connected to the internal interfaces of the Sun (bge), traffic can be detected but with about 30% of input errors. The following drivers are installed: 111883-27 for the ce interface, 113680-01 for the bge. The same setup is working with the same kind of traffic on a other machine.

Input errors

The 30% of input errors on the Gi link is caused by ethernet packets with a payload of 1502 bytes. The bge interface card can not be configured to handle jumbo-frames. The ce interfaces can be configured to allow it but because of the above mentioned issue, we can not swap to that interface.

inhouse test showed, that we also could not detect jumbo packet on the external card . When we sent a normal size packet and after that a jumbo packet, we could see the normal size but not the jumbo. After reconfiguration of the system, the card could handle the bigger packets. Maybe these two problems are related

Final note: we have checked standards, maximum packet size normally set to 1500, but standard says higher are allowed. VLAN Tagging, with VLAN ID enabled, and we need this to support trunking. What can we try, to read all frames, successfully?

2 Replies 2

wong34539
Level 6
Level 6

if the 2950 is able to set the system mtu greater than 1500, it should be ready to pass baby giant frames but we need to be 100% sure of the following : - the modele of 2950 is baby-giant capable (ASIC ready) - its code version is greater than 12.1(6)EA2 - after the system mtu change, the 2950 has been reloaded - thus, in both sides of customer network, If all this assumptions are validated, then we would have to check every ports on the full path from the NIC card A to the destination NIC card B to see where the frame is dropped. (with the help of this link: http://www.cisco.com/warp/customer/473/53.shtml#cat3550 <http://www.cisco.com/warp/customer/473/53.shtml>) and particularly this command : show controllers ethernet-controller mod/port

The statement about SunOS 4.1.x was probably not even true when
Stevens was finally published: it is certainly not true now (not least because
4.1.3 had some serious Year 2000 issues). Among UNIX-based implementations,
Linux is almost certainly the most popular (by number of
hosts) on the Internet. However, a large number of web servers etc. are
still based on Suns, running, in general, Solaris 2.6, 2.7 or 2.8. The vast
majority of machines on the Net these days1 are running Windows of some
flavour, now that Windows is shipped with TCP/IP.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: