3

I have a brocade 6740 that I am using as my gateway. All traffic on the network performs as expected, EXCEPT when I actually access the ip address of the gateway.

For example, if I ping the gateway my latency is over half a second

EDIT: Brocade has confirmed that ICMP on virtual interfaces is extremeley low priority for the CPU, which is why ping times are high (expected behavior) However this does not answer the issue of why telnet/ssh to these interfaces are slow, Brocade has also confirmed this is NOT expected behavior.

root@workstation:~# ping 10.0.112.2
PING 10.0.112.2 (10.0.112.2) 56(84) bytes of data.
64 bytes from 10.0.112.2: icmp_req=1 ttl=64 time=605 ms
64 bytes from 10.0.112.2: icmp_req=2 ttl=64 time=606 ms
64 bytes from 10.0.112.2: icmp_req=3 ttl=64 time=606 ms
64 bytes from 10.0.112.2: icmp_req=4 ttl=64 time=606 ms
64 bytes from 10.0.112.2: icmp_req=5 ttl=64 time=606 ms

But if I ping a machine that is behind my gateway latency is exactly what i expect, ie under .2ms

root@workstation:~# ping 10.0.121.50
PING 10.0.121.50 (10.0.121.50) 56(84) bytes of data.
64 bytes from 10.0.121.50: icmp_req=1 ttl=63 time=0.207 ms
64 bytes from 10.0.121.50: icmp_req=2 ttl=63 time=0.193 ms
64 bytes from 10.0.121.50: icmp_req=3 ttl=63 time=0.184 ms 
64 bytes from 10.0.121.50: icmp_req=4 ttl=63 time=0.181 ms

This becomes a problem when ssh/telneting into the switch any configuration is painful due to the latency

The interface is configured as a virtual ethernet interface with an ipaddress

switch-01# show running-config rbridge-id 15 int ve
interface Ve 112
ip dhcp relay address 10.0.100.223
ip proxy-arp
ip address 10.0.112.2/22
no shutdown
!

My routing table is simple, and looks as such. Note that in this situation I am still staying within the switch-01, the traffic does not leave the network I am just routing across vlans(ie, it does not traverse the default route of 0.0.0.0/0 below)

switch-01# show ip route
Total number of IP routes: 9
Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link
    Destination        Gateway         Port           Cost          Type Uptime
1       0.0.0.0/0          10.66.6.1       Ve 666         1/1           S    28d17h
2       10.0.100.0/24      DIRECT          Ve 100         0/0           D    28d17h
3       10.0.108.0/23      DIRECT          Ve 108         0/0           D    28d22h
4       10.0.112.0/22      DIRECT          Ve 112         0/0           D    28d22h
5       10.0.118.0/23      DIRECT          Ve 118         0/0           D    28d22h
6       10.0.121.0/24      DIRECT          Ve 121         0/0           D    28d22h
7       10.0.123.0/24      DIRECT          Ve 123         0/0           D    28d22h
8       10.0.124.0/23      DIRECT          Ve 124         0/0           D    5d23h
9       10.66.6.0/29       DIRECT          Ve 666         0/0           D    28d17h

My question basically boils down to - why is this interface so slow when communicating directly to a machine, however the traffic traversing this interface is quite speedy?

  • Have you checked the CPU and memory utilization? What happens if you plug a single PC or laptop into the router? – pooter03 Jan 5 '15 at 20:36
  • CPU and MEM usage are very low, cpu load is around 1, memory is around 35% usage. Not sure what you mean by 'plug a single pc' in? I do have one plugged in, as you can see by my ping results – Party Time Jan 5 '15 at 20:47
  • I was curious if you could check the latency when only a single PC is plugged into the Brocade and have everything else is unplugged. Basically, trying to isolate the network behind the gateway to see if anything on there is causing an issue. Obviously, this may not be easily done or possible depending on how busy your network is. – pooter03 Jan 5 '15 at 20:53
  • Oh, yeah not gonna happen haha. Frankly this barely registers as a 'problem' so I can't schedule an outage for it, it's mostly my curiosity – Party Time Jan 5 '15 at 20:57
2

Maybe it is just that gateway gives most CPU cycles to traffic forwarding as it should and less to admin part. This way denial of service attacks on IP of the gateway itself would be less visible,

| improve this answer | |
1

The first edit describes why ping to a VE is slow (expected) but the other issue of ssh/telnet being slow was due to a firmware bug and was solved by an update to a later version of NOS

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.