Archive

Category Archives for "Networking"

Thoughts on vXLAN and Cisco 1000v

I know vXLAN has been around for a year now, but because of the reviews it got from the community immediately upon announcement, I decided to let it mature as an idea before I got involved. Here are some of my thoughts after attending a vXLAN session by Cisco at VMworld 2012. vXLAN really just solves one problem. Most virtual infrastructures depend on L2 connectivity. vMotion is a good example of this.

Thoughts on vXLAN and Cisco 1000v

I know vXLAN has been around for a year now, but because of the reviews it got from the community immediately upon announcement, I decided to let it mature as an idea before I got involved. Here are some of my thoughts after attending a vXLAN session by Cisco at VMworld 2012. vXLAN really just solves one problem. Most virtual infrastructures depend on L2 connectivity. vMotion is a good example of this.

What’s New in vSphere 5.1 Networking

I attended the VMworld 2012 session that covered the new features in vSphere 5.1 with regards to networking. Many features were rolled out to both VDS and the standard switch, and other features just had improved functionality. First off, apparently it’s now VDS, not vDS. This announcement came hours after the announcement that VXLAN was being changed to vXLAN. Um…okay, I guess? Anyways - The speaker pointed out at the beginning that a big change was that many of these features were being rolled out to both the standard and distributed switches.

What’s New in vSphere 5.1 Networking

I attended the VMworld 2012 session that covered the new features in vSphere 5.1 with regards to networking. Many features were rolled out to both VDS and the standard switch, and other features just had improved functionality. First off, apparently it’s now VDS, not vDS. This announcement came hours after the announcement that VXLAN was being changed to vXLAN. Um…okay, I guess? Anyways - The speaker pointed out at the beginning that a big change was that many of these features were being rolled out to both the standard and distributed switches.

OSPF Area Range – Active vs Passive Advertisment

I was troubleshooting an OSPF area range summarization and came upon something I haven’t seen before called Passive Advertisement. There weren’t too many Cisco documents that explained it so I decided to post a really quick description explaining it in little detail and where you could see it . This could be useful for the CCIE troubleshooting section, when dealing with OSPF area summarization problems.

I will use R3 to demonstrate. This router is connected to area 0 and area 1 which makes it the only ABR connecting the two areas. R3 should be sending a summary route 4.4.0.0/16 for the two component routes 4.4.4.0/24 and 4.4.5.0/24. Looks pretty simple. To verify, I check the output of show ip ospf to make sure the area 0 range 4.4.0.0 255.255.0.0 command is configured:

R3#sh ip ospf
Routing Process "ospf 1" with ID 10.3.3.3
Start time: 00:00:23.404, Time elapsed: 00:01:06.080
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border and autonomous system boundary router
Redistributing External Routes from,
rip
Router is Continue reading

Important FCoE Considerations – Cisco Nexus and Netapp

I ran into an issue that presented itself two different ways, each at a different customer. I posted a while back about a customer that wanted to use only a single Nexus 5000, since that was all that was available. I wanted to bundle all four CNA ports on the Netapp storage array to the Netapp SAN. However, after I created this port channel and bound the virtual fibre channel (VFC) interface to it, the VFC interface would not come up.

Important FCoE Considerations – Cisco Nexus and Netapp

I ran into an issue that presented itself two different ways, each at a different customer. I posted a while back about a customer that wanted to use only a single Nexus 5000, since that was all that was available. I wanted to bundle all four CNA ports on the Netapp storage array to the Netapp SAN. However, after I created this port channel and bound the virtual fibre channel (VFC) interface to it, the VFC interface would not come up.

Important FCoE Considerations – Cisco Nexus and Netapp

I ran into an issue that presented itself two different ways, each at a different customer. I posted a while back about a customer that wanted to use only a single Nexus 5000, since that was all that was available. I wanted to bundle all four CNA ports on the Netapp storage array to the Netapp SAN. However, after I created this port channel and bound the virtual fibre channel (VFC) interface to it, the VFC interface would not come up.

Can’t remember the IPv6 6to4 conversion?

What is IPv6 6to4 tunnel address? 2022::/16 or 2002::/16? How do you convert the IPv4 address into IPv6 6to4 tunnel address? Well there is the long way, which you should understand and then there is the easy way in case you need to configure it really quickly. I found this nice method where you can use the IPv6 General Prefix feature to automatically calculate the conversion. Originally this feature was used to create a variable for IPv6 network, the “general-prefix”, to easily change all IPv6 addresses in case reassignment of IP subnets.

 

Configuration is pretty simple. First make sure to have the 6to4 Tunnel’s source interface configured, in my example that’s Loopback0 150.1.1.1.

Rack1R1#sh ip int brief loop0
Interface                  IP-Address      OK? Method Status                Protocol
Loopback0                  150.1.1.1       YES manual up                    up

Then configure the IPv6 general-prefix for 6to4 type using loop0.

Rack1R1(config)#ipv6 general-prefix MY-GEN-PRE 6to4 loopback0

Rack1R1#sh ipv6 general-prefix
IPv6 Prefix MY-GEN-PRE, acquired via 6to4
2002:9601:101::/48 Valid lifetime infinite, preferred lifetime infinite

