Monthly Archives: March 2016

RIP and RIPng

RIPv2 UDP port 520
No hello, RIPv2 relies on the regular full routing updates instead
Update interval 30 seconds
Full updates each interval. For on-demand circuits, allows RIPv2 to
send full updates once, and then remain silent until changes occur, per
RFC 2091
When route changes – triggered update.
Auth: plain-text + MD5
Route tags
Next-hop field

Update 30 s
Invalid after timer per route default 180 s
Holddown timer begins after a route has been declared invalid; default 180 s. The router starts advertising that route as unreachable, does not accept any updated information, and does not modify the routing table entry for that route.
Flushed after timer per route default 240 seconds; If the updates about the route from its next hop cease to be received and the Flushed after timer reaches its limit, the router removes the route from the routing table entirely.
The default timer setting actually does not allow the Holddown timer to completely expire. As a result, the effective Holddown period is only 60 seconds.

  router rip
      timers basic update invalid holddown flush

The RIP packet format is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |  command (1)  |  version (1)  |       must be zero (2)        |
      |                                                               |
      ~                         RIP Entry (20)                        ~
      |                                                               |

RIP Entry :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      | address family identifier (2) |      route tag    (2)         |
      |                        IPv4 address (4)                       |
      |                        Subnet Mask  (4)                       |
      |                        Next-hop addr (4)                      |
      |                           metric (4)                          |

A RIP message consists of a 4B-long header containing the command field (set to 1 for
Request, 2 for Response) and the version field (2 for RIPv2). The remaining two octets
are unused. The remainder of the message consists of routing entries, with each routing
entry occupying 20 octets in total. At most 25 routing entries can be placed into a single
RIP message. Each routing entry contains the address family identifier identifying the
format of the address information carried in the routing entry (only the value 2, IPv4—
also known as AF_INET—is commonly supported), route tag, and the route itself—its
address, netmask, recommended next hop, and metric.

A Request message is used to ask a neighbor to send a partial or a full RIP update immediately,
rather than waiting for the Update timer to expire, speeding the convergence. A
full RIP update is requested by a Request message containing exactly one routing entry
with the address family ID set to 0 and metric set to 16. Otherwise, if a Request message
lists one or more particular networks, only the update on these networks is requested.

RIPv2 increments the metric when sending updates; RIPng and EIGRP increment metrics when receiving updates.

RIPv2 uses autosummarization at classful network boundaries by default.

Cisco IOS enables the RIPv2 (and EIGRP) authentication process on a per-interface basis

interface Fa0/1
   ip rip authentication key-chain name
   ip rip authentication mode { text | md5 }

When authentication is enabled, the maximum number of prefixes that can be advertised
in a RIPv2 message is reduced by 1 to a value of 24. The first route entry in each RIPv2
message would be carrying 20 bytes of authentication data.


FF02::9 UDP port 521
No multiproto capability, so no address-family field.
Version field set to 1

Packet format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |  command (1)  |  version (1)  |       must be zero (2)        |
      |                                                               |
      ~                Route Table Entry 1 (20)                       ~
      |                                                               |
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      |                                                               |
      ~                Route Table Entry N (20)                       ~
      |                                                               |

Route Table Entry:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |                                                               |
      ~                        IPv6 prefix (16)                       ~
      |                                                               |
      |         route tag (2)         | prefix len (1)|  metric (1)   |

The number of route entries in a RIPng message is limited only by the IPv6 MTU on the link, and the protocol itself poses no limitations on their count.

A next-hop RTE is identified by 0xFF in the metric field. The IPv6 prefix field contains the IPv6 address of the next-hop. The route-tag and prefix-len fields are set to 0.

  • Authentication or encryption by IPsec is not supported.
  • Split Horizon can be activated or deactivated only on a per-process basis
  • Passive interfaces are not supported.
  • Static (manual) neighbors cannot be configured (no neighbor command).
  • Per-process offset lists are not supported.


  • Multiple RIPng processes can be run on a router
  • Route Poisoning, as an enhancement of the Split Horizon mechanism, can be activated
    on a per-process basis.
  • Interfaces can be configured with a metric-offset value
  • The default route can be originated on a per-interface basis, including an option of
    suppressing all other updates over that interface.



ip cef and ipv6 cef

ip cef load-sharing algorithm and ipv6 cef load-sharing algorithm :

  • Original algorithm: As the name suggests, this is the original unseeded implementation prone to CEF polarization.
  • Universal algorithm: An improved algorithm using the Universal ID to avoid the CEF polarization.
  • Tunnel algorithm: A further improvement on the Universal algorithm especially suitable to environments where tunnels are extensively deployed, possibly resulting in arelatively small number of outer source/destination pairs. Avoids the CEF polarization. Might not be available for IPv6 CEF.
  • L4 port algorithm: Based on the Universal algorithm while also taking the L4 source and/or destination ports into account. Avoids the CEF polarization.

mls ip cef load-sharing (6500/7600):

Default ( default mls ip cef load-sharing ): Uses source and destination IP, plus the
Universal ID if supported by the hardware. Avoids CEF polarization.
Full ( mls ip cef load-sharing full ): Uses source IP, destination IP, source L4 port, and
destination L4 port. Does not use Universal ID. Prone to CEF polarization. However,
to alleviate its impact, this load-balancing algorithm causes the traffic to split equally
among multiple paths only if the number of paths is odd. With an even number of
parallel paths, the ratio of traffic split will not be uniform.
Simple ( mls ip cef load-sharing simple ): Uses source and destination IP only. Does
not use Universal ID. Prone to CEF polarization.
Full Simple ( mls ip cef load-sharing full simple ): Uses source IP, destination IP,
source L4 port, and destination L4 port. Does not use Universal ID. Prone to CEF
polarization. The difference from Full mode is that all parallel paths receive an equal
weight, and fewer adjacency entries in hardware are used. This mode avoids unequal
traffic split seen with Full mode.

