EIGRP Overview

Back when I took my CCNA and subsequently my CCNP, I really liked working with EIGRP. I found it easier to configure and understand than OSPF, but still with a lot more stability and features than RIPv2. I haven't ever come across an installation where it was used in the real world, though, so my experience with EIGRP is only from the lab and a short period where I used it for my own routing protocol at home (with a DMVPN connection to a few other routers over the big web).

Cisco opened up the protocol to the public back in 2013 - but I haven't heard of any vendor supporting it yet. It was also not released in full - Cisco keeps all the fancy features locked up tight. I hope the protocol will gain some traction, but I do not think it is going to happen any time soon.

Quick sidenote: EIGRP got a "facelift" in IOS release 15.0(1)M and introduced a new cli structure for configuring EIGRP parameters. This new method was called "Named Mode" and the previous method of configuring EIGRP was retroactively renamed Classic Mode. The new Named Mode collects all the configuration elements of EIGRP under the process configuration - no more EIGRP interface sub-commands and stuff like that. I will have a separate post about the new Named Mode soon.

This is to be a (somewhat) quick overview of Cisco's routing protocol the Enhanced Interior Gateway Routing Protocol (EIGRP).

• Classless distance vector routing protocol (sometimes referred to as a hybrid routing protocol)
• Cisco proprietary
• IETF Draft draft-savage-eigrp-02
• Uses IP protocol 88
• Sends Hello messages
• Used to form neighbor adjacencies
• Used as a keepalive between neighbors
• Default Hello interval is 5 seconds
• Default on slow (1544kbps and slower) NBMA link is 60 seconds
• Hello messages are sent unreliably
• Uses a Holddown timer
• Default Holddown timer is set to 15 seconds
• Default on slow NBMA link is 180 seconds
• Sends partial and full updates
• Updates are triggered
• Uses reliable transport protocol (RTP)
• Uses multicast address 224.0.0.10 for IPv4 and FF02::A for IPv6
• Retransmissions are sent to each neighbor's unicast address
• Default administrative distance
• Internal: 90
• External: 170
• Uses a composite metric
• Defaults to using bandwidth and delay to determine the best path
• The composite metric can be weighted by tuning the K values 1 through 5
• The K values must match on all routers
• Supports a maximum hop count of 255 with the default set to 100
• The hop count is mainly used as a loop-prevention mechanism
• EIGRP defaults to using a maximum of 50% of the bandwidth on a link for exchanging hello and updates
• This can be tuned using the interface level sub-command ip bandwidth-percent eigrp <as#> <seconds>
• Supports authentication using MD5 (SHA is supported when using Named Mode)
• Supports route tags
• Supports next-hop advertisement
• Supports manual route summarization in any arbitrary point in the network
• Supports IPv4 and IPv6
• Supports unequal cost load-sharing
• Supports split-horizon with poison reverse
• Uses Diffusing Update Algorithm (DUAL) to control diffusing computations of the topology

Things that have to match for adjacencies to form in EIGRP:

• Authentication (if used)
• K values
• Autonomous System (AS) number
• Primary addresses on interfaces configured in the same common subnet

The last item warrants a little more explanation and I have made a post that goes into more detail regarding this point here. 

The EIGRP composite metric is calculated using these five K values:

1. Bandwidth
2. Load
3. Delay
4. Reliability
5. Maximum Transmission Unit (MTU)

By default, EIGRP uses only K values 1 and 3. This means that bandwidth and delay are the only values used in the composite metric. When manually tweaking EIGRP metrics it is recommended only to use the delay because the bandwidth is also used by other features such as QoS - whereas delay is only used by EIGRP.

EIGRP uses passive to show a route as stable and active to show a route that is in trouble - meaning a route that has been lost and it is now actively trying to find a new path to the network.

