Blog‎ > ‎

Initial Setup NX-OS and Management Features

posted Mar 6, 2014, 7:10 PM by Rick McGee   [ updated Mar 17, 2014, 8:02 PM ]
Initial Configuration dialog
    • Default User "admin"
  • You enter in at the exec mode #
  • There is a single universal software image per version
    • Features and processes are licensed and activated individualy
      • "show license usage"
      • "show feature" current running processes 
      • "license grace-period" give you 120 to enter a valid license
  • House Keeping 
    • Backup license file to a back up server
      • "show license file license_xxxxxxx_xx.lic"
      • "copy license bootflash://sup-1/licnese_xxxxxx_xx.lic.tar" 
        • This is archiving the file which then you can save to a TFTP/FTP sever
  • High Availability 
    • Supervisor redundancy 
      • Remember that the Nexus platform is a Distributed Forwarding model. The Supervisor takes the FIB and sends it to each line card (in ASIC Switch on Chip (like CEF in IOS))and makes forwarding decisions locally
      • If a supervisor fails you just have to reconverge the control plane only
    • Power redundancy 
      • Grid Power, each Grid will have separate UPS with batteries and maybe generators. Each power supply would connect to each Grid
      • "show environment power"

    • config t
    • "power redundancy-mode"
      • combined               "Configure power supply redundancy mode as combined"
      • insrc-redundant     "Configure power supply redundancy mode as grid/AC input"
      • ps-redundant          "Configure power supply redundancy mode as as PS redundant"
      • redundant              "Configure power supply redundancy mode as InSrc and PS redundant"
    • More lines cards obviously more power, you also have to take into consideration of LR "long range" optics pull more power

  • Line Card redundancy 
    • distribution of links where not all combined into a singe module (think Peer-keep alive link)
      • You would want to have at least modules in Pairs M or F modules 
  • Cisco Fabric Services (CFS) This is a service that should be on by default 
    • Used to sync config of certain fetters between chassis
      • For instance NTP,  AAA, RBAC, Call Home, Config Sync between supervisors (only have to configure one chassis)
    • Used to sync control plane of certain features between chassis
      • For instance ARP, ICMPv6 ND, and IGMP Snooping over vPC
    • Supports both Ethernet (CFSoE), IP (CFSoIP), and IPv6 (CFSoIPv6) as transport options
      • This will be depend on application being used
        • "show cfs application"
  • Scope of CFS can be set with cvs region (similar to VTP)
      • Chassis in different regions would not be able to synchronize 
  • Management Connectivity
    • Each switch has a mgmt 0 interface
      • Nexus 7K each supervisor has a mgmt interface
        • Dual SUP's dual
          • Out of band (not in the data plane)
        • Nexus 5K will just have one mgmt 0 interface
        • config t
          • interface mgmt. 0
            • ip address xxx.xxx.xxx.xxx/xx (don't have to use dotted decimal prefix)
          • if you do a "show ip int brief" (you will not see the mgmt 0 interface included
          • There is a vrf for the mgmt port
            • this is out of band from any other links
            • to see this interface you have to do the "show ip interface brief vrf management"
  • If you want to verify connectivity you can do a" ping xxx.xxx.xxx.xxxx vrf management" (key is looking in the vfr)
  • after you verify connectivity you can do a "show cfs peers"
    • Might have to turn on cfs in IP
      • "cfs distribute ipv4" and "cfs eth distribute"
  • Setup the NTP on a one switch that will distribute to the other swtiches via the vrf mgmt 0 interface
    • conf t "ntp distribute"
    • "ntp server xxx.xxx.xxx.xxx use-vrf management"
    • "ntp commit" (because it's running over CFS)
    • on the other switch you still have to run the command "ntp distribute"
    • then check the ntp status by "show ntp peers"
    • "show cfs status"
  • you can also route mgmt over a Layer 3 interface if needed


  • SPAN, ERSPAN, and Ethanalyzer
    • Switchport Analyzer (SPAN)
      • Used to redirect to local sniffer local link to local link
        • Wireshark, IPS sensor, another
    • Encapsulated Remote SPAN (ERSPAN)
      • If you have multiple hops between L2 LAN's
        • RSPAN VLAN floods traffic everywhere (Catalyst way)
          • Need L2 trunk links which may not be the case in most networks
    • Nexus Switches
      • Doesn't' matter if L2 or L3 attached
          • Encapsulates inside GRE tunnel to a Destination Sniffer in a centralized location
            • "monitor session 1 type erspan-source
              • "interface ex/x"
              • "destination ip xxx.xxx.xxx.xxx (loopback interface on destination switch
              • Have to apply the "no shut" to the erspan configuration
              • Can also apply multiple ID's to multiple ERSPAN's
      • Ethanalyzer
        • built-in Wireshark Capability for Network visibility and control
          • Wireshark on the Supervisor
          • no config terminal
            • ethanalyzer local interface inband capture-filter "tcp port 23"  detail will show all the details
            • Can  write to pcap file  to have it on the inband via the console
              • Ethanalyzer local interface inband capture-filter "tcp port 23" write bootflash:telnet.pcap
              • By default only caputuers 10 packets can change that
                • This is only process switched traffic monitoring packets to supervisors
                • Could create a ACL to Layer 3 links permit traffic you want to sniff and log


    
Comments