unique-ID/universal-ID – adds a 32-bit router-specific value to the hash function (called the universal ID – this is a randomly generated value at the time of the switch boot up that can can be manually controlled).  This unique -ID concept does not work for an even number of equal-cost paths due to a hardware limitation, but it works perfectly for an odd number of equal-cost paths. In order to overcome this problem, Cisco IOS adds one link to the hardware adjacency table when there is an even number of equal-cost paths in order to make the system believe that there is an odd number of equal-cost links.

CEF Polarization:
CEF description:


This separation is achieved through the Forwarding and Feature Manager (FFM) and the
Forwarding Engine Driver (FED).
The FFM provides a set of APIs used to manage the control plane processes. The resulting
outcome is that the FFM programs the data plane through the FED and maintains all
forwarding states for the system. It is the FED that allows the drivers to affect the data
plane, and it is provided by the platform.


EEM uses event detectors and actions to provide notifications of
those events.

Event detectors that EEM supports include the following:
■ Monitoring SNMP objects
■ Screening Syslog messages for a pattern match (using regular expressions)
■ Monitoring counters
Timers (absolute time-of-day, countdown, watchdog, and CRON)
■ Screening CLI input for a regular expression match
Hardware insertion and removal
Routing table changes
IP SLA and NetFlow events
■ Generic On-Line Diagnostics (GOLD) events
■ Many others, including redundant switchover events, inbound SNMP messages, and
Event actions that EEM provides include the following:
■ Generating prioritized Syslog messages
Reloading the router
Switching to a secondary processor in a redundant platform
■ Generating SNMP traps
■ Setting or modifying a counter
■ Executing a Cisco IOS command
■ Sending a brief email message
Requesting system information when an event occurs
■ Reading or setting the state of a tracked object


IP Traffic Export, or Router IP Traffic Export (RITE), exports IP packets to a VLAN or
LAN interface for analysis. RITE does this only for traffic received on multiple WAN
or LAN interfaces simultaneously as would typically take place only if the device were
being targeted in a denial of service attack.

When configuring RITE, you enable it and configure it to direct copied packets to the
MAC address of the IDS host or protocol analyzer.

Inbound traffic (the default), outbound traffic, or both, and filtering on the number of
packets forwarded.

Edge# config term
Edge(config)# ip traffic-export profile export-this
Edge(config-rite)# interface fa0/0
Edge(config-rite)# bidirectional
Edge(config-rite)# mac-address 0018.0fad.df30
Edge(config-rite)# incoming sample one-in-every 20
Edge(config-rite)# outgoing sample one-in-every 100
Edge(config-rite)# exit
Edge(config)# interface fa0/1
Edge(config-if)# ip traffic-export apply export-this
Edge(config-if)# end
%RITE-5-ACTIVATE: Activated IP traffic export on interface FastEthernet 0/1.


The components of NetFlow are
Records: A set of predefined and user-defined key fields (such as source IP address,
destination IP address, source port, and so on) for network monitoring.
Flow monitors: Applied to an interface, flow monitors include records, a cache, and
optionally a flow exporter. The flow monitor cache collects information about flows.
Flow exporters: These export the cached flow information to outside systems (typically
a server running a NetFlow collector).
Flow samplers: Designed to reduce the load on NetFlow-enabled devices, flow samplers
allow specifying the sample size of traffic, NetFlow analyzes to a ratio of 1:2
through 1:32768 packets. That is, the number of packets analyzed is configurable
from 1/2 to 1/32768 of the packets flowing across the interface.

Version 1 (V1) is the original format supported in the initial NetFlow releases.

Version 5 (V5) is an enhancement that adds Border Gateway Protocol (BGP) autonomous system information and flow sequence numbers.

Version 8 (V8) is an enhancement that adds router-based aggregation schemes.

Version 9 is an enhancement to support different technologies such as Multicast, Internet Protocol Security (IPSec), BGP next-hops and Multi Protocol Label Switching (MPLS).


  • UDP port 2048
  • content engines also communicate with each other using WCCP
  • Up to 32 content engines WCCPv1; lowest IP address – lead engine
  • Content engines request information on the cluster members from the WCCP
    router, which replies with a list. This permits the lead content engine to determine how
    traffic should be distributed to the cluster.
  • WCCPv1 – only HTTP port 80
  • WCCPv2:
    • TCP and UDP traffic other than TCP port 80 (FTP, Real Audio, Video)
    • Permits segmenting caching services provided by a caching cluster to a particular
      protocol or protocols
    • Supports multicast
    • Supports multiple routers (up to 32 per cluster)
    • MD5
    • Load distribution
    • Transparent error handling
ip wccp web-cache group-address password cisco
! Next we configure an interface to redirect WCCP web-cache
! traffic outbound to a content engine:
int fa0/0
           ip wccp web-cache redirect out
! Finally, inbound traffic on interface fa0/1 is excluded from redirection:
int fa0/1
         ip wccp redirect exclude in
! filter traffic only for certain clients
ip wccp web-cache redirect-list access-list
! types of redirected traffic the router should accept
ip wccp web-cache group-list access-list


  • UDP 161
  • UDP 162 (traps & informs)
SNMP Version Description
1 Uses SMIv1, simple authentication with communities, but used MIB-I originally.
2 Uses SMIv2, removed requirement for communities, added GetBulk and Inform messages, but began with MIB-II originally.
2c Pseudo-release (RFC 1905) that allowed SNMPv1-style communities with SNMPv2; otherwise, equivalent to SNMPv2.
3 Mostly identical to SNMPv2, but adds significantly better security, although it supports communities for backward compatibility. Uses MIB-II. MD5/SHA + DES.




Remote Monitoring, or RMON, is an event-notification extension of the SNMP capability
on a Cisco router or switch. RMON enables you to configure thresholds for alerting
based on SNMP objects, so that you can monitor device performance and take appropriate
action to any deviations from the normal range of performance indications.
RMON is divided into two classes: alarms and events.

