ICANN and the future of DNS and internet

I’m sorry to put here something that is not really technical but for a blog with the name “howdoesinternetwork.com” it would be strange not to follow the story about the future of DNS governance given the fact that DNS is a crucial part of internet functionality.

You probably know how the internet works given the fact that you are visiting a blog like this. Regardless of that, it will not hurt to explain in few words the importance of DNS (Domain Name System) for a normal internet operation.

Let’s surf to se how this works

If you want to open this webpage or send an email to someone, you must enter a destination to your computer so it could know where to sent your stuff. As you are most surely a human, being, you would like to use a name like google.com for opening a webpage or an e-mail address in order to send a message to your colleagues (rather than some strange numbers separated by dots or colons). Almost all humans are like that and they want to use names and addresses. Computers, on the other hand, know to reach each other only by IP addresses.

You can see that we needed someone to take the role of the “address book” as soon as we got the internet.

| Continue Reading.. |

ISSU Upgrade of Cisco Catalyst 6880-X VSS Cluster and 6800ia FEX extenders

For a shorter update procedure guide check abbreviated article: Short list of upgrade steps without extensive explanations “Cisco Catalyst 6880-X VSS ISSU Upgrade Steps


Cisco spoiled us over the years with great and detailed documentation on each technology and hardware component they support. Still, I managed to find a part where documentation is not detailed enough to give you definite number of steps to get things done.

While preparing for software upgrade of Cisco Catalyst 6880-X VSS cluster I stumbled on one of the first examples of outdated and vague procedure for upgrade of Cisco device. Here is my successful ISSU (In-Service Software Upgrade) procedure which I done few days ago. I hope it will help you avoid sweating and hoping that you typed the right thing on a VSS cluster that should not go down at any point 🙂

I included an Acronym Guide at the bottom of the post to guide you trough VSS, ISSU, Cluster, and other mentioned abbreviation which are not described in details here

In my case the environment was Catalyst 6880-X and four 6800ia Fabric Extenders FEX. The same procedure is valid for more on for no FEX extenders.

Cisco Catalyst 6880-X VSS

Cisco Catalyst 6880-X VSS

Get the info on which IOS version is supported to be upgraded with ISSU

Not all IOS images can be upgraded to new IOS versions using In Service procedure to avoid network traffic downtime. In order to get things working, you need to get into Cisco docs and find ISSU supported upgrade matrix document.

| Continue Reading.. |

Cisco Catalyst 6880-X VSS ISSU Upgrade Steps

This is a short version without comments and explanations for those that need to get things done quickly without reading through my extensive waffle.

For detailed update procedure with all the explanations check extended article: ISSU Upgrade of Cisco Catalyst 6880-X VSS cluster and its four 6800ia FEX extenders

Let’s start!

1. Get the info on which IOS version is supported to be upgraded with ISSU

Google for ISSU or EFSU IOS upgrade support or use this Cisco doc “SX_SY_EFSU_Compatibility_Matrix1” to select supported IOS for ISSU upgrade from your current version.

2. Upload IOS to both Chassis

copy ftp://admin:[email protected]/c6880x-adventerprisek9-mz.SPA.151-2.SY7.bin bootdisk:

and same for slavebootdisk:

| Continue Reading.. |

Juniper vMX Lab Setup on VMware

This is a description on how to deploy a Juniper LAB of 8 vMX routers and making a simple topology in VMware vSphere environment. vMX is Juniper’s virtual production router so this could be the same procedure for deploying vMX device in production except different number of routers and their interconnection with vSwitch setup.

Juniper vMX router

Two VMs interconnected with VLAN801 – making one Juniper vMX router

As you might have seen from my previous post, I’m trying to get into Juniper configuration lately. One of the things that I needed is to set up a simple lab running Juniper vMX machines with multicast forwarding enabled.

It was a simple lab experiment with few commands on each device. As it turns out, being a Cisco fellow, each of those commands presented a complicated googling routine until the thing finally started to work.

Most time I spent configuring Virtual Machines and boot them properly, after that Juniper Configuration Guides were enough to make fist lab scenarios.

Goggling went somewhat like this:

  • How to set up Juniper vMX on Vmware ESXi 6.0 and interconnect 8 instances of vMX?
  • How to configure Vmware network and vSwitches to make this work?
  • How to configure VCE and VPE vMX Control and Forwarding plane VM communication?
  • How to configure interfaces and map them to VMware vSwitch interfaces?
  • How to configure Juniper eth interfaces, OSPF, Multicast with PIM Sparse mode?
  • Why this does not work from the first try? Do I need vMX Evaluation licence to do that?
  • What for …. does ‘tunnel-services statement on one or more online FPC and PIC’ mean?