When a router loses reachability to a network it will send out queries to its adjacent neighbors to see if they have a path to the lost network. When this happens, the route is marked as active until replies are heard back from all the neighbors queried or the active timer runs out.
If a reply is not heard within 90 seconds, the local router will send an SIA-query (SIA meaning stuck-in-active) in an attempt to ascertain the reason for the missing reply - or more specifically, is the neighbor still working on the query request or did it not receive the initial query at all. Failure to respond to the SIA-query will result in the local router deleting routes through the non-responsive neighbor and resetting the adjacency. If the neighbor responds to the SIA-query, the active timer will be reset and another SIA-query will be sent again at half the active timer (90 seconds). This allows for an extension of the active timer if the reason behind the slowdown is the neighbors waiting for the active process to complete. A maximum of 3 SIA-queries will be sent before the neighbor adjacency will be reset.

EIGRP supports a graceful shutdown function, where the router sends a hello packet to its neighbor with all the K values set to 255. This happens when an interface running EIGRP is shutdown or the EIGRP process itself is shutdown. It enables the router to signal its neighbors to terminate the adjacency and allows the neighbors to initiate the process of finding an alternate route to the networks advertised by the router shutting down immediately instead of having to wait for the holddown timer to expire.

Below are a few nifty show commands for EIGRP.

The command show ip eigrp traffic gives a statistic of packets sent and received for the EIGRP proces.

The command show ip eigrp neighbors gives a view of the EIGRP adjacency table.

The command show ip route eigrp shows the EIGRP routes currently installed into the routing table.
The command show ip eigrp timers gives a view of the current hello and holddown timers for the EIGRP enabled interfaces.
The command show ip eigrp topology will show the EIGRP topology and will also display the EIGRP process router-id. With the keyword all-links it is possible to view the entire topology as advertised by neighbors (including feasible successor links).

RIPng Overview

So, the eggheads of the networking industry couldn't bear an IP protocol without RIP and so we get RIPng for our IPv6 networks. The "ng" stands for Next Generation, but it is sometimes referred to as RIPv6 or IPv6 RIP.

Below are listed some of the facts of RIPng. The below summary is based on the defaults of Cisco's implementation of RIPng and there are only few differences compared to RIPv2 for IPv4.

• Defined in RFC 2080
• Runs on port UDP/521 (not 520 to avoid clashing with IPv4 RIP configurations)
• Sends updates to multicast address FF02::9
• Metric is still based on hop count with 15 being the maximum and 16 being infinity (unreachable)
• Unlike RIPv2, the sending router does not increment the hop count in advertised routes before sending it out to its neighbors. Instead, it does the most logical thing and advertises what it has in its routing table. The receiving router is responsible for incrementing the entries before entering it into its own routing table
• Default administrative distance is 120
• It is driven mainly by timers
• Update timer: 30 sec.
• sends out the entire routing table every 30 sec. on RIP enabled interfaces (routes affected by the split horizon rule are excluded from the update)
• Triggered updates occur when a route change occurs and an update, including only the changed route, is sent out. Regular updates are unaffected by this and are still sent per the update timer interval
• Cisco uses a jitter variable to avoid update synchronization, just like in RIPv2, but I am unclear on the specific details - I can only assume they function the same way.
• Expiration timer: 180 sec.
• Similar to RIPv2 invalid timer. The expiration timer tracks the validity of a specific route. It resets to 0 whenever a route is received in an update and a route is considered invalid if the route is not received within 180 seconds.
• After the expiration timer expires the route is advertised with a metric of 16 (unreachable) until it is purged from the routing table
• Holddown timer: 0 sec.
• Cisco defaults to not using the holddown timer in RIPng
• Garbage collection timer: 120 sec.
• Unlike RIPv1 and v2, RIPng garbage collection timer starts counting after the specific routes expiration timer is exceeded
• The route is advertised with a metric of 16 (unreachable) for 120 seconds - after which the route is purged from the routing table
• An update message can contain as many entries as the MTU size allows (unlike RIPv1 and v2, which only allows for 25 entries per update message)
• Does not natively support authentication
• It uses IPv6 built-in authentication features (I will find the time to do a post on that on a later date)
• The ring is able to tag routes being redistributed into the routing process
• Unlike RIPv1 and v2, RIPng supports multiple instances running on the same router
• Cisco uses named instances, where instance names are locally significant and do not have to match between routers
• Use the global configuration command ipv6 router rip <instance name> to enter the general process configuration mode
• Use the interface sub-command ipv6 rip <instance name> enable to enable RIPng on a specific interface