rmon event 1 log trap public description Fa0.0RisingErrors owner config
rmon event 2 log trap public description Fa0.0FallingErrors owner config
rmon event 3 log trap public description Se0.0RisingErrors owner config
rmon event 4 log trap public description Se0.0FallingErrors owner config
rmon alarm 11 ifInErrors.1 60 delta rising-threshold 10 1 falling-threshold 5 2 
owner config
rmon alarm 20 ifInErrors.2 60 absolute rising-threshold 20 3 falling-threshold 10 
owner config

show rmon alarm
show rmon event

Jun 9 12:54:14.787: %RMON-5-FALLINGTRAP: Falling trap is generated
because the value of ifInErrors.1 has fallen below the fallingthreshold
value 5
Jun 9 12:55:40.732: %RMON-5-FALLINGTRAP: Falling trap is generated
because the value of ifInErrors.2 has fallen below the fallingthreshold
value 10


  • UDP 123
  • Modes: client (static/broadcast); server; symmetric active mode (ntp peer)

1) Peer – permits router to respond to NTP requests and accept NTP updates. NTP control queries are also accepted. This is the only class which allows a router to be synchronized by other devices.
2) Serve – permits router to reply to NTP requests, but rejects NTP updates (e.g. replies from a server or update packets from a peer). Control queries are also permitted.
3) Serve-only – permits router to respond to NTP requests only. Rejects attempt to synchronize local system time, and does not access control queries.
4) Query-only – only accepts NTP control queries. No response to NTP requests are sent, and no local system time synchronization with remote system is permitted.




  • Virtual IP address and virtual MAC are active on the HSRP Active router.
  • 3 sec hello, 10 sec dead
  • – V1
  • – V2
  • Virtual MAC of 0000.0C07.ACxx (v1)
  • Virtual MAC of 0000.0c9f.fxxx for IPv4 (v2) and 0005.73a0.0xxx for IPv6 (v2)
  • Port UDP 1985 for IPv4
  • Port UDP 2029  for IPv6 
  • Clear-text & MD5 auth
  • MHSRP (administrative LB)
  • Only 1 standby, highest IP preemts standby.


  • IP protocol number 112; TTL 255 – MUST
  • 1 sec hello, 3 sec dead
  • Virtual MAC of 0000.5E00.01xx
  • Preempts by default
  • Group IP address is the interface IP address of one of routers (prio for the router will be 255)
  • Higest IP preempts; more than 1 standby
  • The priority value zero (0) has special meaning indicating that the current Master has stopped participating in VRRP. Backups quickly transition to master.


  • UDP 3222
  • 3 sec hello, 10 sec dead
  • 0007.B400.xxyy , where xx is the GLBP group number and yy is a different number for each router (01, 02, 03, or 04).
  • 1024 GLBP groups per physical interface and up to four AVF per GLBP group
  • If multiple gateways have the same priority (1-255), the gateway with the highest real IP address becomes the AVG; standby AVG election – same principle.
  • The Redirect timer (600 sec) determines how long will AVG continue to respond to ARP requests with the virtual MAC of the failed AVF. The Secondary Hold  (4 hours, 14400 sec) timer sets the amount of time the backup AVF will continue to accept packet for the virtual MAC address taken from the failed AVF.


Relies on server to allocate IP addresses Yes Yes Yes
Encapsulates messages inside IP and UDP so that they can be forwarded to a remote server No Yes Yes
Client can discover its own mask/gateway/DNS/download server No Yes Yes
Dynamic address assignment from a pool of IP addresses without requiring knowledge of client MACs No No Yes
Allows temporary lease of IP address No No Yes
Includes extensions for registering client’s FQDN with a DNS No No Yes



Ethernet proto type: 0x0806


Same old ARP message, but the ARP request lists a MAC address target of its own MAC address and a target IP address of RARP server on the same subnet. ARP reply, after entering the configured IP address in the Source IP address field.


IP+UDP header.


IP+UDP header.

DHCP relay:

  • set own IP address in gateway IP address (giaddr) field while relaying
  • change the destination IP address to a LAN broadcast, and forward the packet
    onto the client’s LAN

NAT order of operations


Inside-to-Outside Outside-to-Inside
  • If IPSec then check input access list
  • decryption – for CET (Cisco Encryption Technology) or IPSec
  • check input access list
  • check input rate limits
  • input accounting
  • redirect to web cache
  • policy routing
  • routing
  • NAT inside to outside (local to global translation)
  • crypto (check map and mark for encryption)
  • check output access list
  • inspect (Context-based Access Control (CBAC))
  • TCP intercept
  • encryption
  • Queueing
  • If IPSec then check input access list
  • decryption – for CET (Cisco Encryption Technology) or IPSec
  • check input access list
  • check input rate limits
  • input accounting
  • redirect to web cache
  • NAT outside to inside (global to local translation)
  • policy routing
  • routing
  • crypto (check map and mark for encryption)
  • check output access list
  • inspect CBAC
  • TCP intercept
  • encryption
  • Queueing

Note that the process is merely the same. But for inside process the NAT is performed after routing. As for outside the NAT if performed before routing. Which seems pretty logical 😉

QoS order of operations

1. QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB)
2. Input common classification
3. Input ACLs
4. Input marking (class-based marking or Committed Access Rate (CAR))
5. Input policing (through a class-based policer or CAR)
6. IP Security (IPSec)
7. Cisco Express Forwarding (CEF) or Fast Switching

1. CEF or Fast Switching
2. Output common classification
3. Output ACLs
4. Output marking
5. Output policing (through a class-based policer or CAR)
6. Queueing (Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)), and Weighted Random Early Detection (WRED)

BGP order of preference

For inbound updates the order of preference is:
1. route-map
2. filter-list
3. prefix-list, distribute-list

For outbound updates the order of preference is:
1. filter-list
2. route-map | unsuppress-map
3. advertise-map (conditional-advertisement)
4. prefix-list|distribute-list
5. ORF prefix-list (a prefix-list the neighbor sends us)


