It’s official, the CCIE DC has been announced. Here’s the meat of the announcement:
“Cisco announced today that a new expert-level certification for data center professionals will be available starting September 2012. This expert-level certification validates a candidate’s expert knowledge of implementing and troubleshooting complex data center networks. The program offers candidates the knowledge and skills required to design, implement, operate, monitor, and troubleshoot complex data center networks. Products tested in this certification include Cisco Catalyst 3750, MDS 9222i, Nexus 7709(sic), 5548, 2232, 1000v and Cisco Unified Computing System (UCS), and Cisco Application Control Engine Appliance.”
This is a very interesting certification. It’s definitely crossing the line between a Data Center engineer and a Network Engineer. I think I might give it a shot. I have almost zero knowledge of UCS and Storage, but I think I could learn it. Working with everything on the blueprint is almost my dream job.
Real short one today. This post is about Nexus port profiles. Port profiles are great for ensuring consistency across port configurations. They allow us to configure a template which is inherited by a group of ports. There are three types of port-profiles: Ethernet, Interface-VLAN (SVI) and Port-Channel. In my example, we’ll be configuring several ports as “VM Server” ports. Some may be asking why one would choose these over the simple “interface range” command. In my opinion, port profiles are more strict. The range command configures any range of ports where a port profile configures ALL ports which inherit it. Any new configuration added to the profile is pushed to the inheriting ports as well.
Here’s an example:
n5k-1(config)# port-profile type ethernet VM n5k-1(config-port-prof)# switchport access vlan 225 n5k-1(config-port-prof)# spanning-tree port type edge n5k-1(config-port-prof)# spanning-tree bpduguard enable n5k-1(config-port-prof)# state enabled
Pretty basic. We create an “ethernet” port profile named VM and assign some config to it. The command “state enabled” makes this profile usable, without this command we wouldn’t be able to inherit the profile on a port.
Hi guys, I’m back for my annual post.:/
I’ve been working with a good amount of Nexus gear lately. Today we’ll configure Configuration Synchronization offered on the Nexus 5K platform. This feature allows one to create a switch profile on a vPC member and push the profile’s configuration to the peer. This is crucial as vPC configurations need to match exactly on both peers. If configurations don’t match, the channel could be suspended. Here’s our topology:
We’re using an Enhanced vPC (EvPC) here (supported in 5.1(3)N1(1) and up) topology – the FEXes are dual-homed and connected to the 5Ks via vPC and we’re also running a vPC to the host. Config Sync is almost a necessity here. We’re using 169.254.0.0/30 for the IPs Peer Keepalive links (stole this practice from Chris Marget. It’s important to note that CFS (Cisco Fabric Services – this is the magic that makes config sync work) communicates over the Managment 0/peer-keepalive interface.
I had an interesting conversation the other day regarding OSPF. I don’t want to give too much away, so here we go. This is the topology:
Assume interfaces have correct bandwidth statements and no cost commands have been added. R1 and R2 are redistributing the 192.168.1.0/24 prefix as E2 with a cost of 100.
Which path does R4 take to the 192.168.1.0/24 network? Does it load balance? Explain.
I started a thread on Networking-Forum on this as well. Post your answer here in the comments or over there.
Update: Here’s another question. What happens if we change it to:
Everything is the same except R2 is now redistributing as E1. Which path and why?
Hello everyone. I know I’ve been neglecting this blog for too long. Can’t promise that things are going to change, but I have a good post for today.
I was recently exposed to some new technology while working with a customer. I had to learn it pretty quickly. This post is about a new feature in the Cisco ASA 8.4 code called Bridge Groups. This is essentially the addition of BVI interfaces, which have existed in IOS forever. This feature is useful when running an ASA transparently, but not physically inline. Running a firewall physically inline works well, but it can limit you to the number of available interfaces you have on each firewall. Adding physical interfaces to a firewall is expensive. This feature also saves you from using a context per firewalled VLAN on your ASA. Here we’ll use a 3750 for physical connectivity and use BVIs to force traffic through the firewall. Here is the physical topology: