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?

Improve this question
8
  • A small image with relevant topology Commented Jan 5, 2015 at 20:24
  • Have you checked the CPU and memory utilization? What happens if you plug a single PC or laptop into the router? Commented Jan 5, 2015 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 Commented Jan 5, 2015 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. Commented Jan 5, 2015 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 Commented Jan 5, 2015 at 20:57

2 Answers 2

Reset to default
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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.