…so when it actually finally worked, I decided to share it so you can have one post that would describe it from start all the way to VLC Multicast streaming.

| Continue Reading.. |

Juniper vMX Multicast Configuration

I’m fairly new to Juniper CLI. For one of my first tries, I decided to make my life difficult by starting with multicast configuration on virtual vMX routers running as VMs on VMware ESXi.

It took a lot of investigation about some part of this configuration specially the tunnel interface which you will see below. I decided to put it here all in one place with the explanation of every step because Juniper documentation tends to assume that you know more than me. If that is not the case, this short description is for you.

Here’s how the topology looks like. I have 8 routers making this topology with the plan to source multicast streams from right to left, from PC towards PC

Juniper vMX topology


| Continue Reading.. |

WoL – Wake On LAN

If a computer on local LAN network is turned off and administrator needs to do some regular maintenance on it, he will need to use Wake-On-LAN (WoL) to power the system up remotely.

Of course, network devices need to be configured to enable that kind of “magic” packet forwarding.

NIC cards on machines need to support WoL for this to work, but we don’t bother with this here..

WoL is sending “magic packets” to computer NIC card in order to start the system up. NIC which supports WoL is still receiving power when PC is turned off. NIC then keeps listening on the network for the magic packet and if received it will initialise the system boot process and power up the PC.

Magic packet is specially crafted network directed broadcast packet typically sent with connectionless UDP, port 7.

You would usually have a WoL server somewhere on you network which will be used to source magic packets. If you send magic packets across network segments (between VLANs or from some remote subnet), last router in the path, one having client subnet locally connected, needs to be configured with directed broadcast. The first router on the path, router with server subnet locally connected, should have ip helper configured pointing to directed broadcast IP address (in our case

In our example below, both ip helper and directed broadcast are configured on the same L3 device since this is the only router connecting two subnets.

Directed broadcast on Cisco devices is off by default since IOS 12.0 and needs to be configured on specific subnets where WoL will be needed.

You need directed broadcast because PC which needs to be woken up is asleep and while asleep it will not have an IP nor it will respond to ARP. Only way to get some packets to that PC without an ARP resolution is by using local subnet L2 broadcast.

Furthermore, we can surely assume that your PCs are connected to L2 Access Switch. That switch will not know to which port is the PC connected while that PC is asleep. Only a Layer 2 broadcast (and unknown unicast) will be sent out all ports on a switch.

| Continue Reading.. |

Network Virtualization

(Part I) Network Virtualization

This is the first part in the series of posts dedicated to network virtualization and path isolation.

Virtualization is a technique of simulating a hardware device by using software, usually on standard x86 CPU based servers. Hardware devices that are being virtualized are (in the order from most common) servers, firewalls, switches and routers. Almost all devices that you can think of can be virtualized, we listed the most common ones used within network operations. By using virtualization, we are able to run multiple virtual instances (virtual contexts) of a device, in the same way like we would run “real” hardware devices. Each of these virtualized instances is, of course, running independently and usually operating with separate configuration, enabling separation by purpose. Virtual instances are usually running as multiple contexts on specialised, virtualization enabled device or as Virtual Machines (VMs) on a Hypervisor platform like VMWare of Hyper-V.

Network Virtualization is part of above explained virtualization. It is virtulization of networking devices. We are using network virtualization with VLANs on switches to enable multiple broadcast domains (LAN segments) to be connected on one single switch. We are doing the same thing on layer 3 with enabling the router to run multiple routing instances by implementing VRF configuration on it. With VRF we are splitting the router into multiple routers, with VLANs we are splitting switch into multiple switches. We are doing this with the use of software but only on specialized hardware devices that are virtualization enabled.

There are two network elements we can virtualize

Network virtualization can be as simple as running firewall on a VMWare host. In this case we are just skipping the usage of real hardware appliance for firewalling task.

Things can get more complex with requirements for path isolation. Different categories of traffic then need to use same physical devices and their interconnections and have complete data communication isolation between them. Here we are in a situation where we will need to virtualize not only the above mentioned firewall but also router forwarding plane and interconnections between network devices.


VRF enables the router to run more “virtual” instances of routing and forwarding table. VLANs separate switch port groups into separate broadcast domains/isolated segments. Firewall can have trunk link with subinterfaces of which each one is separate zone forwarding traffic for one router VRF. Image on top shows three different isolated paths which are forwarded through same devices/interconnections. Below, physical topology is shown.

Ok that’s it! We can not only virtualize network devices but the paths between them to. Let’s see what that means.

| Continue Reading.. |