Steps to convert two standalone switches to VSS switches

  (by default all switches are operating at standalone mode)  

1. optional - save configs
         >> assuming that these boxes are new, no configs need to be save
2. Configure each chassis as VSS
3. Configure VSSL peer
4. Convert!

    == Step 2 ==   assigning switch domain

note:  once vss is completed, # will not be in config. However, you must ensure that those numbers are NOT the same. 

The priority (number between 1 - 255) allows the switch to elect an "active" member.
Switch1(config)#
 switch virtual domain 40
  swtich 1

  switch 1 priority 150

Switch2(config)#
 switch virtual domain 40
  switch 2

  switch 2 priority 100

>> higher priority will take over active state when it loads. 

    == Step 3 ==

  Configuring VSL Port channel and ports    (VSL = Virtual Switch Links)

create Port Channels for VSLswitch1(config)#
 int po100
  description VSL 1
  switch virtual link 1
  no shut

 switch2(config)#
  int po200
  description VSL 2
  no shut

>> each switch needs a different port-channel group to avoid having the configs overwritten when the switches are converted and the configs are combined together.

add them to the physical InterfacesSwitch1(config)#
 int range Te1/1/1 - 2
  description VSL to switch 1
  channel-group 100 mode on

Switch2(config)#
 int range Te1/1/1 - 2
  description VSL to switch 2
  channel-group 200 mode on

    == Step 5 ==
     Converting it to VSS!  (use same commands on both switches)

checking platform (optional)

switch1&2#
 show platform hardware pfc mode

>>if it is not set to pfc3c then:

Switch1&2(config)#
 platform hardware vsl pfc mode pfc3c

converting to VSS

if you watch the conversion taking place, you can see the active & standby election process and will be able to watch the ports change from 1/1 to 1/1/1.

Switch1&2#
 switch convert mode virtual
 yes

this convert command automatically saves config so you dont have to worry about saving them. (as long as whatever you had before the conversion was saved)

also, Switch 1 and Switch 2 do no have to be converted at the same time. It is interesting to watch the processes a switche goes through to become a VSS switch instead of standby. They will both be VSS after both of them have been converted.

These two are the requirements for having a VSS

Switch1&2(config)#
 redundancy
  mode sso

=> this is done by default onces switch domains are configured.

Switch1&2(config)#
 router ospf 10
  nsf

=> can be done after conversion

VRF

VRF stands for virtual routing and forwarding.

Most commonly used in MPLS networks, VRF is where a single router can have multiple routing planes. This means that one router can have multiple routing tables with completely different routing decisions made in the same box.

Imagine a MPLS service provider. In one machine, you have to ensure that multiple clients are routed correctly within each clients own cloud through one physical network. To make this possible, VRF must be enabled so each client's MPLS cloud will have their own routing table. Without this, the clients will need a separate set of routers/switches to forward their traffic - which, as you can imagine, will be too expensive. Therefore, by virtualizing the routing planes, you can "simulate" multiple layer 3 devices.

Not only does this provide cost savings, it provides an increased level of security as routing decisions can be separated in the same physical box. This also means that the same IP address can be used in different VRFs on the same router. (This is not recommended due to confusion - but it is possible with good reason.)


References:
http://en.wikipedia.org/wiki/VRF

NX-OS vs IOS

What is NX-OS?
NX-OS is the new operating system for the Nexus data center switching equipment.
While it is similar to the Cisco IOS in that most of the commands are the same, there are some big fundamental differences. I personally find using NX-OS to be easier than IOS.

Some examples of BIG differences between the two:

1.) Show commands - NX-OS allows show commands to be issued at any mode when IOS the "do show" command has to be issued while in a mode higher than privileged exec mode.
2.) Features have to be turned on - To run/configure any routing protocols, tunnels, or even vlans, those features have to be turned on in NX-OS by issuing the "feature [ feature name ]". Otherwise, the box will not recognize any commands relating to that feature.
    >> Ex. without issuing "feature interface-vlan" command, you cannot configure "interface vlan #"
3.) Using /prefix when configuring interface ips - instead of typing out:
      "ip address 192.168.1.1 255.255.255.0"  this can be simplified to:
      "ip address 192.168.1.1 /24"
  Simple and so time saving.
4.) No range key word to configure multiple interfaces 


There are many more differences between the two operating systems - most of which I find to be quite useful when configuring devices (especially once you get used to it)


More notes on differences between them:
http://docwiki.cisco.com/wiki/Cisco_NX-OS/IOS_Interface_Comparison
For the full NX-OS command reference list:
http://www.cisco.com/en/US/products/ps9372/prod_command_reference_list.html

Getting Your CCNA - Helpful Links

https://learningnetwork.cisco.com/community/certifications/ccna/ccna_exam?tab=practice
Take advantage of review questions and other activities that cisco has to help you prepare for the exam.
Also, the exam topic can be found on the same page - make sure to look it over so all material is covered/reviewed

== will be updated soon ==

Troubleshooting Leak-maps

For basics about leak-maps read >>http://networkqueen.blogspot.com/2011/01/leak-maps.html

If your Leak-map is not configured incorrectly, one of two things can happen:

1. If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised, but all component routes are suppressed.
   
2. If the leak-map keyword is configured, but the access list does not exist or the route map does not reference the access list, the summary address and all component routes are sent

These are both easy mistakes to spot. Always double check to make sure the summary and the leak-map are doing exactly what they are supposed to do.

Leak-maps

A leak-map is a method of using a route-map.
It can be helpful to use a leak-map to "leak" in or only allow certain routes to the stub. The benefit of route leaking (advertising a route) is that the leaked route is more specific than a summarized route and is therefore the preferred route.

Consider the example below:

Routers A,B, C and stub are participating in the same EIGRP AS.
Notice that past router A and B, the addresses can be summarized as a /23 (as noted above.)
So, we can summarize these routes by adding the following command on A and B on the interfaces facing router c:
 Router(config-if)#ip summary-address eigrp 100 192.168.0.0 255.255.254.0

So what does this mean for router C?
Without any special configuration (without any leak-maps configured), that would mean that router C would see two paths to the route 192.168.0.0 /23 with an equal cost.

What if you wanted to force the routers to prefer taking router A to get to the stub LAN (192.168.1.0/24)?
This is where the leak map comes in handy.
By putting the leak-map on router A, and "leaking" just that 192.168.1.0/24 as well as the summary route, we can ensure that router C will prefer that path.

To do this add the following in router A instead of the summary address command above. There are a few steps to getting this work:

1. An ACL is required to restrict the address you want to "leak"
2. A route map is required to match the ACL
3. the leak map parameter has to be added to the summary address command.

These are the commands needed:
RouterA(config)#access-list 1 permit 192.168.1.0 255.255.255.0
RouterA(config)#route-map LEAK-STUB-LAN permit
                               #match ip address 1
RouterA(config)#int fa0/0
RouterA(config-if)#ip summary-address eigrp 100 192.168.0.0 255.255.254.0 leak-map LEAK-STUB-LAN


So what else can you do with a leak-map?

Another alternative method of using a leak-map (which i believe is less commonly known) is using as part of
Router(config-router)# eigrp stub connected leak-map <LEAK-MAP>
As you probably know, "eigrp stub connected" command permits EIGRP to advertise the directly connected routes. However, by using the leak-map command, you can "leak" non directly connected network on the stub.

Troubleshooting Leak Maps>> http://networkqueen.blogspot.com/2011/01/troubleshooting-leak-maps.html
info source: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_esflr.html