Unmanaged switches — These switches have no configuration interface or options. They are plug-and-play. They are typically the least expensive switches, found in home, SOHO, or small businesses. They can be desktop or rack mounted.
Managed switches — These switches have one or more ways, or interfaces, to modify the operation of the switch. Common management methods include: a serial console or Command Line Interface accessed via telnet or Secure Shell; an embedded Simple Network Management Protocol SNMP agent allowing management from a remote console or management station; a web interface for management from a web browser. Examples of configuration changes that one can do from a managed switch include: enable features such as Spanning Tree Protocol; set port speed; create or modify VLANs, etc.
Two sub-classes of managed switches are marketed today:
Smart (or intelligent) switches — These are managed switches with a limited set of management features. Likewise "web-managed" switches are switches which fall in a market niche between unmanaged and managed. For a price much lower than a fully managed switch they provide a web interface (and usually no CLI access) and allow configuration of basic settings, such as VLANs, port-speed and duplex.[10]
Enterprise Managed (or fully managed) switches - These have a full set of management features, including Command Line Interface, SNMP agent, and web interface. They may have additional features to manipulate configurations, such as the ability to display, modify, backup and restore configurations. Compared with smart switches, enterprise switches have more features that can be customized or optimized, and are generally more expensive than "smart" switches. Enterprise switches are typically found in networks with larger number of switches and connections, where centralized management is a significant savings in administrative time and effort. A Stackable switch is a version of enterprise-managed switch.
Source: http://en.wikipedia.org/wiki/Network_switch
I would explain in more personal detail, but the wiki explains it pretty well.
I will complete Zoredache's answer.
A L2 switch does switching only. This means that it uses MAC addresses to switch the packets from a port to the destination port (and only the destination port). It therefore maintains a MAC address table so that it can remember which ports have which MAC address associated.
A L3 switch also does switching exactly like a L2 switch. The L3 means that it has an identity from the L3 layer. Practically this means that a L3 switch is capable of having IP addresses and doing routing. For intra-VLAN communication, it uses the MAC address table. For extra-VLAN communication, it uses the IP routing table.
This is simple but you could say "Hey but my Cisco 2960 is a L2 switch and it has a VLAN interface with an IP !". You are perfectly right but that VLAN interface cannot be used for IP routing since the switch does not maintain an IP routing table.
Best Answer
The introduction document on the strongSwan wiki has some more information about this. The three options to start connections are as follows:
Manually (or by remote peers): Connections with
auto=addare loaded but nothing happens automatically afterwards. They can then be initiated manually usingipsec up <name>(provided a single hostname/IP is configured inright).Such connections also allow remote peers to initiate a connection, given their IP matches whatever is configured in
right(so you'll often see connections withright=%anyin remote access scenarios, where the clients' IP addresses are generally unknown).Automatically: With
auto=starta connection is loaded and the IKE daemon will immediately start to connect to the remote host configured inright. This is basically like manually callingipsec upfor these connections directly after the IKE daemon got started.On demand: The IKE daemon will load connections with
auto=routeand install trap policies, based on the traffic selectors configured withleft|rightsubnet, in the underlying IPsec implementation, for instance, the Linux kernel. When the kernel later encounters traffic that matches these policies it will request the IKE daemon to initiate the connection.Such connections can also be initiated manually using
ipsec up.Furthermore it is possible to remove the policies installed in the kernel later on using
ipsec unroute. The connection then has the same status as one that got added withauto=add. Likewise, connections that were loaded withauto=add(orauto=start) can be routed usingipsec route.