Tunnel Mode  Topology and Address Space  Applications 
Automatic 6to4 Point-to-multipoint; 2002::/16 addresses Connecting isolated IPv6 island networks.
Manually configured Point-to-point; any address space; requires dual-stack support at both ends Carries only IPv6 packets across IPv4 networks.
IPv6 over IPv4 GRE Point-to-point; unicast addresses; requires dual-stack support at both ends Carries IPv6, CLNS, and other traffic.
ISATAP Point-to-multipoint; any multicast addresses Intended for connecting IPv6 hosts within a single site.
Automatic IPv4- compatible Point-to-multipoint; ::/96 address space; requires dual-stack support at both ends Deprecated. Cisco recommends using ISATAP tunnels instead. Coverage in this book is limited.
Tunnel Type  Tunnel Mode  Destination 
Manual ipv6ip  An IPv4 address
GRE over IPv4 gre ip  An IPv4 address
Automatic 6to4 ipv6ip 6to4  Automatically determined
ISATAP ipv6ip isatap  Automatically determined
Automatic IPv4-compatible ipv6ip auto-tunnel  Automatically determined

Automatic IPv4-Compatible Tunnels

The first 96 bits of the tunnel interface addresses are all 0s, and the remaining 32 bits are derived from an IPv4 address. These addresses are written as 0:0:0:0:0:0:A.B.C.D, or ::A.B.C.D, where A.B.C.D represents the IPv4 address.

Automatic 6to4 Tunnels

Per-packet basis to encapsulate traffic to the correct destination—thus its point-to-multipoint nature.


This prefix-generation method leaves another 16 bits in the 64-bit prefix for numbering networks within a given site.

interface Ethernet2/0
 description Ethernet link to the outside world
 ip address
 interface Tunnel0
 no ip address
 ipv6 address 2002:0a01:6401::1/64
 tunnel source Ethernet 2/0
 tunnel mode ipv6ip 6to4
 ipv6 route 2002::/16 tunnel

ISATAP Tunnels

Treat underlying network like NBMA cloud. Point-to-multipoint operations.

[64-bit link-local or global unicast prefix]:0000:5EFE:[IPv4 address of the ISATAP link]

For example, let’s say that the IPv6 prefix in use is 2001:0DB8:0ABC:0DEF::/64 and the IPv4 tunnel destination address is The IPv4 address, converted to hex, is AC14:1401. Therefore the ISATAP address is


Interface MUST be configured to derive the IPv6 address using the EUI-64 method. EUI-64 addressing in a tunnel interface differs from EUI-64 on a nontunnel interface in that it derives the last 32 bits of the interface ID from the tunnel source interface’s IPv4 address.

By default, tunnel interfaces disable router advertisements (RA). However, RAs must be enabled on ISATAP tunnels to support client autoconfiguration (no ipv6 nd supress-ra).




IPv6 hosts can use stateless or stateful autoconfiguration. Stateless address autoconfiguration (SLAAC) uses IPv6 prefixes from Router Advertisement (RA) messages; stateful autoconfiguration uses DHCPv6.

  • Managed-Config-Flag tells the end-host to use DHCPv6 exclusively;
  • Other-Config-Flag tells the end-host to use SLAAC to get IPv6 address and DHCPv6 to get other parameters (DNS server address, for example).
  • Absence of both flags tells the end-host to use only SLAAC.

One might assume that setting managed-config-flag in RA messages forces IPv6 hosts to use DHCPv6. Wrong, the two flags are just a polite suggestion.


Address types

Address Purpose
FF00::/8 Multicast
FF70::/12 Embedded RP
FE80::/10 Link Local Unicast
FF02::1:FF00:0000/104 Solicited node address
2000::/3 Global Unicast
2001::/32 Teredo
2001:DB8::/32 Documentation rezerved
2002::/16 Automatic 6to4
FC00::/7 Unique Local

Solicited node address

In addition, IPv6 multicast uses a solicited-node group that each router must join for all of its unicast and anycast addresses. The format for solicited-node multicast addresses is


Solicited-node addresses are built from this prefix concatenated with the low-order 24 bits (128 – 104 = 24) of the corresponding unicast or anycast address. For example, a unicast address of

has a corresponding solicited-node multicast address of


Multicast address

General multicast address format
Bits 8 4 4 112
Field prefix flags scope group ID


Multicast addresses in IPv6 always begin with FF as the first octet in the address, or FF00::/8. The second octet specifies the lifetime and scope of the multicast group. Lifetime can be permanent (0000) or temporary (0001). Scope can be local to any of the following:

  • Node – 0001
  • Link – 0010
  • Site – 0101
  • Organization – 1000
  • Global – 1110

EUI-64 Address Format

Ethernet hosts and Cisco routers with Ethernet interfaces use their 48-bit MAC addresses as a seed for EUI-64 addressing. But because the MAC address is 48 bits long and the EUI-64 process makes up the last 64 bits of an IPv6 address, the host needs to derive the other 16 bits from another source. The IEEE EUI-64 standard places the hex value FFFE into the center of the MAC address for this purpose. Finally, EUI-64 sets the universal/local bit, which is the 7th bit in the Interface ID field of the address, to indicate global scope.

Here is an example. Given the IPv6 prefix 2001:128:1F:633 and a MAC address of 00:07:85:80:71:B8, the resulting EUI-64 address is


ND Functions in IPv6

Message Type  Information Sought or Sent Source Address Destination Address  ICMP Type, Code 
Router Advertisement (RA) Routers advertise their presence and link prefixes, MTU, and hop limits Router’s link-local address FF02::1 for periodic broadcasts; address of querying host for responses to an RS 134, 0
Router Solicitation (RS) Hosts query for the presence of routers on the link. Address assigned to querying interface, if assigned, or :: if not assigned FF02::2 133, 0
Neighbor Solicitation (NS) Hosts query for other nodes’ link-layer addresses. Used for duplicate address detection and to verify neighbor reachability. Address assigned to querying interface, if assigned, or :: if not assigned Solicited-node multicast address or the target node’s address, if known 135, 0
Neighbor Advertisement (NA) Sent in response to NS messages and periodically to provide information to neighbors. Configured or automatically assigned address of originating interface Address of node requesting the NA or FF02::1 for periodic advertisements 136, 0
Redirect Sent by routers to inform nodes of better next-hop routers. Link-local address of originating node Source address of requesting node 137, 0


  • two groups: error reporting messages and informational messages
  • RFC mandates configurable rate limiting of ICMPv6 error messages (ipv6 icmp error-interval – default 100 ms + 10 token buckets)


