Is there a CLI command which will result in Ethernet statistics?

Happy New Year!

rgds/ldv

Try this:
where "name" is the name if the interface such as ether1

is that what you wanted?

Try this:

Code: Select all

/interface monitor-traffic "name" 

where "name" is the name if the interface such as ether1

is that what you wanted?

Thanks for the reply. My question wasn't complete or correct -- for which I apologize. I'm looking for Ethernet errors which are leading to the copper link being less reliable than a p-t-p link. Ping results across the Ethernet link in question vary from 972/1000 to 991/1000, so I'm looking to confirm what equipment needs to be changed, either the Ethernet switch or one of the two RouterBoards involved.

PW-GW (RB532a) Ether3 --- local distribution switch --- RB133 (actually RIC/522).

rgds/ldv

OK, well lets really get in to this and see if we can help you.

The wireless interfaces as well as the copper interfaces on any routerboard are both ethernet interfaces.

So it sounds to me like you are having some problems on a copper UTP/STP twisted pair infrastructure.

If you are seeing high ping times on copper infrastructure then there are various places to start looking. By and large if the Status of the copper interface is steady and autonegotiates to something sensible like 100mbs full duplex and your cable infrastructure complies with standards (not longer 100m per segment for e.g.) then there is probably not much wrong with the cabling and switches, and I would probably start to look at the switches themselves and the routerboards from a configuration point of view.

Remember that in routerboards a lot of things can inject latency in to the data flow. Here are a few examples:

1: using queues to limit traffic will inject latency
2: doing all sorts of mangle, firewall and such like on a low end routerboard like a RB133 will slow things down (reduce throughput) as the processor gets maxed out by all the manipulations you are doing
3: the new deep packet inspection or layer7 filters on routerOS 3 can require a lot of processor time too.
4: with an RB133 doing routing and some you can expect to get around 20megabits throughput before it starts to get overloaded
5: dont for get to check your IP addressing and vlans on the switches too. running multiple IP subnets on one lan segment can cause headaches.....

Does this help?

The MT have no ethernet statistics. It's high on my wishlist too. You'll have to use a managed switch.

OK, well lets really get in to this and see if we can help you.

5: ... running multiple IP subnets on one lan segment can cause headaches.....

Does this help?

This is the only point of the 5 that we hit on. This is at a distribution pop on a wireless ring. Ether1 is left side of ring (single subnet), Ether2 is right of ring (single subnet), Ether3 has 8 subnets (i.e., used for local distribution). i.e., Ether3 faces the customers (APs, ptp links, yada yada).

The severe lightning storms of summer electrocuted the Cisco 2651XMs, which were replaced with RB532As.

Are you saying using multiple subnets on Ether3 (or any other Ether port) is known to result in packet loss?

rgds/ldv

The MT have no ethernet statistics. It's high on my wishlist too. You'll have to use a managed switch.

The switch connected to Ether3 is managed, but we're trying to get double confirmation of the problem.

rgds/ldv

Some more details on your network would help.

As I understand it you are running multiple subnets on a managed switch with no Vlans enabled. This 'can' work (and in theory - as I understand it - its ok to do because the switch only cares about mac addresses and works at layer 2) but you leave yourself open to ARP attacks, which often manifest them selves as DOS attacks, overloading the processor of the switch and brining it to its knees. A symptom could be the slow network with high latency that you describe.

At least use the vlans to segment this traffic.

I am not saying that multiple subnets on routerboard ether interfaces causes problems. After all they are designed to do virtual interfaces and have multiple IP configured there.

I use them this way but I have to admit I have only ever used them with Vlanś when using different subnets and when having multiple IP per interface in the same subnet.

So, what is your network config?

but you leave yourself open to ARP attacks, which often manifest them selves as DOS attacks, overloading the processor of the switch and brining it to its knees. A symptom could be the slow network with high latency that you describe.

So, what is your network config?

Sorry for the delayed response, but I've spent the day ridding the network of martian traffic which was getting through a leak.

Please write more about how to protect from ARP attacks.

I'm not sure how to answer your question about network config. Hum another bar and I'll try to catch the tune if the below is not close to what you need.

What used to be a wireless ring until the weather disaster (lightning) of summer 2007 now resembles the big or little dipper in the sky. Each wipop has a RB532A which acts as the router. Upstream part of big dipper is connected to Ether1. Downstream part of big dipper is connected to Ether2. Ether3 is connected to customer facing Etherswitch. Ports on the switch are connected as necessary to perform distribution. e.g., AP1 ..., p-t-p links for individual customers, p-t-p links for areas for which a distribution pop is not justified (e.g., p-t-p link to AP in the middle of a pasture atop a hill. Nearly all the major wipops are on water towers.

CPEs live on a private network, acting as bridges. Customer equipment has 1..n public IPs on a case by case basis. Most customers run, e.g., a Linksys WRT54G on a public address. Others have just a computer on a public IP address.

All of our equipment is now MikroTik (save the customer gear, which started as Tranzeos and now Ubiquiti LS2 or PS2).

Again, I hope this helps -- if it doesn't, hum another bar and I'll try again.

Happy New Year!

rgds/ldv

Perhaps a good place to start finding out about ARP attacks is here: http://en.wikipedia.org/wiki/ARP_spoofing

As far as I am aware, - and at this point I have to tell you that I am not an expert on this stuff, and hopefully some other guru can jump in and help us is - the best / only way to prevent/reduce exposure to ARP attacks is to segment your network.

There are other options in RouterOS that allow you to set ARP settings per interface. Check through the manual, but you will see them in properties of an interface in winbox.

By the way, did we ever decide that you had an ARP DOS Attack problem? HAve you made any headway in reducing your latency on the copper links?

Oh, by the way thanks for the cheerful happy new year comment!

I live in Kenya and right now if you have been watching world news, we have just had elections and now our country is in chaos and rioting, but thanks for the cheery thought.

Salaams,

Alex

Perhaps a good place to start finding out about ARP attacks is here: http://en.wikipedia.org/wiki/ARP_spoofing

Thanks for the URL.

By the way, did we ever decide that you had an ARP DOS Attack problem? HAve you made any headway in reducing your latency on the copper links?

So far,
. fixed the leak in the bogon/martian filters
. disallowed sixty-seven dot two-hundred-twenty-eight dot eight dot two-hundred-four from his/her enmasse connections to each address in our /19.

Those two changes have resulted in much higher (99.4% or better), but there is still an underlying problem I haven't found.

BTW, it appears to this observer that the "timeout" in /tools/ping lengthens the cycle even if the outgoing ping packet gets a reply, whereas in RedHat/Centos, -w does not change the cycle time. I dunno.

best regards/ldv