Tag Archives: cisco systems

Cisco Nexus Management and Default VRFs

cisco vrf

Here is another post regarding a topic from my new and upcoming CCNA Data Center course (200-155) at CBT Nuggets. This one talks about two specific Virtual Routing and Forwarding components called out in the exam objectives. Remember, a VRF is a logical separation at Layer 3 for routing information. You can liken it to a VLAN at Layer 2!

Cisco NX-OS devices have a default VRF and a management VRF. All Layer 3 interfaces exist in the default VRF until you assign them to another VRF. By default, all EXEC commands are processed in the default VRF unless you specify otherwise when you run a command.

Here is what you should know about the default VRF:

  • Routing protocols are run in the default VRF context unless another VRF context is specified
  • The default VRF uses the default routing context for all show commands.
  • The default VRF is similar to the global routing table concept.

Here is what you should know about the management VRF:

  • It is for management purposes only – duh!
  • Only the mgmt0 interface can be in the management VRF; the mgmt0 interface cannot be assigned to another VRF.
  • No routing protocols can run in the management VRF (static routing only).

You should also know the following VRF guidelines and limitations:

  • When you make an interface a member of an existing VRF, NX-OS removes all Layer 3 configurations. Therefore, you should configure all Layer 3 parameters after adding an interface to a VRF.
  • If you configure an interface for a VRF before the VRF exists, the interface is operationally down until you create the VRF.
  • NX-OS creates the default and management VRFs by default. You should configure the mgmt0 IP address and other parameters after you add the mgmt0 interface to the management VRF.
  • The write erase boot command does not remove the management VRF configurations. You must use the write erase command and then the write erase boot command.

CCNA Data Center DCICT (200-155) CBT Nuggets Outline

200-155

By popular demand – here is the rough outline of the exciting new CCNA Data Center course I am working on at CBT Nuggets!

  1. Introduction: The CCNA Data Center
  2. Introduction: Getting Your Hands on Equipment
  3. Network Virtualization: Module Introduction
  4. Network Virtualization: Functional Planes
  5. Network Virtualization: Default and Management VRFs
  6. Network Virtualization: OTV
  7. Network Virtualization: NVGRE
  8. Network Virtualization: VXLAN
  9. Network Virtualization: Troubleshooting VDC STP
  10. Networking Technologies: Module Introduction
  11. Networking Technologies: Configuring FEX
  12. Networking Technologies: Configuring vPC
  13. Networking Technologies: Configuring FabricPath
  14. Networking Technologies: Configuring Unified Switch Ports
  15. Networking Technologies: Benefits of the Unified Fabric
  16. Networking Technologies: RBAC
  17. Unified Computing: Module Introduction
  18. Unified Computing: Server Types
  19. Unified Computing: Connectivity
  20. Unified Computing: Cisco UCS
  21. Unified Computing: Hardware Abstraction
  22. Unified Computing: Configuring High Availability
  23. Unified Computing: Configuring Port Roles
  24. Unified Computing: Configuring Hardware Discovery
  25. Unified Computing: Hypervisors
  26. Unified Computing: Virtual Switches
  27. Unified Computing: Shared Storage
  28. Unified Computing: VM Components
  29. Unified Computing: Virtual Machine Manager
  30. Automation and Orchestration: Module Introduction
  31. Automation and Orchestration: Using APIs
  32. Automation and Orchestration: Cloud Computing
  33. Automation and Orchestration: UCS Director
  34. Automation and Orchestration: Troubleshooting a UCS Director Workflow
  35. Application Centric Infrastructure: Module Introduction
  36. Application Centric Infrastructure: The ACI Environment
  37. Application Centric Infrastructure: ACI Fabric Discovery
  38. Application Centric Infrastructure: The ACI Deployment Model
  39. Application Centric Infrastructure: The ACI Logical Model