Below is a packet capture of a RIPng update message (also known as a response) sent from the IPv6 link-local address of FE80::13:3 to the IPv6 multicast address of FF02::9.

RIPng response message, including two prefixes

RIPv2 Overview

RIPv2 is a simple routing protocol - at least when compared to other major routing protocols like OSPF and BGP. The pros for using RIPv2 in a network is the ease of configuration and maintenance of the routes and also the network traffic generated by the protocol is somewhat less than that of other routing protocols. Also, most vendor equipment supports RIPv2 and so is a fairly common protocol to come by in smaller routing environments. The cons, however, are the protocols slow convergence time and lack of scalability.

Below are listed some of the quick hard facts of RIPv2. The below summary is based on the defaults of Cisco's implementation of RIPv2 - timers and the likes can vary from vendor to vendor.

• Defined in RFC 2453
• Supports classless routing operation (unlike RIPv1 which is only classfull)
• Runs on port UDP/520
• Sends updates to multicast address 224.0.0.9
• can be changed to unicast with the neighbor <ip address> command under the routing process
• can be changed to broadcast with the ip rip v2-broadcast command under a given interface
• Metric is based on hop count with 15 being the maximum and 16 being infinity (unreachable)
• The sending router increments the hop count in advertised routes before sending it out to its neighbors. Thus, receiving routers do not increment the metric, but enters the metric directly into its routing table
• Default administrative distance is 120
• It is driven mainly by timers
• Update timer: 30 sec.
• sends out the entire routing table every 30 sec. on RIP enabled interfaces (routes affected by the split horizon rule are excluded from the update)
• Triggered updates occur when a route change occurs and an update, including only the changed route, is sent out. Regular updates are unaffected by this and are still sent per the update timer interval
• Cisco implements a RIP_JITTER variable that randomly subtracts 0-15% from the 30 second timer to avoid the synchronization of routing updates with its neighbors. This changes the effective update interval to between 25,5 and 30 seconds
• Invalid timer: 180 sec.
• The invalid timer tracks the validity of a specific route. It resets to 0 whenever a route is received in an update and a route is considered invalid after 180 sec.
• After the invalid timer expires the route is advertised with a metric of 16 (unreachable) until it is purged from the routing table
• Holddown timer: 180 sec.
• After the invalid timer expires the holddown timer starts counting. Even if a valid route is received in an update, it will not be entered into the routing table until the holddown timer expires or the route is flushed from the routing table (either manually or by the timer)
• Flush after timer: 240 sec.
• The flush after timer (or garbage collection timer) starts counting after the last routing update is received - effectively counting alongside the invalid timer and subsequently the holddown timer
• By default, 60 seconds after the invalid timer expires (and only 60 seconds into the holddown timer) the flush after timer runs out and the route is purged from the routing table
• No neighbor adjacency is formed and no hello packets are sent
• An update message can contain up to 25 entries
• Supports authentication using plain-text or MD5 hashing
• RIPv2 is able to tag routes being redistributed into the routing process

Below is a packet capture of RIPv2 update (also known as a response) sent from 10.0.0.1 to a multicast address of 224.0.0.9. Worth noting is that the packet is filled with 25 network entries all with a metric of 1 except for the first entry being advertised with a metric of 16 due to a simulated network failure (interface shutdown) on the source router 10.0.0.2. Not shown in the screen dump is the subsequent packet sent from the router 10.0.0.2 including two additional subnets.

RIPv2 response message, including 25 entries

