Networking

One strength of Juniper Junos is the config file management. The concept of different configurations is nothing special. For example Cisco uses two configuration files to reflect the current configuration in the RAM (running configuration), and the configuration used on startup (startup configuration). HP is doing the same on their networking gear. If you are new to Juniper Junos, the concept of an active configuration and a candidate config, which holds the current changes but isn’t active, maybe confuses you.

The Cisco Discovery Protocol (CDP) is used to discover and advertise the identity and capabilities of a network component to other networking components. CDP a proprietary protocol developed by Cisco, so it’s often used on Cisco switches and routers. The Link Layer Discovery Protocol (LLDP) is a vendor-neutral discovery protocol, which is used e.g. by Hewlett-Packard. With CDP or LLDP you can easily get an overview over a network topology. You can quickly check, e.g. what switches are connected to an uplink. Both protocols use Ethernet Multicast to advertise and receive information. CDP usess the address 01:00:0C:CC:CC:CC, LLDP 01:80:C2:00:00:0E.

I’m a big fan of Juniper Networks! I work mainly with the SSG (ScreenOS) and SRX (Junos) series. The Juniper SRX is a network security solution, which can be positioned in the data center or at the branch. You will surely agree, that virtualization and cloud computing changed a lot from the network perspective. This demands security solutions that are not bound to hardware boundaries. Juniper Firefly Perimeter addresses this demands.

What is Juniper Firefly Perimeter?

Juniper Firefly Perimeter is a SRX Service Gateway and it’s delivered in form of a virtual appliance. You can compare it with HP VSR1000 Virtual Service Router or Cisco Cloud Service Router 1000V. Firefly Perimeter is available for VMware vSphere 5.x and Linux KVM. Microsoft Hyper-V is currently not supported. When you take a look into the datasheet you will notice, that Firefly Perimeter can all the cool things, that you expect from this kind of a virtual appliance: From simple routing, routing protocols (RIP, OSP, BGP, IS-IS…), MPLS, VPN, stateful/ stateless firewall, Network attack detection, a lot of management feature and many more.

One possible use case for the HP VSR1000 is to build IPsec tunnels for secure data transfer. In this post I will show you how to configure a IPsec tunnel between two HP VSR1000. If you need a short introduction, feel free to take a look at this article.

The experimental setup

We have two server VMs (in this case Windows Server 2008 R2 with SP1) and two HP VSR1000 Virtual Service Router. To simplify I added a vSwitch without uplinks to my ESXi at home. This vSwitch has three port groups. While each VSR1000 is connected to only one site and the WAN port group, the server VMs are only connected to one site. The WAN port group should simulate the WAN link, but in reality WAN can be anything. This is a screenshot of the ESXi vSwitch and port group configuration, as well as the logical setup.

In an earlier blog post I wrote a bit about virtual service routers. Now I want to show you how easily you can deploy a virtual service router in your lab. To do so I have downloaded the the HP VSR1000 Virtual Service Router and the Cisco Cloud Service Router 1000V. If you want to know how to download them, just read the mentioned blog post. Because both virtual service routers delivered as OVA, I can easily deploy them through the vSphere Client (sorry, no Web Client. It’s a standalone HP Micro Server without a vCenter). I will show an example on how to deploy the Cisco CSR1000V. That procedure is exactly the same for the HP VSR1000. The procedure is pretty straightforward. The screenshots are self-explanatory.

Today you can get nearly everything as a virtual appliance. So even a router. Usually virtual router appliances are used for the same purposes as physical router: Connecting different networks. A router is nothing more then a piece of hardware and software. Due to this fact a router can be easily deployed as a virtual appliance. So where do you find router typically? In you datacenter? Yes, but in a datacenter you will deal typically with layer-3 switches rather than a classical router. In you WAN? That’s much warmer. Think of all the CE router in the branch offices, or the router that is running at a SMB customer. Or the small linux VM with IPtables which secures a special VM on your hypervisor. Or public cloud deployments. But what’s the benefit of a virtual router?

Today I was onsite at a customer to bring a tiny VMware vSphere cluster to life (HP BladeSystem c7000 with 7 HP ProLiant BL460 Gen8). Normally no big deal, but it started with two unavailable Onboard Administrator (OA) network interfaces. I switched from static ip addresses to DHCP, but I had no luck. I noticed that both interfaces were available if I connect my notebook directly to the interfaces. I even noticed that the Insight Display was unresponsive after connecting one or both OA to the network. The customer told me, that they had yesterday network related problems with virtual AND physical machines. Short outages, lost pings, things like that. This morning, before I arrived on site, the problems were worse. The customer told me that they had this network problems for a while. They had a lot of work and the outages were annoying, but not a big problem. The network of the BladeSystem were already connected (HP 10GbE Pass-Thru modules), but this kind of interconnect couldn’t cause this kind of problems. I checked the Switches and found on EVERY SINGLE ACTIVE port an enormous amount of “Drops TX”. But I found no loops or something like that. The network was flat. One VLAN and a /16 network. Not nice, but functional. I asked the customer to start Wireshark. I wanted to take a look around, get a feeling for what was going on in the network. Wireshark started and… stopped responding. After a couple of seconds it came back and I saw traffic that was… spooky. Usually I expect things like broadcasts, ARP, traffic from my client or for my client. But I saw traffic from a domain controller to a Windows NLB cluster and Citrix traffic to a Windows NLB cluster. I checked if the workstation was connected to a monitoring port, but it wasn’t. And it was only traffic with destination to the Windows NLB cluster. Our network problems had something to do with the Windows NLB. The customer and I decided to stop both NLB nodes. After that: Silence… I saw the expected traffic in Wireshark and my OA were both responding. Everything was fine… until we started the NLB again.