Rules of Networking

I have to admit that I’m obsessed with RFC1925 and do my best to apply it to all aspects of my work.

Just as a note to self, I post the Twelve Networking Truths here, and hopefully add more relevant ideas I find in the course of time.

  1. It Has To Work.
  2. No matter how hard you push and no matter what the priority, you can’t increase the speed of light.
    1. (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won’t make it happen any quicker.
  3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
  4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
  5. It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
  6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
    1. (corollary). It is always possible to add another level of indirection.
  7. It is always something
    1. (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).
  8. It is more complicated than you think.
  9. For all resources, whatever it is, you need more.
    1. (corollary) Every networking problem always takes longer to solve than it seems like it should.
  10. One size never fits all.
  11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
    1. (corollary). See rule 6a.
  12. In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Share this!

ToR & EoR Data Center Designs

This post is my snippet of Brad Hedlund article about ToR and EoR design which is accessible via the following link:
http://bradhedlund.com/2009/04/05/top-of-rack-vs-end-of-row-data-center-designs/

Top of Rack Design

ToR is sometimes called In-Rack design.

Benefits:
  • All copper cabling for servers stays within the rack as relatively
  • there is no need to for a large copper cabling infrastructure
  • Any network upgrades or issues with the rack switches will generally only affect the servers within that rack
  • any future support of 40 or 100 Gigabit on twisted pair will likely have very short distance limitations (in-rack distances). This too is another key factor why Top of Rack would be selected over End of Row.

Continue reading “ToR & EoR Data Center Designs”

Share this!

OSPFv2 in NX-OS

When you configure a summary address, Cisco NX-OS automatically configures a discard route for the summary address to prevent routing black holes and route loops.

OSPFv2 has the following configuration guidelines and limitations:

  • You can have up to four instances of OSPFv2 in a VDC.
  • Cisco NX-OS displays areas in dotted decimal notation regardless of whether you enter the area in decimal or dotted decimal notation.
  • All OSPFv2 routers must operate in the same RFC compatibility mode. OSPFv2 for Cisco NX-OS complies with RFC 2328. Use the rfc1583compatibility command in router configuration mode if your network includes routers that support only RFC 1583.
  • You must configure RFC 1583 compatibility on any VRF that connects to routers running only RFC1583 compatible OSPF.
Reference bandwidth for link cost calculation 40 Gb/s
Product License Requirement
Cisco NX-OS OSPFv2 requires an Enterprise Services license. For a complete explanation of the Cisco NX-OS licensing scheme and how to obtain and apply licenses, see the Cisco NX-OS Licensing Guide. 
nexus7009(config)# feature ospf
Nexus7009(config-if)# ip router ospf 201 area 0.0.0.15

From http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_ospf.html

Share this!

IPX Vol.1 Switching Notes

Downstream switches inherit timers from the root (of each VLAN)

  • BPDUgurad blocks incoming BPDUs.
  • BPDUfilter blocks outgoing BPDUs.
  • bpdufilter default and bpduguard default work in conjunction with portfast default.
  • spanning-tree guard loop  is similar to UDLD, but users STP BPDU keepalive.
show spanning-tree mst [detail]
In MST, load-balancing with cost/port-priority is the same as CST, PVST.
interface f0/0
spanning-tree mst 1 cost 1
spanning-tree mst 2 port-p 0

All switches in the L2 transit path should know about the RSPAN remote-vlan, and the interconnections should be trunk. Remember to remove pruning for RSPAN VLAN from trunks.

IPphone tags voice traffic with CoS 5.

switchport voice vlan dot1p instructs the IP-phone to apply VLAN0 and CoS 5, so both Voice & Data share the same VLAN.

switchport voice vlan  automatically applies portfast.

mls qos trust device cisco–ipphone means only trust CoS if received from IP-phone which is detected by CDP.

Fallback Bridging is the concept of bridging non-routed protocols between SVIs or native L3 router interfaces on switches. Similar to CBR and IRB on routers.

bridge 1 protocol vlan-bridge
interface f0/1
 bridge 1
  • PVLAN requires Transparent VTP mode.
  • Whenever a task asks us to optimize a switch for memory or routing, it means “sdm prefer routing“
  • Macros do not accept “interface range”!
  • When filtering traffic using mac-access-list remember to allow Spanning-tree and ARP stuff!

HSRP

  • standby use-bia  : not using the vMAC
  • standby version 2  : Uses 224.0.0.102 for inter-router communications instead of 224.0.0.2
standby 1 ip 150.100.220.1
standby 1 priority  : default is 100
standby 1  : not default
standby 1 track 1 decrement  // same as  standby 1 track Serial0/1/0 20

Remember to add static arp for hosts when filtering ARP in LAB exam. (show arp)

Share this!

Nested Policy-map

Policy-maps do indeed have the ability to be nested inside other policy maps. When we engage in this nesting behavior, we refer to the policy as a hierarchical policy. This is typically done to configure multiple treatments to QoS. For example – we might want to traffic-shape all traffic to 3 MB; and then inside that 3 MB shaped traffic, guarantee Web traffic at least 1 MB of bandwidth.

Remember, we use a service-policy (normally done with interfaces) to  assign the QoS policies that we define inside the policy-map.

With the nesting of policy maps, there are some restrictions that you should be aware of. For example:

  • The set command is not supported on the child policy
  • The priority command can be used in either the parent or the child policy, but not both
  • The fair-queue command cannot be used in the parent

Here is an example of nesting policy maps:

Verifying your policy-map, is very simple thanks to the following show commands:

show policy-map
show policy-map interface int_name
Share this!