If we look deeper into one of the entries we can see that the entry includes a subnet mask (which is not included in RIPv1) making it possible to advertise variable length subnet masks (VLSM) - making it a classless routing protocol. Also, note the next-hop being set to all 0's, which means that the next-hop address is assumed to be the same as the source of the update (10.0.0.2).

RIPv2 response message entry

A short explanation of split-horizon is warranted. Split-horizon simply states that a router should not advertise a route out of the same interface that it learned it from. This is to prevent routing loops from occurring, but it can in some cases cause issues with routes not being sent to valid neighbors on DMVPN interfaces for example.

Basic Multi Layer Switch (MLS) configuration

Okay, so a fairly common thing would be to have a multi layer switch in your network - at least when your network becomes larger than what can usually be plugged into a switch or two.

It may look something like this: some beefy core MLS that can push packets real quick, some less beefy, but still awesome, distribution MLS and finally some relatively inexpensive layer 2 switches to connect your clients, printer, access points, servers and whatever else you may have need of connecting to the network.

Core-Distribution-Access Diagram

For the sake of simplicity we will just assume the access layer switches are configured and functions only at layer 2. In this example we will focus solely on the distribution switches/routers (MLS).

Let's start out by getting the layer 2 functions working. We configure our VTP mode to be transparent and then create 4 VLANs (10, 20, 30 and 40).

DIST-SW-01(config)#vtp mode transparent
Setting device to VTP Transparent mode for VLANS.
DIST-SW-01(config)#vlan 10,20,30,40

The same configuration is done on DIST-SW-02, but not shown here to keep this example somewhat brief and manageable.

Then we create the layer 2 port-channel between the two distribution switches and configures it as a trunk port for all VLANs.

DIST-SW-01(config)#interface range FastEthernet0/23-24
DIST-SW-01(config-if-range)#switchport trunk encapsulation dot1q
DIST-SW-01(config-if-range)#switchport mode trunk
DIST-SW-01(config-if-range)#switchport nonegotiate
DIST-SW-01(config-if-range)#channel-group 1 mode active

Before we configure any of the layer 3 features we will need to enable IP routing on the two distribution switches. You can enable IP interfaces and configure redundancy protocols, but what you will experience is a complete lack of routing ability if this command is absent.

DIST-SW-01(config)#ip routing

 DIST-SW-02(config)#ip routing

Secondly, we will configure a first hop redundancy protocol for the clients connected to the access switches to use as their default gateways. We will make distribution switch 1 the active forwarder for odd numbered VLANs and distribution switch 2 will be the active forwarder for evenly numbered VLANs.

Distribution switches with VLANS and HSRP configured

Configuration on Distribution Switch 1

interface Vlan10
 ip address 10.0.10.1 255.255.255.0
 standby 10 ip 10.0.10.254
 standby 10 priority 110
 standby 10 name VLAN_10
!
interface Vlan20
 ip address 10.0.20.1 255.255.255.0
 standby 20 ip 10.0.20.254
 standby 20 name VLAN_20
!
interface Vlan30
 ip address 10.0.30.1 255.255.255.0
 standby 30 ip 10.0.30.254
 standby 30 priority 110
 standby 30 name VLAN_30
!
interface Vlan40
 ip address 10.0.40.1 255.255.255.0
 standby 40 ip 10.0.40.254
 standby 40 name VLAN_40

Configuration on Distribution Switch 2

interface vlan 10
 ip address 10.0.10.2 255.255.255.0
 standby 10 ip 10.0.10.254
 standby 10 name VLAN_10
!
interface vlan 20
 ip address 10.0.20.2 255.255.255.0
 standby 20 priority 110
 standby 20 preempt
 standby 20 ip 10.0.20.254
 standby 20 name VLAN_20
!
interface vlan 30
 ip address 10.0.30.2 255.255.255.0
 standby 30 ip 10.0.30.254
 standby 30 name VLAN_30
!
interface vlan 40
 ip address 10.0.40.2 255.255.255.0
 standby 40 priority 110
 standby 40 preempt
 standby 40 ip 10.0.40.254
 standby 40 name VLAN_40

