Lucky there is a big disclaimer at the beginning of this video. Otherwise I would be tempted to test such things and then plug it in to see if it still start (at least) and run.
It’s a nice commercial from Cisco, but to be honest I feel bad for this poor device:
[adsense_id=”2″]
If you ever worked in an environment where you have to deal with leased / dedicated lines provider by your SP (service provider) then you know that whenever it’s a problem on the line they request, if possible, to put a loop on the line from one end toward the other end, so they can do some measurements. Usually from my experience with SP, this is a standard approach in case that they don’t know exactly what problem is with your line or where the issue occurred, especially if they use sub-providers of their own.
Lately I saw some questions on Cisco support forums regarding the usage of software loops on Ethernet interfaces so I’ve decided to write a small how-to about the basic configuration of a soft loop on different interfaces.
configure terminal
! Apply the loop on the controller interface to loop the entire (e.g.) T3 interface (all 28 x T1 channels)
controller t3 3/0
loopback [local | network | remote]
Mandatory parameter:
– loopback – place the loop
Optional:
local – Loops the data back toward the router and sends an AIS signal out toward the network
network – Loops the data toward the network at the T1 framer
remote – Sends a far-end alarm control (FEAC) request to the remote end requesting that it enter into a network line loopback. FEAC requests (and therefore remote loopbacks) are only possible when the T3 is configured for C-bit framing.
If your controller is channelized for T1, E1, you can avoid to loop the entire controller, but choose to apply the soft loop on only one channel:
configure terminal
! Apply the soft loop under interface configuration rather than controller
interface Serial3/0:1
loopback [local | network {line | payload} | remote {line {fdl {ansi | bellcore} | inband} | payload [fdl] [ansi]}]
Mandatory:
loopback – applies the soft loop
Optional:
local – Loops the router output data back toward the router at the T1 framer and sends an AIS signal out toward the network.
network – Loops the data back toward the network before the T1 framer and automatically sets a local loopback at the HDLC controllers (line) or loops the payload data back toward the network at the T1 framer and automatically sets a local loopback at the HDLC controllers (payload
remote line fdl – Sends a repeating, 16-bit ESF data link code word; ansi—Places the CSU into loopback, per the ANSI T1.403 Specification; bellcore—Places the SmartJack into loopback, per the TR-TSY-000312 Specification
remote line inband – Sends a repeating, 5-bit inband pattern (00001) to the remote end requesting that it enter into a network line loopback.
payload – Sends a repeating, 16-bit ESF data link code word to the remote end requesting that it enter into a network payload loopback. Enables the remote payload Facility Data Link (FDL) ANSI bit loopback on the T1 channel. Rarely it’s necessary to specify fdl or ansi keywords
To be honest I never used here more than local or network parameters. The other ones I add them here with explanation, but never use them.
configure terminal
! Apply the soft loop on the serial interface
interface Serial3/0
! If the interface is a port on a PA-E3
loopback [dte | local | network {line | payload}]
! If the interface is a port on a PA-T3
loopback [dte | local | network {line | payload} | remote]
Mandatory:
loopback – apply the soft loop
Optional:
dte – Sets the loopback after the LIU toward the terminal.
local – Sets the loopback after going through the framer toward the terminal.
network – Sets the loopback toward the network before going through the framer (line) or after going through the framer (payload).
remote (only T3) – Sends a far-end alarm control (FEAC) to set the remote framer in loopback.
configure terminal
! Apply the soft loop on a Ethernet interface
interface GigabitEthernet
loopback [driver | mac]
Mandatory:
loopback – apply the loop
Optional (only on Gigabit Interfaces):
– driver – apply the loop at the transceiver level
– mac – apply the loop at the MAC controller level
You can use the loopback driver and loopback mac interface configuration commands with the 2-Port 10/100/1000 Gigabit Ethernet SPA. These commands do not apply to the 4-Port 10/100 Fast Ethernet SPA.To properly enable internal loopback, you must disable autonegotiation (under interface configuration, you have to apply no negotiation auto)
Due to different card/router models, IOS versions and specific SP configuration not all the commands will fit exactly how described above, but at least this is a starting point to check when you need to enable a soft loop. If you are a beginner you may wonder why I’m calling it soft loop. This is because is a software loop, opposite to a hardware loop which implies that wires are physically looped.
[adsense_id=”2″]
Stephan, a colleague of mine, found the following documents digging through multiple pages of Cisco.com. The documents present a nice view of different QoS approaches and the most important information. Somehow like “cheatsheets”. They were helpful to us when need to implement QoS in some parts of the network that we administer. I hope they will help you as well.
Maybe you’re wondering why I’m adding them here, since the documents are already somewhere in Cisco.com. As you probably know, Cisco has constantly changing their website in the last months and a lot of documentation is misplaced in the Cisco.com sitemap. We already had problems finding all links, so I said why not share it here as they are already public made by Cisco.
You’ll find a Download button under each document, for PDF version and at the end of this post there is a Link to download all documents in an archive. If somebody needs only one document and has a poor Internet connection why to force them to download the full archive.
Cisco – QoS Design for IPsec VPNs
Cisco – QoS Design for MPLS VPN Service Providers
Cisco – Scavenger class – QoS Strategy for DoS Worm Attack
Cisco – QoS Design for MPLS VPN Subscribers
As said in the beginning, if you’d prefer, you download all QoS graphs in one archive.
Let me know your opinions on the above approach on QoS from Cisco. Is is accurate? Do you apply them in your organization weather for Campus, WAN, VPN or even Security?
This video looks like a good joke, but to be honest it explain in the most simple way how TCP Slow Start and Wan Optimization work. If you have problems explaining networks concepts, than for sure when somebody ask you about TCP Slow Start and Wan Optimization, you’ll remember the two guys running with oranges.
Combine the video below with some technical explanation and you can put together a nice presentation:
As I promised in Part I of this article, here is the second part covering the port-channel load-balancing method explanation. If you didn’t know what I’m talking about, please be sure that you have read the first part of this article. Everything remains the same in this scenario. We have 3 physical interfaces bundled in one port-channel. Together with this port-channel we have some possible sources and destinations.
In this Part II, I will try to explain the remaining 6 methods of port-channel load-balance:
src-ip
src-mac
src-port
dst-mixed-ip-port
src-mixed-ip-port
src-dst-mixed-ip-port
I’ve grouped this 3 methods under one example as the basic principle is the same; Loads distribution on the source IP address / mac-address / port. Ignore completely the destination IP address / mac-address / port.
In the above case all traffic from Source A (depending on the method, this can be IP address A / mac-address A / port A) is forward through physical interface Fa0/1 in Port-Channel 1, not matter of its destination. Fa0/2 and Fa0/3 are not an alternative in this load-balance methods.
Loads distribution on the destination IP address and TCP or UDP port
This method offer more granularity and we see that we start to have a more complex scenario as this process take into consideration a mix of IP address and TCP/ UDP port. We may have the following scenarios for traffic load-balance:
– from Src A packets to Dst A and port 80 – Fa0/1 in PO1 – valid alternative
– from Src A packets to the same Dst A, but port 25 – Fa0/2 in PO1 – also valid, because the IP address is the same, but TCP port is different
– from Src A packes to Dst B, same port 25 – Fa0/2 in Po1 – valid as is the same port (25), but different IP address
– from Src A packets to Dst B port 25 – Fa0/3 in Po1 – not valid, as there is already a path through Fa0/2 for the packets matching this destination and port
Loads distribution on the source IP address and the TCP or UDP port
This method offer also a great granularity in load-balance process. If we analyze the port communication trend, I would say that this method offer more granularity than the dst-mixed-ip-port one, because source ports are more random chosen in communication than destination port. Here we have the following scenarios:
– Src A and source port 32343 to Dst A – Fa0/1 in PO1 – valid choice
– Src A and source port 32345 to Dst A – Fa0/2 in PO1 – valid choice (same source IP, different source port)
– Src A and source port 32346 to Dst B – Fa0/2 in PO1 – valid choice (same source IP, different source port than previous example); you might think that also different destination, but in this method, destination IP or port are not taken into consideration.
– Src A and source port 32346 to Dst C – Fa0/3 in PO1 – not valid choice as the path for this source IP / source port is already defined through Fa0/2
Loads distribution on the source XOR-destination IP address and the TCP or UDP port
The best granularity until now. Almost every path in PO1 is a valid choice. You can just image that a path which is consider not valid is if you have a pair of SRC IP : PORT -> DST IP: PORT and is already forwarded through one port (Fa0/2), then the Fa0/3 is not a valid choice for the same traffic. Otherwise, there are more possibilities to load balance traffic than in the previous methods. The issue is that not all devices support these last methods (especially the last 3), so if you’re device is capable to support this complex method you have to deal with the other ones and choose the best one for your scenario.
I want to close this article by adding a new load-balance method:
This method set the load-distribution method among the ports in the bundle for Multiprotocol Label Switching (MPLS) packets, use the port-channel load-balance mpls command in global configuration mode. I never had the chance to work with this method, so I don’t know how it’s working exactly (just in theory). If anybody has experience with it, I would be glad to add it’s explanation here (with credits of course).Otherwise you’ll have to wait until I get my hands on this configuration and then I’ll share my knowledge with you.