To use stateful autoconfiguration, a host sends a DHCP request to one of two well-known IPv6 multicast addresses on UDP port 547:


    • FF02::1:2, all DHCP relay agents and servers
    • FF05::1:3, all DHCP servers


Name Location of Host  IP Address Space in Which Address Exists
Inside local Inside the network  Part of the enterprise IP address space – private IP
Inside global Inside the network  Part of the public IP address space
Outside local In the public Inet  Part of the enterprise IP address space – private IP
Outside global In the public Inet  Part of the public IP address space

These are key terms to help you understand static NAT:

  • NAT inside interface—The Layer 3 interface that faces the private network.
  •  NAT outside interface—The Layer 3 interface that faces the public network.
  •  Local address—Any address that appears on the inside (private) portion of the network.
  •  Global address—Any address that appears on the outside (public) portion of the network.
  •  Legitimate IP address—An address that is assigned by the Network Information Center (NIC) or service provider.
  •  Inside local address—The IP address assigned to a host on the inside network. This address does not need to be a legitimate IP address.
  •  Outside local address—The IP address of an outside host as it appears to the inside network. It does not have to be a legitimate address, because it is allocated from an address space that can be routed on the inside network.
  •  Inside global address—A legitimate IP address that represents one or more inside local IP addresses to the outside world.
  •  Outside global address—The IP address that the host owner assigns to a host on the outside network. The address is a legitimate address that is allocated from an address or network space that can be routed.


  • Homogeneous stack
  • Mixed stack
    • mixed hadrware
    • mixed software
    • mixed hard and soft

A switch stack is identified in the network by its bridge ID and, if it is operating as a Layer 3 device, its router MAC address. The bridge ID and router MAC address are determined by the MAC address of the stack master. Every stack member is identified by its own stack member number .
The system-level features supported on the stack master are supported on the entire switch stack.

Master election:

  1. current master
  2. highest stack member priority value (1-15; def 15)
  3. switch that is not using the default interface-level configuration
  4. switch with the higher priority feature set and software image combination
    1. IP services crypto
    2. IP services non crtypto
    3. IP base crypto
    4. IP Base non crypto
  5. Longest up-time.
  6. lowest MAC

A stack master retains its role unless one of these events occurs:

  • The switch stack is reset. 
  • The stack master is removed from the switch stack.
  • The stack master is reset or powered off.
  • The stack master fails.
  • The switch stack membership is increased by adding powered-on standalone switches or switch stacks.

Stack members that are powered on within the same 20-second time frame participate in the stack master election and have a chance to become the stack master. Stack members that are powered on after the 20-second time frame do not participate in this initial election and become stack members. All stack members participate in re-elections.


  • source
  • destination
  • protocol type
  • incoming interface
  • length


  • incoming – link level (ip policy route-map)
  • locally originated (ip local policy route-map)

set ip|ipv6 default next-hop|interface – attempts to route based on the routing table, and only if no match is found in the routing table, the packet will be handled by PBR

Point-to-Point Protocol & HDLC

The ISO standard for the much older HDLC does not include a Type field, so the Cisco HDLC implementation adds a Cisco-proprietary 2-byte Type field to support multiple protocols over an HDLC link.

PPP framing (RFC 1662) defines the use of a simple HDLC header and trailer for most parts
of the PPP framing. PPP simply adds the Protocol field and
optional Padding field to the original HDLC framing. (The Padding field allows PPP to
ensure that the frame has an even number of bytes.)


Feature HDLC PPP
Error detection? Yes Yes
Error recovery? No Yes
Standard Protocol Type field? No Yes
Default on IOS serial links? Yes No
Supports synchronous and asynchronous links? No Yes


  • RFC1661
  • includes an architected Protocol field
  • Link Control Protocol (LCP)
  • NCP for each L3 (IPCP, for example)