Because we use FHRP with the default gateway set differently for the odd and even numbered VLANs, we would want to make sure that the spanning-tree configuration chooses the correct root bridge for those VLANs as well - making Distribution Switch 1 the root for odd numbered VLANs and Distribution Switch 2 the root for evenly numbered VLANs.

DIST-SW-01(config)#spanning-tree vlan 1,10,30 priority 4096
DIST-SW-01(config)#spanning-tree vlan 20,40 priority 8192

DIST-SW-02(config)#spanning-tree vlan 1,10,30 priority 8192
DIST-SW-02(config)#spanning-tree vlan 20,40 priority 4096

Now we will configure the trunk ports from the distribution layer to the access layer. Again, we assume that the access switches are already configured appropriately for this scenario.

DIST-SW-01(config)#interface range fa0/19 , fa0/21
DIST-SW-01(config-if-range)# switchport trunk encapsulation dot1q
DIST-SW-01(config-if-range)# switchport mode trunk
DIST-SW-01(config-if-range)# switchport nonegotiate

The same commands are issued on DIST-SW-02.

Verify the configuration by examining the output of the commands shown in the sections below:

VTP and VLAN configuration

DIST-SW-01#show vtp status
DIST-SW-01#show vlan brief

EtherChannel (port-channel) configuration

DIST-SW-01#show etherchannel summary
DIST-SW-01#show etherchannel 1 detail

HSRP (standby) configuration

DIST-SW-01#show standby brief
DIST-SW-01#show standby vlan [10 | 20 | 30 | 40]

Spanning-tree configuration

DIST-SW-01#show spanning-tree vlan [10 | 20 | 30 | 40]
DIST-SW-01#show spanning-tree root

Switchport trunk configuration
DIST-SW-01#show interfaces trunk
DIST-SW-01#show interfaces [port-channel 1 | fa0/19 | fa0/21] trunk
DIST-SW-01#sh interfaces [port-channel 1 | fa0/19 | fa0/21] switchport

Now we should be able to reach our FHRP default gateways from a client connected to the VLANs 10,20,30 or 40 in the access switches. Here we show only for VLAN 10 and 20 as they should show connectivity through DIST-SW-01 and DIST-SW-02 respectively. Notice that the trace to 8.8.8.8 fails at 10.0.100.10 because that router doesn't have a route towards the destination - what matters here is that it goes to 10.0.10.1 and 10.0.20.2 even though the default gateway is set to .254.

Trace and ARP table on VLAN 10

Trace and ARP table on VLAN 20

Note: some Catalyst multi layer switches, like the Catalyst 3560 used in this example, there may be some commands unavailable if the Switch Database Management (SDM) template is configured to not support the configuration you are attempting.

To troubleshoot issues like these you must first verify that the commands you are trying to configure are supported by referring to the documentation for the specific platform. Secondly, make sure the image and licensing is correct. The command show version gives you the information regarding the platform and the image you are on and some information on the licensing (only on some platforms/IOS versions).

If the image and licensing is in order, but you still cannot input the desired commands, you may be using the incorrect SDM template. Check the currently used template with this command:

DIST-SW-01#show sdm prefer
 The current template is "desktop default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.
  number of unicast mac addresses:                             6K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                                  8K
  number of directly-connected IPv4 hosts:                 6K
  number of indirect IPv4 routes:                                 2K
  number of IPv4 policy based routing aces:               0
  number of IPv4/MAC qos aces:                                0.5K
  number of IPv4/MAC security aces:                         1K

This will display some of the maximums of the current SDM template in use. With this specific template I am unable to configure any policy based routing aces - meaning I cannot configure policy based routing (PBR).

If I had to do PBR on this MLS I would have to change the SDM template. The below command shows how that would be done - bear in mind that you cannot fine tune anything in the SDM templates they come pre-configured.

DIST-SW-01(config)#sdm prefer ?
  access              Access bias
  default             Default bias
  dual-ipv4-and-ipv6  Support both IPv4 and IPv6
  routing             Unicast bias
  vlan                VLAN bias
