Silver bullet for home QoS

Rationale

I mentioned in one of the posts about how prioritizing small packets upstream is almost the proverbial silver bullet when it comes to QoS at home. I'm sure any ADSL user who uses interactive applications, such as SSH have noticed how laggy the SSH gets when you upload something from home, say your holiday pictures with scp to your web server. Also download is quite slow during upload. VoIP and online gaming will suffer too. Canonical solution is to use DSCP markings at sender end or DSCP mark based on IP address or port.

But I feel that is unnecessarily complex for typical home use scenario, since all of the important/interactive stuff are using small packets and the bandwidth hogging applications are all essentially doing MTU size packets. I've chosen <200B as small packet, which is arbitrary decision I did about decade ago when setting this up first time, I'm sure it could just as well be like 1300B. So without further rambling, I'll give IOS (ISR) and JunOS (SRX) examples how to roll this on your CPE.

IOS example

class-map match-any SMALL-PACKETS match packet length max 200 ! policy-map WAN-OUT class SMALL-PACKETS priority percent 75 class class-default fair-queue random-detect ! interface ATM0.100 point-to-point pvc 0/100 vbr-nrt 2000 2000 tx-ring-limit 3 service-policy output WAN-OUT ! !

JunOS example

[email protected]> show configuration interfaces vlan unit 0 family inet filter input FROM_LAN; [email protected]> show configuration firewall family inet filter FROM_LAN term small_packets { from { packet-length 0-200; } then { Continue reading

How Unix Made Me a Better Network Engineer

I've had two main areas of interest in my IT career. Professionally, I've been a network guy. Designing, building, and supporting IP networks is what pays my bills. On the other side, I'm a Unix geek. Building, tinkering, and hacking code on Unix systems and related open source software has always been fun and challenging for me. Recently I was reflecting on my career and realized that my Unix and open source experience has played a big role in my career as a network engineer. Here's some of the ways I believe network engineers can benefit from Unix experience.

Cisco UCS and SR-IOV

I read an excellent blog post by Scott Lowe (@scott_lowe) this week on Single Root I/O Virtualization (SR-IOV) titled “What is SR-IOV?". It's an older post but it did a great job of solidifying my understanding and filling in the knowledge gaps. One thing that stuck out was this bit: SR-IOV requires support in the BIOS as well as in the operating system instance or hypervisor that is running on the hardware.

CCIE Data Center

The long rumored, highly expected and very desired has finally been released and it’s a beast!

Since the release of the Nexus platform there has been talk about when these platforms were to be introduced in a CCIE track. With the introduction of UCS in 2009 this became an even higher request especially since UCS really took off in sales. When I started my CCIE Storage studies in 2010 I initially wrote an article for IPexpert about my predictions for the CCIE DC (http://blog.ipexpert.com/2010/01/13/storage-and-datacenter-ccie/). Most of them where very easy guesses, but those also became reality in the track, though with new hardware that is now available (2 years later).

You might have already read most information on other blogs, but I’m trying to consolidate that information. During the coming weeks/months more and more information will become available and during Cisco Live in June there will be a huge amount of information and questions during the 4-hour Techtorial (TECCCIE-9544).

The scope of the exam is pretty much based on the usual suspects, so in summary you should know the:

  • UCS B-series blade systems
  • UCS C-series rackmount systems connected to UCS Manager via FEX
  • Virtual Interface Cards Continue reading

Nexus Accounting Log

Perhaps another trivial post, but if you don’t know about it, you might find it extremely useful. Cisco NX-OS has an on-device log file of the exec level configuration commands entered successfully. Obviously similar informational can be obtained from the TACACS logs, but there is a certain benefit in having directly on CLI. The command […]

Static Routes to an Interface, Not A Next-Hop

Static routes can be handy in some situations where you want to do some quick and (sometimes) easy routing to get the job done, whether replacing the job that a routing protocol would perform, or redistributing the static route into that protocol. The best way to do this would be to identify the remote subnet being routed to, and specify a next-hop IP address to send traffic to so that it can be reached.

Static Routes to an Interface, Not A Next-Hop

Static routes can be handy in some situations where you want to do some quick and (sometimes) easy routing to get the job done, whether replacing the job that a routing protocol would perform, or redistributing the static route into that protocol. The best way to do this would be to identify the remote subnet being routed to, and specify a next-hop IP address to send traffic to so that it can be reached.

Fast Restoration on IP – MPLS Fast ReRoute

Service providers that have a lot of real-time traffic through their network, like mobile network operators (MNOs), are very keen on a fast restoration of service once a failure occurs in the network. In the past a lot of networks were based on SDH/SONET transport networks, which took care of sub-second (50ms) failovers. Nowadays Ethernet is THE standard for any transport within a service provider network. This introduces an issue, as Ethernet is not built for automatic failover when certain things fail.

Now there are many ways to solve this and I want to dig deeper in these technologies in several posts.  I will discuss various protocols that can solve the fast restoration requirement in different ways. Some are used in local situations (so failover to local neighbor, like a twin sibling) and others can be used in inter-site locations or can be an end-to-end protection for certain traffic.

The posts are broken down as follows:

  1. MPLS Fast ReRoute (this post)
  2. IP Loop Free Alternate
  3. BGP PIC Core/Edge
  4. Hierarchical Forwarding

Please be aware that these technologies are all related to fast restore the layer 3 forwarding path, therefore restoring the MPLS forwarding path. The MPLS forwarding path may be Continue reading

LLDP / 802.1AB-2009 blows

If you're designing L2 discovery protocol, I suppose one of your mandatory requirements is, that you can 'machine walk' the network, after you find one box. I.e. you are able to know your neighbor devices and their ports. LLDP makes no such guarantees

You have 4 mandatory TLVs, [0123], End of LLDPDU, Chassis ID, Port ID and TTL. Chassis ID has 7 subtypes which implementation is free to choose, EntPhysicalAlias (two distinct cases), IfAlias, MAC address, networkAddress, ifName or locally assigned. Port ID also has 7 subtypes which implementation is free to choose, ifAlias, entPhysicalAlias, MAC address, networkAddress, ifName, agent circuit ID, locally assigned.

Now you can send what ever trash via locally assigned and be fully compliant implementation. It seems that it would be wise to mandate sending management address (networkAddress) in ChassisID and SNMP ifindex in PortID (and any _additional_ ones you may want to send, i.e. more than 1, which is not allowed). This way you'd immediately know what OID to query and from which node. Obviously this makes assumption that we have IP address always and SNMP implementation always. If we absolutely must support some corner cases where this is not true, we should Continue reading

JNCIE-ENT lab set-up

As I’m preparing for the various exams (up to the Expert lab) of the Enterprise Routing & Switching track of Juniper I needed a lab to support this. In this blogpost I would like to explain my choice of hardware and software and how I’m going to use this set-up to prepare for the written exams and the lab exam.

Hardware and Software

Based on the blueprint, available on the Juniper website (http://www.juniper.net/us/en/training/certification/resources_jncieent.html), I needed to select hardware and software. The current software version used in the lab is JUNOS 10.4. On the various communities I heard that they want to upgrade this to a JUNOS 11.x (probably 11.4, which is a long-term-support version) software track somewhere this year, but until that time I chose the latest version of 10.4. At time of this writing this is JUNOS 10.4R9.

On the official blueprint there is no real indication of which hardware is used on the lab exam, but when you find your ways through the community sites and with the help from some community friends (special thanks to Chris ;-) I decided to use the SRX100H as router and EX4200 Continue reading

OAM LFM: Part 2 – Junos implementation

This post covers: - OAM implementation on Junos - Default value of OAM LFM parameter (in relation with the Part 1) - Configuration / understanding: Neighbor discovery phase - Configuration / understanding: Remote loopback operation - Configuration / understanding:...

OAM LFM: Part 2 – Junos implementation

This post covers: - OAM implementation on Junos - Default value of OAM LFM parameter (in relation with the Part 1) - Configuration / understanding: Neighbor discovery phase - Configuration / understanding: Remote loopback operation - Configuration / understanding:...

Nexus load intervals

This is a interesting but a trivial post. Everybody know about the interface command “load-interval” that changes the time period over which the interface packet-rate and throughput statistics are averaged. I discovered an addition to this command on the Nexus the other day while poking around. NX-OS allows multiple counter intervals to be configured on […]

OAM LFM: Part 1 – The theory

1/ Some terms, before: OAM for Operations Administration and Maintenance LFM for Link Fault Management EFM for Ethernet in the First Mile 2/ Introduction: OAM is intended for point-to-point or emulated p2p Ethernet links. The OAM block is optional, so...

OAM LFM: Part 1 – The theory

1/ Some terms, before: OAM for Operations Administration and Maintenance LFM for Link Fault Management EFM for Ethernet in the First Mile 2/ Introduction: OAM is intended for point-to-point or emulated p2p Ethernet links. The OAM block is optional, so...