The way you apply it on the tunnel is using regular ipv6 address command:

R1(config)#int tun1
R1(config-if)#ipv6 address ?
  WORD                General prefix name
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/  IPv6 prefix
  autoconfig          Obtain address  Continue reading

Scripted Flexpod Provisioning – First Impressions

I had the opportunity this week to ascertain the feasibility of automating the provisioning of a full Flexpod. For reference, this is considering a “vanilla” Flexpod build: Pair of Nexus 5ks Pair of Cisco UCS Fabric Interconnects (with a few chassis) Netapp running ONTAP 7-Mode (I tested on FAS6070) Note that this also makes a few assumptions about the build. FC via Nexus 5000, no MDS No existing vCenter integration or storage migration So - pretty much a green field Flexpod build, pretty close to the specs laid out in the design guide.

Scripted Flexpod Provisioning – First Impressions

I had the opportunity this week to ascertain the feasibility of automating the provisioning of a full Flexpod. For reference, this is considering a “vanilla” Flexpod build: Pair of Nexus 5ks Pair of Cisco UCS Fabric Interconnects (with a few chassis) Netapp running ONTAP 7-Mode (I tested on FAS6070) Note that this also makes a few assumptions about the build. FC via Nexus 5000, no MDS No existing vCenter integration or storage migration So - pretty much a green field Flexpod build, pretty close to the specs laid out in the design guide.

Scripted Flexpod Provisioning – First Impressions

I had the opportunity this week to ascertain the feasibility of automating the provisioning of a full Flexpod. For reference, this is considering a “vanilla” Flexpod build: Pair of Nexus 5ks Pair of Cisco UCS Fabric Interconnects (with a few chassis) Netapp running ONTAP 7-Mode (I tested on FAS6070) Note that this also makes a few assumptions about the build. FC via Nexus 5000, no MDS No existing vCenter integration or storage migration So - pretty much a green field Flexpod build, pretty close to the specs laid out in the design guide.

Netvisor and iTOR Unvieled

After a long wait, we finally unveiled stage 1 of the big solution – the Netvisor and our intelligent Top of the Rack (iTOR) switch. If you haven’t had a chance to see, you can read about it here. At this point, we have enough boxes on the way that we can open the beta to slightly larger audience. Some more details about the hardware – it has 48  10gigabit ethernet ports which can take a sfp+ optical module, sfp+ direct attach or a 1gigbit RJ45 module along with 4x40gigabit qsfp ports. The Network Hypervisor controlling one or more iTOR is a full fledged Operating System and  amongst other things capable of running your hardest applications. Comes with all tools like gcc/gdb/perl already there and you can load anything else that is not there. Why you may ask – if you always had an application that needed to be in the network, now it truly can be on the network. Imagining doing your physical or virtual load balancers, proxy servers, monitoring engines, IDS systems, SPAM filters, running on our network hypervisor where they are truly in the network without needing anything to plug in. Create you virtual networks along with Continue reading

A BGP leak made in Canada

A BGP leak made in Canada

Today many network operators saw their BGP session flap, RTT’s increase and CPU usage on routers spike.  While looking at our BGP data we determined the root cause to be a large BGP leak in Canada that quickly affected networks worldwide.

Dery Telecom
Based on our analysis it seems that Canadian ISP Dery Telecom Inc (AS46618) is the cause of what we observed today. AS46618 is dual homed to both VIDEOTRON and Bell. What seems to have happened is that AS46618 leaked routes learned from VIDEOTRON to Bell. This in itself is not unique and happens relatively often. However normally transit ISP’s like Bell have strict filters applied on these BGP sessions, limiting the number of prefixes they accept from their customers. In this case the filter failed to work or simply wasn’t (correctly) applied by both Bell and Dery Telecom.

Sequence of events
At 17:27 UTC  AS46618 ( Dery Telecom Inc) started to leak a ‘full table’, or at least a significant chunk of it to its provider Bell AS577. Bell selected 107,409 of these routes as best routes. Even though many of the ASpaths were much longer than other alternatives it Continue reading

The First Bufferbloat Battle Won

Some puzzle pieces of a picture puzzle.Bufferbloat was covered in a number of sessions at the Vancouver IETF last week.

The most important of these sessions is a great explanation of Kathie Nichols and Van Jacobson’s CoDel (“coddle”) algorithm given during Tuesday’s transport area meeting by Van.  It is not to be missed by serious network engineers. It also touches on why we like fq_codel so much, though I plan to write much more extensively on this topic very soon. CoDel by itself is great, but in combination with SFQ (like) algorithms that segregate flows, the results are stunning; CoDel is the first AQM algorithm which can work across arbitrary number of queues/flows.

The Saturday before the IETF the IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication took place. My position paper was my blog entry of several weeks back. In short,  there is no single bullet, though with CoDel we finally have the final missing bullet for its complete solution. The other, equally important but non-technical bullets will be market pressure fix broken software/firmware/hardware all over the Internet: so exposing the bloat problem is vital. You cannot successfully engineer around bufferbloat, but you can detect it, and let users know when they Continue reading

1 … 3,328 3,329 3,330 3,331 3,332 … 3,353