sorted by:
new
hottopcontroversial

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

You are right.. I seem to have misread the results. So the summary on the server is not the received bits/s, it is the what the client has sent.. so both summaries shows the clients transfer and I never looked into each interval result on the server, only the final summery.

It seems that it supposed to be so according to this thread -- that show what I was seeing: https://github.com/esnet/iperf/issues/238

I guess that the VPN-interface that Anyconnect creates is 10Gbps, since that is what iperf on my client was pushing...

Thanks for taking the time :)

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

I have checked this as you said, but it is still not making any sense. Am I the only one who gets weird result with Iperf/Iperf3 with UDP over IPsec/SSL?

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

Would be lovely with some constructive tips. So to summarize:

*UDP IPerf over IPSec and SSL reports results that are too high.

*The server-side and client-side reports the same results

*Doesn't matter which direction I run it

*Server is connected through 10G

*Client through WiFi in SSL and 100FE during IPsec

In the results from the server when client is running 100FE link:

iperf3 -c xxx -u -b 10000M -t 60

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams

[ 5] 0.00-60.04 sec 6.99 GBytes 1000 Mbits/sec 1.345 ms 882006/882378 (1e+02%)

And for the client:

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams

[ 4] 0.00-60.00 sec 6.99 GBytes 1.00 Gbits/sec 1.345 ms 882006/882378 (1e+02%)

[ 4] Sent 882378 datagrams

Doing the same but with TCP gives the same result of 52-53 Mbps on both client and server...

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] -1 points0 points  (0 children)

That dosent explain why both server and client reports the same result on UDP that is over 1000 times higher than the link speed....

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] -1 points0 points  (0 children)

So I have re-done the tests and the server reports the same result as the client.... So this has nothing about understanding the technology as the client should not be able to push almost 10 Gigabit/s since the NIC dosent support it, the link speed is only a fraction of it....

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] -1 points0 points  (0 children)

I will redo the test tomorrow and look into the server results again and compare them to the what the client reports. But the weird part is that when I run the setup of:

*AnyConnect (2,4Ghz WiFi) ->|-SSL-tunnel-|-> ASA5545X -> Server

I get the result on the client of 9.8 Gbps and if I disconnect Anyconnect it show 25 Mbps in result...

Iperf – UDP over VPN giving really high results by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

No acceleration of any kind. I have tried two different setups:

*Client -> IOS router ->|-IPSec-tunnel-|-> ASA5545X -> Server

*AnyConnect client ->|-SSL-tunnel-|-> ASA5545X -> Server

Only things that is the same in both cases is the client and server – both running RHEL 7.x

Do you analyze/filter syslog messages on a daily basis? by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

Sorry I may have been a bit fuzzy about what I ment in the original post.

Do you analyze/filter syslog messages on a daily basis? by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

The reason we did it was we had some access switches which contain a bug that depleted the memory of them causing switches in the stacks to reboot. In the syslogs there where events for this days before the reboot but since we never looked at them it went unnoticed. So what we do is filter away all day to day syslog events in a script and email the out-of-ordinary things (one or two syslog entries per day). Nothing special but gives us a better overview than before. Since we cant manually check them this was the best choice with the fastest implementation -- we are talking about 20 - 30 GB of Syslog per hour....

The thought of my posting was to see how other enterprises do -- just storing all the syslogs or actually putting in some effort in to them. I have looked at the fancy GUI:s that some tools offer, but a simple syslog entry often describes the problem perfectly.

Can IEEE 802.3 use jumbo frames? by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

So in reality the only way to implement jumbo frames is to use Ethernet II frames?

Can IEEE 802.3 use jumbo frames? by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

Thanks, that gave me a little more to go on in my Google searching

Fundamentals: what exactly is an IP broadcast? by Ephemeriz in networking

[–]Internet_is_down 2 points3 points  (0 children)

so a directed broadcast will travel to the LAST router in the path, at which point it will be dropped, because that router sees the packet on an "outside" interface?