LCP features:

  • Link Quality Monitoring (LQM) (statistics about frames wo errors. if the percentage falls under configured value – frop the link). (ppp quality if command)
  • Looped link detection (send random magic number. if receive own number – drop the link)
  • Layer 2 load balancing (ML-PPP fragments the packet and sends the packet to each link. add header of 2 or 4 bytes for reassembly (sequence number and Flag bits designating the beginning and ending fragments)
  • Auth (pap, chap)


  • authenticated—Use the peer authenticated name as the bundle name. This option cannot support multiple clients using the same authentication username. (default option)
  • endpoint—Use the peer endpoint discriminator as the bundle name.
  • both—Use the peer authenticated name and endpoint discriminator as the bundle name.

Link Fragmentation and Interleaving (LFI): prevent small, delay-sensitive packets from having to wait on longer, delay-insensitive packets to be completely serialized out an interface. LFI tools fragment larger packets, and then send the delay-sensitive packet after just a portion of the original, longer packet.


  • ppp multilink interleave
  • ppp multilink fragment-delay x : size = x * bandwidth; Note that the unit for the delay parameter is  milliseconds, so the units for the interface bandwidth must also be converted. Eg.:
    bandwidth 256
    ppp multilink fragment-delay 10
    The fragment delay is set to 10 ms, so the fragments will be of size (256,000 * 0.01) = 2560 bits = 320 bytes.
  • ppp multilink multiclass the sequence number is maintained per class and so the interleaved small packets also would have the multilink header and so could be ordered correctly. Resolves out-of-order issues with LFI.

Compression: payload, TCP header and/or RTP header.
Payload: Cisco IOS software supplies three different payload compression options for PPP, namely Lempel-Ziv Stacker (LZS), Microsoft Point-to-Point Compression (MPPC), and Predictor. LZ uses more CPU and less memory in comparison to Predictor, and LZ typically results in a better compression ratio. Once compression is configured (matching compress command), PPP starts the Compression Control Protocol (CCP), which is another NCP, to perform the compression negotiations and manage the compression process.

Feature Stacker MPPC Predictor
Uses LZ algorithm Yes Yes No
Supported on HDLC Yes No No
Supported on PPP Yes Yes Yes
Supported on Frame Relay Yes No No
Supports ATM and ATM-to-Frame Relay Service Interworking (using MLP)? Yes Yes Yes

RTP header compression compresses the IP/UDP/RTP headers (40 bytes) into 2
or 4 bytes. With G.729 in use, RTP header compression reduces the required bandwidth by
more than 50 percent.
TCP header compression compresses the combined IP and TCP headers, a combined
40 bytes, into 3 or 5 bytes.
It does this by saving the state of TCP connections at both ends of a link, and only sending the differences in the header fields that change.
ip tcp headercompression [passive] and ip rtp header-compression [passive]: use IPCP to initiate compression (or wait if passive).
Alternative method using an MQC policy map to create classbased header compression.


  • Client sends username and password
  • Server sends authentication-ack (if credentials are OK) or authentication-nak (otherwise)
    Description 1 byte 1 byte 2 bytes 1 byte Variable 1 byte Variable
    Authentication-request Code = 1 ID Length Username length Username Password length Password
    Authentication-ack Code = 2 ID Length Message length Message
    Authentication-nak Code = 3 ID Length Message length Message

    PAP packet embedded in a PPP frame. The protocol field has a value of C023 (hex).

    Flag Address Control Protocol (C023 (hex)) Payload (table above) FCS Flag


  • After the completion of the link establishment phase, the authenticator sends a “challenge” message to the peer.
  • The peer responds with a value calculated using a one-way hash function on the challenge and the secret combined.
  • The authenticator checks the response against its own calculation of the expected hash value. If the values matches, the authenticator acknowledges the authentication; otherwise it should terminate the connection.
  • At random intervals the authenticator sends a new challenge to the peer and repeats steps 1 through 3.
    Description 1 byte 1 byte 2 bytes 1 byte Variable variable
    Challenge Code = 1 ID Length Challenge Length Challenge value Name
    Response Code = 2 ID Length Response Length Response value Name
    Success Code = 3 ID Length Message
    Failure Code = 4 ID Length Message

The Challenge packet has a Value field which contains a variable stream of octets (a random value). The Challenge packet also has a Name field which contains the hostname of the router transmitting the packet.

The “hash” that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:

  • A router’s Hostname
  • The configured PPP CHAP password
  • The PPP CHAP Challenge value

This generates a one-way hash value and set in the Value field of the Response packet which is sent back to the authenticator. The Name field of the Response packet is set to the hostname of the peer router.

CHAP packet embedded in a PPP frame. The protocol field has a value of C223 (hex).

Very nice explanation of interleaving:

Most voice codecs require a maximum delay of 10 ms between the different VoIP packets. Let’s say the serial link offers 128 Kbit of bandwidth…how long would it take to send a voice packet that is about 60 bytes?

60 bytes * 8 = 480 bits / 128.000 = 0.00375.

So it takes roughly 3.7 ms to send the voice packet which is far below the required 10 ms. We can run into issues however when we also send data packets over this link. Let’s say we have a 1500 bytes data packet that we want to send over this link:

1500 bytes * 8 = 12.000 / 128.000 = 0.093.

DHCP format

Table 1 BOOTP Request and Reply Format
Field Bytes Name Description
op 1 OpCode Identifies the packet as a request or reply. 1=BOOTREQUEST and 2=BOOTREPLY.
htype 1 Hardware Type Specifies the network hardware type.
hlen 1 Hardware Length Specifies the length hardware address length.
hops 1 Hops The client sets the value to zero and the value increments if the request is forwarded across a router.
xid 4 Transaction ID A random number that is chosen by the client. All DHCP messages exchanged for a given DHCP transaction use the ID (xid).
secs 2 Seconds Specifies number of seconds since the DHCP process started.
flags 2 Flags Indicates whether the message will be broadcast or unicast.
ciaddr 4 Client IP Address Used when the client is aware of the IP address as in the case of the Bound, Renew, or Rebinding states.
yiaddr 4 Your IP Address If the client IP address is, the DHCP server places the offered client IP address in this field.
siaddr 4 Server IP Address If the client knows the IP address of the DHCP server, this field is populated with the DHCP server address. Otherwise, it is used in DHCPOFFER and DHCPACK from the DHCP server.
giaddr 4 Router IP Address The gateway IP address, filled in by the DHCP/BootP Relay Agent.
chaddr 16 Client MAC Address The DHCP client MAC address.
sname 64 Server Name The optional server hostname.
File 128 Boot Filename The boot filename.
Options Variable Option Parameters The optional parameters that can be provided by the DHCP server. RFC 2132 lists all possible options.


Great article with header description:

The SNAP is an extension of the 802.2 LLC specified in the IEEE 802 Overview and Architecture document.[2] The 5-octet SNAP header follows the 802.2 LLC header if the destination SAP (DSAP) and the source SAP (SSAP) contain hexadecimal values of AA or AB:

802.2 LLC Header SNAP extension
DSAP SSAP Control OUI Protocol ID
1 octet 1 octet 1 or 2 octets 3 octets 2 octets

The SNAP header consists of a 3-octet IEEE Organizationally Unique Identifier (OUI) followed by a 2-octet protocol ID. If the OUI is hexadecimal 000000, the protocol ID is the Ethernet type (EtherType) field value for the protocol running on top of SNAP; if the OUI is an OUI for a particular organization, the protocol ID is a value assigned by that organization to the protocol running on top of SNAP.
SNAP is usually used with Unnumbered Information 802.2 protocol data units (PDUs), with a control field value of 3, and the LSAP values are usually hexadecimal AA, so the 802.2 LLC header for a SNAP packet is usually AA AA 03; however, SNAP can be used with other PDU types as well.
On Ethernet, the 8 octets occupied by the LLC and SNAP headers reduce the size of the available payload for protocols such as the Internet Protocol to 1492 bytes, compared to the use of the Ethernet II framing; therefore, for protocols that have EtherType values, packets are usually transmitted with Ethernet II headers rather than with LLC and SNAP headers. On other network types, the LLC and SNAP headers are required in order to multiplex different protocols on the link layer, as the MAC layer doesn’t itself have an EtherType field, so there’s no alternative framing that would have a larger available payload.

Spanning Tree

IEEE 802.D

  • Protocol ID: 0
  • Reserved multicast MAC address 0180.C200.0000 using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to 0x42
  • Ignore inferior PDUs until Max_Age-Message_Age
  • TCN originated out of root port. The designated bridge receives the TCN, acknowledges it, and generates another one for its own root port. Root will send config BPDU with TCN flag set for Forward_Delay+Max_Age. Switches reduce MAC address tables aging time to Forward_Delay once the receive configuration BPDU with TC bit set. Switch originating TCN will stop it once it receives TCN ACK from upstream bridge.

Hello: 2s
Max_Age: 20s (info age out)
Forward_Delay: 15s (listening/learning states)
Message_age: Incremented every time a BPDU traverses a switch (so it might be compared to the hop count).(start at 0)
2xForward_Time (direct link falure)
2xForward_Time + (Max_Age-Message_Age) (inderect failure or BPDU timeout)

UplinkFast: Upon link failure immediately activate ALT path. Dummy mcast with known MACs as source. Set bridge PRIO and link COST to high values not to become transit.
FlexLink: Active/standby pair (switchport backup command). mac address-table move {receive|transmit} and switchport backup interface x/y mmu.
BackboneFast: Explicitly verify inferior BPDU info. RLQ queries out of all candidate paths to the current root. Root floods a positive RLQ response out of ALL its designated ports. Saves Max_Age time.
LoopGuard: If BPDUs are not received on a non-designated port (root or alternate), and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state.


Cisco switch connects to an IEEE switch using a 802.1q trunk with default native VLAN (VLAN 1)

  • CST (Common Spanning Tree) is the spanning tree built by joining a single instance from PVST+ domain (VLAN 1 instance) with MST (Mono Spanning Tree) . the spanning tree of IEEE domain.
  • The PVST+ switch sends IEEE STP BPDUs corresponding to local VLAN 1 STP to IEEE MAC address as untagged frames across the link
  • Special new SSTP (shared spanning tree, synonym to PVST+) BPDUs are being sent to SSTP multicast MAC address 0100.0ccc.cccd also untagged. These SSTP BPDUs are encapsulated using IEEE 802.2 LLC SNAP header (SSAP=DSAP=”0xAA” and SNAP PID=”0x010B”). Special TLV with the source VLAN number. IEEE switches simply flood them through the respective VLAN topology. The reason for sending additional SSTP BPDUs across VLAN 1 is purely informational, to perform consistency checking. The idea is to inform all other potential Cisco switches attached to MST cloud about our native VLAN.
  • As for non-native VLANs (VLANs 2-4095) Cisco switch sends only SSTP BPDUs, tagged with respective VLAN number and destined to the SSTP MAC address.

Cisco switch connects to IEEE switch using 802.1q trunk with non-default native VLAN (e.g VLAN 100).

  • IEEE switch sends IEEE STP BPDUs to IEEE multicast MAC address and those BPDUs are processed by VLAN 1 (CST) STP instance in the Cisco switch.
  • PVST+ side (Cisco switch) sends untagged IEEE STP BPDUs corresponding to VLAN 1 (CST) STP to IEEE MAC address across the link.
  • At the same time, VLAN 1 BPDUs are replicated to SSTP multicast address, tagged with VLAN 1 number (to inform other Cisco switches that VLAN 1 is non-native on our switch).
  • Finally, BPDUs of the native VLAN instance (VLAN 100 in our case) are sent untagged using SSTP encapsulation and destination address.
  • As in Case 1 for the remaining non-native VLANs (VLANs 2-4095) Cisco switch sends SSTP BPDU only, tagged with respective VLAN tag and destined to the SSTP MAC address.

PVST+ is used on 802.1q trunks to tunnel PVST instances across an MST (mono spanning tree) cloud and build a CST consisting of PVST VLAN 1 and IEEE MST. PVST+ BPDUs contain special TLV with the source VLAN ID, which allows interconnected switches to detect inconsitencies or misconfigurations.


IEEE 802.1W -> IEEE 802.1D-2004 standard
Protocol ID: 2

  • Simplified port states (discard -> learn -> forwarding)
  • New port roles (backup; edge)
  • Sync process

TCN only generated when non-edge link becomes forwarding. TCN causes MAC table to flush (per vlan/instance).
spanning-tree portfast default; if BPDU received – remove edge status.

Link types:
– p2p (full duplex) – use sync
– shared (half duplex) – fall back to legacy

– elect local root port
– block all non-edge designated ports
– start sync on all designated ports

Hello’s == keepalives. This gives 6 second vs 20 second Max_Age of legacy.
Topology change:
Set tcWhile == Hello + 1s on all non-edge Designated and Root ports except of the one the TCN was received
Flush MAC learned on these ports
Send TCN on these ports every Hello seconds until tcWhile expires.


IEEE 802.1S -> IEEE 802.1Q-2005 standard
Protocol ID: 3
Based on RSTP (same sync process, etc).
Max 65 instances.

1. Region Name
2. Revision number(16 bit)
3. Vlan to instance mapping(hash)

  • IST BPDU using special M-Records (one for every active MSTI) which carry root prio, designated bridge prio, port prio, root path cost in TLV.
  • Timer can only be tuned for IST. Other instances inherit it.
  • MSTP does not use MaxAge timer. Special field in BPDU – Remaining Hops. Root send BPDU with hop count equal to MaxHops (configurable value).
  • If upstream switch sends superior info but receives BPDU with designated bit set it blocks the downstream port and declares it as STP Dispute link.

Intra region:

  • Details of region are known within region.
  • Manual vlan to instance mapping.
  • Undefind vlans fall to CIST (MSTI0)

Inter region:

  • Details between regions are not known.
  • Regions are treated as virtual bridges.
  • Simplified inter-region calculations: MSTIs are collapsed into CIST

Inter region operations:

  • CIST Root is the bridge that has the lowest Bridge ID among ALL regions. This could be a bridge inside a region or a boundary switch in a region.
  • CIST Regional Root is a boundary switch elected for every region based on the shortest external path cost to reach the CIST Root. Path cost is calculated based on costs of the links connecting the regions, excluding the internal regional paths. CIST Regional Root becomes the root of the IST for the given region as well. Provides Master Port.
  • The CST connects all boundary ports and perceives every region as a single virtual bridge with the Bridge ID equal to CIST Regional Root Bridge ID.
  • Every region builds IST instance using the internal path costs using CIST Regional Root as the IST Root
  • Switches do not send M-Records (MSTI information) out of boundary ports, only CIST information.
  • Since MSTIs in every region are independent, any change affecting MSTI in one region will not affect MSTIs in other regions. This is a direct result of the fact that M-Record information is not exchanged between the regions. However, the CIST recalculations affect every region and might be slow converging.


  • MST is backward compatible with 802.1D and 802.1W.
  • Behaves like inter-region MST.
  • CST Root must be within MSTP domain:
    • Either IST BPDU must be superior for all the VLANS
    • Either IST BPDU is inferior for VLAN 1 and identical or inferior of PVST+ BPDU from all other VLANs
  • MST-PVST+: replicate all IST BPDUs to PVST+ BPDUs for all active VLANs. VLAN 1 info in the opposite direction.


  • spanning tree guard root: recovers automatically if undesired BPDUs are not received MaxAge-MessageAge or 3xHello interval for RSTP
  • spanning tree bpdufilter default: applies on EdgePorts. 1 immediate BPDU and 10 more each hello interval are sent. If no BPDUs received – ceaase sending.
  • spanning tree bpdufilter enable: Interface command. Cease sending & receiving BPDUs unconditionally.
  • Global BPDU Guard supersedes Global BPDU filter. While port-level – vice verca
  • Bridge Assurance must be enabled on both sides. BPDUs as Hellos (even for blocking). BA-inconsistient blocking state.



  • Helper for STP
  • Special frames sent to well-known MAC address 01:00:0C:CC:CC:CC
  • If no echo frame with our ID has been seen from the peer for a certain amount of time, the port is suspected to be unidirectional.
  • In Normal mode, if the physical state of port (as reported by Layer 1) is still up, UDLD marks this port as Undetermined, but does NOT shut down or disable the port, which continues to operate under it’s current STP status.
  • If UDLD is set to Agressive mode, once the switch loses it’s neighbor it actively tries to re-establish the relationship by sending a UDLD frame 8 times every 1 second. If the neighbor does not respond after that, port is considered to be unidirectional and brought to Errdisable state.
  • UDLD Aggressive will only brings link to errdisable state when it detects Bidirectional to Unidirectional state transition. This prevents link from becoming errdisabled when you configure Aggressive mode just on one side. The UDLD state of such link will be Unknown

Private Vlans

  • Promiscuous (“P”) port: Usually connects to a router. This port type is allowed to send and receive L2 frames from any other port on the VLAN
  • Isolated (“I”) port: This type of port is only allowed to communicate with “P”-ports . i.e., they are “stub” port. You commonly see these ports connecting to hosts.
  • Community (“C”) port: Community ports are allowed to talk to their buddies, sharing the same community (group) and to .P.-ports.
  • The Primary VLAN delivers frames downstream from the router (promisc port) to all mapped hosts.
  • The Isolated VLAN transports frames from the stub hosts upstream to the router
  • The Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards “P”-ports.
  • Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding procedure within boundaries of primary/secondary VLANs.
Switch# configure terminal
 Switch(config)# vlan 20
 Switch(config-vlan)# private-vlan primary
 Switch(config-vlan)# exit
 Switch(config)# vlan 501
 Switch(config-vlan)# private-vlan isolated
 Switch(config-vlan)# exit
 Switch(config)# vlan 502
 Switch(config-vlan)# private-vlan community
 Switch(config-vlan)# exit
 Switch(config)# vlan 503
 Switch(config-vlan)# private-vlan community
 Switch(config-vlan)# exit
 Switch(config)# vlan 20
 Switch(config-vlan)# private-vlan association 501-503
 Switch(config-vlan)# end
 Switch(config)# show vlan private vlan
 Primary Secondary Type Ports
 ------- --------- ----------------- ------------------------------------------
 20 501 isolated
 20 502 community
 20 503 community
 20 504 non-operational
Switch# configure terminal
 Switch(config)# interface gigatibethernet0/22
 Switch(config-if)# switchport mode private-vlan host
 Switch(config-if)# switchport private-vlan host-association 20 501
 Switch(config-if)# end
Switch# configure terminal
 Switch(config)# interface gigatibethernet0/2
 Switch(config-if)# switchport mode private-vlan promiscuous
 Switch(config-if)# switchport private-vlan mapping 20 add 501-503
 Switch(config-if)# end


Member ports must have same values for:

  • Speed & duplex
  • trunking/access mode, DTP mode
  • same access VLAN
  • same trunk type, allowed & native vlans
  • same STP cost per VLAN
  • no SPAN configured

Switch shuts down all physical ports when no interface port-channel [n] to avoid loop.
spanning-tree etherchannel guard misconfig for the same purposes (BPDUs received via both ports).
PAGP: 8 links max; 01:00 :0c:cc:cc:cc
LACP: 16 links max, 8 active max, 8 standby; 01:80:C2:00:00:02
channel-protocol: interface command. refuse any modes keywords other than configured under this command



MCAST MAC: 0100.0ccc.cccc
Timers: 60 sec, 180 sec


MCAST MAC: 01:80:c2:00:00:0e, or 01:80:c2:00:00:03, or 01:80:c2:00:00:00
EtherType: 0x88CC
Timers: 30 sec, 120 sec
-Port description TLV
-System name TLV
-System description TLV
-System capabilities TLV
-Management address TLV