{"id":132,"date":"2018-01-07T15:34:56","date_gmt":"2018-01-07T15:34:56","guid":{"rendered":"https:\/\/www.kuncar.net\/blog\/?p=132"},"modified":"2018-01-09T00:44:51","modified_gmt":"2018-01-09T00:44:51","slug":"rfc2544-testing-explained","status":"publish","type":"post","link":"https:\/\/www.kuncar.net\/blog\/2018\/rfc2544-testing-explained\/","title":{"rendered":"RFC2544 Testing explained"},"content":{"rendered":"

\"\"This next article in this mini-series about testing Ethernet\/IP networks I will write about one of the most common test \u2013 the\u00a0<\/span>RFC2544<\/a>\u00a0\u00a0\u201d<\/span>Bench-marking\u00a0Methodology for Network Interconnect Devices\u201d. The purpose of this test is quite often misunderstood even though it is clearly stated in the introduction of the standard itself. So let\u2019s start with clarifying what this testing suite is and what it should be used for.<\/span><\/span><\/p>\n

\n

Introduction and considerations<\/span><\/h3>\n

As the standard say right at the beginning this test suite is in place so customers have a single point of reference while testing network equipment capabilities. So as you can see the intent of this test is to evaluate a single piece of equipment and provide results that can be easily compared between vendors. This approach has some very obvious advantages and some not so obvious drawbacks both of which I will try to cover in this article.<\/span><\/p>\n

The advantages of the test suite can be covered rather quickly as they are for most part rather obvious. The test suite had been designed in order to provide vendor-independent comparable test with clear and easy-to-understand results. The tests themselves are measuring behaviors\/variables that are absolutely a \u201cmust know\u201d for any new network element being introduced into the network. What the test cover and how will be detailed below in detail and I have to say most of the methods are still very valid even though the standard has been approved in 1999. The main advantage (or maybe you can say disadvantage) is the test popularity as it became over the years a most used standard for Ethernet\/IP network testing.<\/span><\/p>\n

The disadvantages of RFC2544 are bit more obfuscated but are rather serious. The first \u00a0of the problems I am encountering a lot is the fact this test suite is so popular often results in two interconnected problems \u2013 it is being used in wrong place (where other test would be more suitable) and its results are being misunderstood or misinterpreted. I hope this article will help to shed some light on the test procedures and variables entering the test and subsequently on the expected results.<\/span><\/p>\n

The other important thing to consider while making a decision if to use or not use this test is that this test suite was created to test standalone network elements and even though it can be used for service activation\/ acceptance testing it is not its primary focus and the testing procedures must be adjust. \u00a0It should be considered that in some cases it will not be suitable at all (that is why there are specialized test procedures for those.<\/span><\/p>\n

The last consideration or problem of the RFC2544 suite is that it has been created and approved devices that were around in 1999 (routers, L2 switches and hubs etc.) so it is designed in a way that is quite different from today\u2019s multi service environment. Also the intent was to test purely \u00a0native Ethernet devices (and now legacy Ethernet transport over FFDI and token-ring) so using it in Telco environment where quite large quantities of equipment still use ATM (at least internally) can lead to very interesting results. I will discuss this in later part of this article.<\/span><\/p>\n

Physical setup<\/span><\/h3>\n

The first thing to consider when using the RFC2544 test suite is what physical setup you will use and what repercussions will that have on subsequent evaluation and fault-finding. The three main options are:<\/span><\/p>\n