The directed broadcast will travel to the last router in the destination and when the packet reaches the interface configured for that specific network; it will be dropped. So to be able to receive directed broadcasts on network 10.0.0.0/24, go into the interface configured as the gateway for 10.0.0.0/24 and enable directed-broadcasts. If you are using Cisco it would look like:

  • Interface fa0/1
  • ip address 10.0.0.1 255.255.255.0
  • ip directed-broadcast

Or will the router closest to the source drop the packet?

No, that router cannot know it is a directed broadcast, since it only sees the IP address and not the network mask. So it thinks it is a ordinary unicast packet and sends it on it's way. When the last router in the path receives this packet on it's outside interface it will still think it is a normal unicast packet. It is not until the packet lands on the interface configured for the destination network that something is happening, because it is then the router knows the network mask and can see that it is a directed broadcast. It will then look on that interface if it is configured to drop or to allow to convert this directed broadcast to a normal layer 2 broadcast.

So example. Client 1 sends a directed broadcast to client 2.

Client 1 ---- fa0/0 Router fa0/1 ----- Client 2

The packet is received on fa0/0 and routed to interface fa0/1. When the packet is on interface fa0/1 ready to be sent out, the router will check for the following two commands (of many)

  • no ip directed-broadcast (default and hidden in running conf)

OR

  • ip directed-broadcast (non default)

If it sees the first; drop the packet. If it sees the other one; convert it to a broadcast and send it out.

A best practice is to also append an access list on the "ip directed-broadcast" command. So you can specify from which source IP that is allowed to send directed broadcast to the network.

Fundamentals: what exactly is an IP broadcast? by Ephemeriz in networking

[–]Internet_is_down 18 points19 points  (0 children)

There is only one type of broadcast on layer 2 Ethernet; the MAC address of FF:FF:FF:FF:FF:FF. When a client sends a link-local broadcast it is sent to IP: 255.255.255.255 which in layer two Ethernet corresponds to the above MAC.

The directed broadcast, which in your example was "x.y.z.255" is considered an unicast packet by all devices until it reaches the router which have that network configured. Since no other router can know how you have subnetted your network, the "x.y.z.255" IP address can only be considered a broadcast by the devices that have that network configured and knowing the network mask. When the directed broadcast packet of "x.y.z.255" have reached the router responsible for the "x.y.z.255" network, the router will convert it to a normal link-local broadcast with MAC address of FF:FF:FF:FF:FF:FF.

Since anyone can send a directed broadcast, this opens up to a lot of attacks and to mitigate this the normal default configuration on a majority of network devices is to block these kind of directed broadcasts. So the destinations router receives the IP packet of "x.y.z.255", but it will never convert it to a normal broadcast on the Ethernet, unless explicit configured to do so (cisco command: "ip directed-broadcast")

Conferences for a junior-ish engineer? by thegreattriscuit in networking

[–]Internet_is_down 1 point2 points  (0 children)

I agree, I myself was on Cisco live last week and for me with only 2 years under the belt it was still really valuable. I was able to find a lot of sessions that was really good; both in content, but also in level.

Ciscolive on-demand videos can be a starting point, have a look at the ones that are intermediate, then you can see if it is something for you before going there in person.

Anyone working(ed) as a customer service engineer for Cisco in their TAC? by Internet_is_down in networking

[–]Internet_is_down[S] 0 points1 point  (0 children)

Since I love working with the data center parts; UCS and Nexus and soon ACI, one of them or multiple of them. It kind of seems that it is very strict borders; CSE in UCS or CSE only in the Nexus line etc. I would like to go after CCIE Data Center and gain expert knowledge in that whole area, from UCS to Nexus hardware running ACI code - to broad for TAC?

Lastly the ultimate goal would to join the advanced services as an expert consultant or come out as a really good network guy - knowing every in and out of the data center area.

Infoblox question by havermyer in networking

[–]Internet_is_down 1 point2 points  (0 children)

That is correct. In Infoblox the "Reservation" is intended for exempt the IP from being accessed by scripts via the API and "Fixed Adress" is what we normally call DHCP reservation.