DIST-SW-01(config)#sdm prefer routing

Also, the switch will need to be reloaded for the new template to take effect.

Address Resolution Protocol

Address Resolution Protocol (ARP - defined in RFC 826) is today mainly used in multi-access IP networks to identify the layer 2 address (MAC address) associated with a specific layer 3 address (IP address).

ARP request and ARP reply

This is done by sending a layer 2 broadcast requesting the MAC address for a specific IP address. To the right is a part of a packet capture of a client (172.17.6.72) broadcasting a request and then the server (172.17.6.5) responding to that request.

The ARP protocol is, strictly speaking a layer 2 protocol, but it carries information to facilitate layer 3 functions. As a layer 2 broadcast it is not routable, but by means of a proxy it can function between clients on different subnets.

Proxy ARP
Proxy ARP can facilitate communication between clients in a scenario where you wish to segment a larger IPv4 scope, but wish to change the addresses of hosts on the subnet gradually.

For example: you have a subnet of 192.168.0.0 /21. This network allows for more than 2000 hosts on the same broadcast domain. Say you would like to segment this /21 subnet into smaller /24 subnets, but some of the hosts include printers that have statically configure IP addresses and subnet masks on the devices. You configure your subnets so that clients are located on the subnet 192.168.1.0 /24 and the printers are in the subnet 192.168.2.0 /24. The clients acquire their address from a DHCP server so they will get the new /24 subnet mask automatically, but the printers are all statically configured with a subnet mask of /21. This means that the clients trying to contact a printer knows that the printers are on another subnet and therefore sends the traffic to their default gateway, but the printers will think that the clients are on the same layer 2 segment as them and will attempt to look them up using an ARP request.
This is where proxy ARP comes into play. It is configured on the interface of the router connected to the printer network so that if it receives an ARP request on the printer interface, requesting a MAC address of a client, it will go ahead and reply to the ARP request with its own MAC address in the reply. The result: the client routes traffic as it was supposed to and the printer sends the traffic to the MAC address of the ARP proxy router, thinking it is the MAC address of the client machine.
Now, the administrator in charge of changing the IP address (or at least the subnet mask) on the printers can do so at his or her own pace.

I am not saying this is a recommended scenario - just that it is possible given the proper circumstances.

There are many other uses for Proxy ARP, which is turned on by default on Cisco devices. You can turn it off on a per interface basis with the command no ip proxy-arp.

Gratuitous ARP
The gratuitous ARP is a special form of ARP request that functions like a reply, but a reply that no one asked for - hence the gratuitous part. It is an ARP request and not an ARP reply mainly because it would be the type of ARP message most likely to be processed by the largest audience of endpoints. More can be read about the specific reasoning here.

The following is true about a Gratuitous ARP packet.

• The destination MAC address is the layer 2 broadcast (ff:ff:ff:ff:ff:ff)
• The source and destination IP address is that of the host sending the gratuitous ARP packet
• No reply is expected

Gratuitous ARP is used to inform hosts on a subnet that a MAC address has changed. This feature is used by HSRP and VRRP to notify the network (mainly the switches) of where to forward packets to their virtual IP address.

ARP Probes
A feature in IPv4 uses ARP probes as a means of Address Conflict Detection (defined in RFC 5227) by using ARP requests to check if an IP address is already in use in the particular broadcast domain.

Reverse ARP
Reverse ARP is where an ARP request is sent out on a subnet with the source and destination MAC address being that of the sender and the source and destination IP address being all zeros (0.0.0.0). This allows a Reverse ARP server to reply to this request with a reply to the MAC address of the sender with an IP address, which needs to be manually defined on the Reverse ARP server beforehand. Essentially making an entry stating which IP address is associated with which MAC address. This is a means of dealing out IP addresses to hosts without statically configuring them on the hosts themselves. This is rarely used today (I have never encountered a network using Reverse ARP for addressing purposes) because of the cumbersome act of manually configuring the database with IP to MAC mappings and the need for the Reverse ARP server to be reachable on the clients layer 2 subnet.

vlan internal allocation policy ascending

If you have worked with Cisco switches for some time you may have noticed this command when viewing the configuration. Ever wonder what it actually means?

Well, I have and today I just so happened to satisfy my own curiosity by looking it up.

In short, it means that the switch will allocate VLANS for internal use starting from VLAN 1006 (because VLAN 1002-1005 are reserved for some legacy stuff that nobody dares remove even though the calendar says 2014).

This may make you go "Oh. Well, of course, that's what it means..." and think no more of it. But, if you are anything like me, you probably went "Ok. What does that mean?". What are VLANS used for "internally" on a Cisco switch?

One example that is easy to setup in the lab is this:

SW01(config)#int gi0/33
SW01(config-if)#no switchport
SW01(config-if)#ip address 192.168.1.1 255.255.255.0

We just changed a switchport on a Catalyst switch into a routed port. Another way of accomplishing this goal would be to do this:

SW01(config)#int gi0/33
SW01(config-if)#switchport access vlan 10
% Access VLAN does not exist. Creating vlan 10
SW01(config-if)#int vlan 10
SW01(config-if)#ip address 192.168.1.1 255.255.255.0

Assuming that interface gi0/33 is the only interface in VLAN 10 - this would pretty much accomplish what the no switchport command does. In fact, it is exactly what the no switchport command does and the vlan internal is the key to show it.

Let us look at the no switchport scenario and see if we can't peek a little behind the curtains.

SW01#show ip interface brief | include GigabitEthernet0/33
GigabitEthernet0/33    192.168.1.1     YES manual down                  down

So, the interface has an IP address assigned manually and it is currently in the down-down state (no cable is attached). Let us try to see some of the internal vlan usage.

SW01#sh vlan internal usage
VLAN Usage
---- --------------------
1006 GigabitEthernet0/33

This shows us that VLAN 1006 has been assigned to GigabitEthernet0/33 (per the allocation policy).

So, what this means is, that when you issue the no switchport command, the switch creates VLAN 1006 and assigns it the IP address and chains it to the physical interface.

A thing to keep in mind is that internally assigned VLANs and user created VLANs share the same database so an error message like the one below is shown if I try to manually create a VLAN that is already assigned internally.

SW01(config)#vlan 1006
SW01(config-vlan)#exit
% Failed to create VLANs 1006
VLAN(s) not available in Port Manager.
%Failed to commit extended VLAN(s) changes.
*Jun 10 08:20:11.932: %PM-4-EXT_VLAN_INUSE: VLAN 1006 currently in use by GigabitEthernet0/33
*Jun 10 08:20:11.932: %SW_VLAN-4-VLAN_CREATE_FAIL: Failed to create VLANs 1006: VLAN(s) not available in Port Manager

You can probably imagine some of the scenarios that might arise if you don't know that this is the way Catalyst switches accomplishes this - maybe you have your own tale to tell on the subject.
Here is a link to an article about one of the more likely situation you might learn of this "feature" in the IOS: http://packetpushers.net/cisco-internal-vlan-usage/

Edit (27-10-2014):
There are a few more things that the no switchport command disables.

You can mimic the no switchport a little better if you issued the following commands:

SW01(config)#no spanning-tree vlan 10
SW01(config)#no mac address-table learning vlan 10
SW01(config)#interface gi0/33
SW01(config-if)#switchport mode access
SW01(config-if)#switchport access vlan 10
SW01(config-if)#switchport nonegotiate
SW01(config-if)#no vtp
SW01(config-if)#exit
SW01(config)#interface vlan 10
SW01(config-if)#ip address 192.168.1.1 255.255.255.0

This disables spanning-tree and mac learning on the vlan, adds the port to the vlan as an access port, disables DTP negotiation and VTP on the port and finally configures an IP address on the SVI (switched virtual interface).