RIP

RIP

• UDP port 520 is used for transport.
• RIPv2 uses 224.0.0.9 for multicast
• Update interval is 30 seconds.
• RIP v2 allows RIP to tag routes as they are distributed into RIP.
• Next Hop fields: supports the assignment of a next hop IP address for a route.
• RIP adds 1 to the route before sending the update. So if it has a route of 2, when it updates other router, it advertises the hop count as 3.
• “ip maximum-paths” command under router rip to change default. 4 equal-metric routes
• Split Horizon: instead of advertising all routes a particular interface, RIP omits the routes whose outgoing interface filed matches the interface out which the update would be sent. It’s on by default except for cases in which FR is configured with the IP address on a physical interface.
• Route Poisoning and Poison Reverse: route poisoning is when a hop count of 16 is advertised and Poison reverse is advertising 16 but in reaction to an update received on that same interface.
• Holddown and invalid timer: 180 seconds, Flush Timer: 240 seconds.
• RIP has triggered updates and can converge to an alternate route in typically less than a minute.
• Passive Interface: in router rip, use passive-interface <type> <number>
• clear ip route * command bypasses loop prevention features so it can be risky.
• network command must have classful network as the parameter
  • Sending RIP updates: can be disabled by passive interface
  • Listening to RIP updates: can be filtered (incoming routes) using distribute list
  • advertising the connected subnet: filter outbound advertisements on other interfaces using distribute lists.
• on multicaccess networks, you can use neighbor ip-address RIP subcommand.
• to filter routes, use distribute list, can use ACL or prefix-list. If no interface specified, applied to all routes coming in!

IP Forwarding

IP Forwarding:

• before creating a new frame, the router updates the IP header TTL filed requiring a recomputation of the IP header checksum.
• Frame Relay Inverse Arp:
  • With InArp, routers already know the DLCI and need to learn the corresponding IP address.
  • unlike LAN, packet does not need to arrive at the router to trigger the InARP protocol; instead an LMI status message triggers InARP.
  • After receiving an LMI PVC Up message, each router announces its own IP address over the VC. If you disable LMI message, InARP does not work cuz nothing triggers it.
  • when “dynamic” keyword is uses in “show frame-relay map”, it means learnt by InARP (the ip address). For P2P interfaces, entry does not use InARP and you would not see any L3 address or “dynamic” keyword in the output.
  • point to point interfaces “ignore” the received InARP information.
  • “broadcast” keyword says to send copies of broadcasts over the VC.
  • on multipoint or physical spoke:“frame-relay map ip <ipaddresswannareach> <dlci_of_hub> broadcast”
  • formula for Full Mesh links: N (N – 1) / 2, with N equaling the number of host
  • Disabling InARP:
    • no frame-relay inverse-arp (can be disabled for all VCs, or all VCs for a particular L3 protocol and even for a particular L3 protocol per DLCI.). Tells router to ignore received InARP messages. e.g “no frame-re inverse-arp ip 400”
• Classless Routing: when default route exists and no specific match is made, the default route is used
• Classful Routing: when default route exists AND the class A,B or C network for the IP address does not exist, default route is used. Otherwise router discards the packet.
• MLS:
  • When do you not need a VLAN interface? when MLS switch connects to a router using a cable from a switch interface to a routers LAN interface, and the only two devices are the router and the one physical port on the MLS switch, you can use “routed switch port”.
  • VLAN interface: vlan must exist. Otherwise shows as “up and down”. VLAN interface uses L2 logic and L2 MAC address table. “ip routing” global command must be configured.
• Policy Routing:
  • allows policy decisions other than destination IP address.
  • routemaps match on referring ACL (numbered or named IP ACL using the “match ip address” command) or based on packet length ( match length) command. Can set TOS and Precedence.

IP Services: Syslog, WCCP, ICMP

SYSLOG:

• uses UDP port 514
• use, logging <host> command and optionally, logging trap.
• default facility of local7
• e.g: “service timestamps log datetime localtime” à logging 192.168.1.100 à logging monitor informational.

WCCP:

· uses UDP port 2048

· upto 32 content engines can communicate with a single router using WCCPv1.

· The content engine with the LOWEST IP address is elected as the lead engine.

· WCCPv1, only ONE router can redirect traffic to a content engine or cluster of content engines. ONLY supports HTTP traffic (TCP port 80)

· WCCPv2, multiple routers and multiple content engines can be configured.

§ Supports TCP and UPD traffic other than port 80, including, FTP caching, FTP proxy, web caching for non 80 ports, real audio, video and telephony.

§ supports multicast.

§ provides MD5 security “ip wccp password password”

§ load distribution

§ transparent error handling.

§ default version is WCCPv2.

· Configuring

§ globally: ip wccp web-cache group-address <ip> password Cisco

§ redirecting traffic out: ip wccp web-cache redirect out ß to content engine

§ inbound traffic on interface is excluded from redirection: ip wccp redirect exclude in

ICMP:

· Echo Request: sent by a ping from the host to test node reachability

· Echo Reply: Indicates the node can be reached successfully.

· Redirect: sent by the router to the source host to stimulate more efficient routing

· Time Exceeded: sent by the router if an IP packet’s TTL filed reaches zero.

IP Services: NTP, SNMP

NTP:

• NTP server: (global) ntp master 7 ß stratum 7
• NTP symmetric active mode: router/switch mutually synchronizes with another NTP host, configured with ntp peer command. (global) ntp peer 10.1.1.1
• NTP broadcast client: Listens to NTP broadcasts on the Ethernet. (int) ntp broadcast client
• NTP client: configures, “ntp server 10.1.1.1”
• Authentication on NTP:
  • ntp authentication-key 1 md5 <name>
  • ntp authenticate
  • ntp trusted-key 1
• under interface configure “ntp broadcast” (broadcast the time)
• show ntp associations

SNMP

• SNMPv1: simple authentication with communities, used MIB-I
• SNMPv2: removed requirement for communities, added GetBulk and inform messages, MIB-II
• SNMPv2c: only difference, allowed SNMPv1 style communities with SNMPv2
• SNMPv3: better security, backward compatibility to communities.
• communities: read-only, read-write, trap.
• Inform requests are acknowledged with an SNMP response packet.
• Messages:
  • Response: responds to information in Get and Set requests.
  • Inform: A message used b/w SNMP managers to allow MIB data to be exchanged about agents they both manage.
• MIBS:
  • RMON is outside MIB-II
• SNMPv3 adds authentication and encryption. MD5 and SHA creates a message digest for each protocol message (authentication) and DES to encrypt messages providing encryption (privacy).
• SNMP embedded event manager
  • automatic recovery actions are performed without need to fully reboot the routing device
  • allows event management capability directly inside the Cisco IOS devices.
  • action snmp-trap enables the traps event-manager command, also requires snmp-server configuration.
  • two types of EEM policy: applets and script
  • E.g: event manager applet IOSWD_Sample1
    • event ioswdsysmon sub1 cpu-proc taskname “task 1” op ge val 25 period 10 (triggers an applet when avg cpu usage is greater than or equat to 25% for 10 seconds. )
    • action 1.0 syslog msg “IOSWD_Sample1 Policy Triggered” (generates syslog notification)

IP Services: ARP, RARP, DHCP, BOOTP

ARP and Proxy Arp:

• method to learn another hosts MAC address
• all 0’s in des MAC
• ARP protocol type: 0x0806
• Proxy Arp: if a router can route packet to the target host in another subnet, router uses proxy ARP on behalf of the target.

RARP, BOOTP and DHCP

• main function: how host can discover it’s own IP address plus other details
• RARP: same old ARP message but uses it’s own MAC address as TARGET and IP address of 0.0.0.0. RARP server must be on the same subnet as the client.
• BOOTP: commands are encapsulated in an IP and UDP header. Router can forward the BOOTP packets to other subnets. Also allows assignment of: subnet mask, default gateway, DNS address and IP address of a boot server. STILL REQUIRES CONFIGURATION LIKE RARP.
• DHCP: Router would change the clients DHCP request from a source and destination of 255.255.255.255 to a source of directed broadcast of clients subnet (e.g 10.1.1.255) and destination of DHCP server. DHCP response would be forwarded to destination 10.1.1.255.
  • Only configuration command: ip helper-address <dhcpserverIP> on the inside router interface (client side).
  • DHCP pool includes keys such as: subnet, default gateway, length of lease time, dns domain name.
  • you can use (global) ip dhcp excluded-address command to exclude IP hosts. (global configuration)

Chapter 17: IP Multicast Routing

Chapter 17: IP Multicast Routing

• Mcast using Dense Mode
  • instructs the router to forward the multicast traffic on all the configured interfaces, except not forwarding out the interface on which it was received.
  • DM protocols assume that all subnets need to receive a copy of the packets. But they do not want to receive multicast packets for a particular group if: 1) the router does not have any active downstream routers that needs packets for that group, 2) the router does not know of any hosts on directly connected subnets that have joined that group.
  • when these conditions are true, router sends a “prune” message to the upstream router.
  • DVMRP, PIM-DM and MOSPF are dense-mode routing protocols.
• RPF check
  • use RPF check to prevent loops. Rule: “Look at the source IP address of the multicast packet. If my route that matches the source, lists an outgoing interface that is the actual interface on which the packet was received, the packet passes the RPF check. If not, do not replicate and forward the packet.”
  • Mcast router does not forward any mcast packets unless the packet passes the RPF check.
  • uses shortest path.
  • how different Mcast protocols determine their RPF interfaces
    • DVMRP: maintains separate mcast routing table and uses it for RPF check
    • PIM and CBT: use unicast table for RPF check
    • Multicast OSPF does not use RPF check cuz it computes both forward and reverse shortest-path source-rooted trees by using Dijkstra
• Mcast using Parse Mode
  • e.g. PIM-SM
  • by default, DM protocols keep forwarding the group traffic unless a downstream router sends a message stating that it does not want that traffic. Sparse-mode protocols do not forward the group traffic to any other routers unless it receives a message from that router requesting copies of packets sent to a particular mcast group. Downstream router requests only when: 1) router received request for packets from downstream router or 2) a host on a directly connected subnet has sent an IGMP join message.
  • PIM-SM begins with packet being forwarded to a special router, RP.
  • all routers configure the RP ip statically.
  • usually loopback IP is used as the RP’s IP address (and advertised via IGPs)
  • critical for all routers to somehow learn the IP address of an RP.
  • RPF check performed by using the IP address of the RP rather than the IP of the source packet.
• Multicast Scoping
  • TTL Scoping
    • routers compare the TTL value on a multicast packet with a configured TTL value on each outgoing interface.
    • router forwards the mcast packet only on those interfaces whose configured TTL is less than or equal to ttl value in the mcast packet. E.g: ttl is 17 in mcast packet and interface ttl is 0 and 32. It will go out 0 but not 32. By default, Cisco interfaces are configured as 0 ttl.
  • Administrative scoping
    • IP addresses 239.0.0.0 to 239.255.255.255, admin scoped mcast. Sets admin boundaries to limit forwarding of mcast traffic. You can configure and apply a filter on a router’s interface so that multicast traffic with group addresses in private address range is not allowed to enter or exit the interface.
• Dense-Mode Routing protocols
  • PIMv2 sends hello messages every 30 seconds on every interface on which PIM is configured.
  • PIMv2 Hellos use IP protocol # 103 and reserved Mcast destination address, 224.0.0.13 (ALL-PIM-Routers)
  • holdtime = 3xhello
  • establishing adjacency is very important for PIM.
  • Source Based Distribution Trees:
    • also called Shortest Path Tree (SPT) or simply a source tree.
    • the tree defines a path b/w the source host that originates the multicast packets and all subnets that need to receive a copy of the multicasts sent by that host.
    • configuration:
      • ip multicast-routing
      • (int) ip pim dense-mode (on all interfaces)
    • in the sh ip mroute command:
    • (S,G) refers to a particular SPT or to an individual routers’ part of a particular SPT. Where S is the source’s IP address and G is the group Multicast Address.
    • The C flag indicates that R3 has a directly connected group member for G and T flag indicates that the (S,G) traffic is forwarded SPT. Everytime R3 forwards a packet using (S,G) entry, the timer resets to 3 minutes.
    • the PIM-DM will continue to forward traffic until it is PRUNED.
  • Prune Message:
    • The PIM prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
    • So if in sh ip mroute, it shows S0/1 as pruned, it means Router won’t forward traffic for G (226.1.1.1) on its s0/1 interface.
    • in PIM-DM, when a router receives a Prune message on an interface, it starts a default 3-minute Prune timer, counting down to 0. If the downstream router still does not want the traffic, it can send a prune message again. This allows downstream router to know the (S,G) traffic is available from the other router.
    • The only interface in which a router will receive and process multicast packets from a particular source is the RPF interface.
    • Rules for Pruning: 2 key rules PIM-DM router must follow to decide when it can request a prune.
      • 1) when receiving packets on a non-RPF interface
      • 2) when a router realizes that both of the following are true: 1) no locally connected hosts in a particular group are listening for packets 2) no downstream routers are listening for the group.
      • P (Prune flag) which means that the router has completely pruned itself from that particular (S,G) SPT.
      • combination of C flag and RPF neighbor 0.0.0.0 indicates that the connected device is the SOURCE of the group.
      • in reality, there is not separate Prune message and Join message; PIM-DM and PIM-SM use a single message called Join/Prune message. Prune message, G in prune filed and join message, G in join field.
    • PIM-DM reacting to a failed link
      • RD changed its S0/1 interface to forwarding state because of a PIM Graft messages sent by downstream router.
  • Steady state operation and the State Refresh Message
    • when Cisco created PIMv2, created a feature called “State refresh”. Prevents inefficient method of PIMv1 of pruning and automatically unpruning.
    • The PM state refresh message can be sent just before neighbor’s prune timer expires.
  • Graft Message
    • to allow routers to “unprune” a previously pruned interface from an SPT, PIM-DM includes the GRAFT Message, which puts the upstream router to put the link back into a forwarding state.
• LAN specific issues with PIM-DM and PIM-SM
  • Prune override: in multi-access networks, when one router sends a prune message doesn’t mean other routers also want to get pruned. Upstream router sets a 3 minute timer once it gets a prune message. The downstream router that doesn’t want to be pruned (it received prune message too on all PIM-Routers address, 224.0.0.13). So this router sends a Join message to upstream router so the upstream router does not remove the interface. This process is called prune override.
  • Assert Messages: PIM-DM message. Used to prevent wasted effort when more than one router attaches to the same LAN. Rather than sending multiple copies of each multicast packet onto the LAN, the PIM assert message allows the routers to negotiate. Assert picks a winner based on the routing protocol and metric used to find the route to reach the unicast address of the source.
    • Router advertising lowest AD used to learn the route wins
    • if tie, lowest advertised routing protocol metric
    • if tie, the router with the highest IP address on LAN wins.
  • Designated routers.
    • PIM hello message elect a DR on Multiaccess network.
    • A PIM (dm or sm) router with the HIGHEST IP address becomes a DR.
    • used mainly with IGMPv1 since it does not have a method to elect a querier. With IGMPv2, it can automatically select querier based on the “lowest” IP address. so PIM DR is not needed for that.
    • on a LAN, one router might win Assert process for a particular (S,G) SPT while another might become the IGMP querier (PIM DR or IGMPv2 querier). Winner of Assert is responsible for forwarding multicasts and winner for querier is responsible for managing the IGMP query messages on LAN.
• DVMRP:
  • similar to PIM-DM
  • DVMRP uses its own distance vector routing protocol that is similar to RIPv2. Sends route updates every 60 seconds and considers 32 hops as infinity.
  • uses Probe messages to find neighbors using All DVMRP routers group addres, 224.0.0.4
  • uses a truncated broadcast tree, similar to SPT with some links pruned
• MOSPF
  • uses group membership LSA, Type 6. It floods it throughout the originating router’s area.
  • SPT is calculated “on-demand”, when the first multicast packet for a group arrives.
  • after spf calculations, entries are made into each routers mcast forwarding table.
  • RPF check is not required.
  • Cisco IOS does not support MOSPF.
• Sparse Mode Routing Protocols. (PIM-SM)
  • assumes no hosts want to receive multicast packets until they ask (opp. to PIM-DM)
  • downstream routers must send PIM Join messages and must continually send Join messages to upstream router.
  • Similarity with PIM-DM:
    • Neighbor discovery using Hello
    • election of a DR on a multi-access network.
    • Prune overrides on Multiaccess networks.
    • Use of Assert messages to elect a designated forwarded on a multi-access network.
  • Sources sending packets to RP
    • 1) sources send the packets to a router called the RP
    • 2) the RP sends the mcast packets to all routers/hosts that have registered to receive packets for that group. This process uses a shared tree.
    • Configuration:
      • (config)ip multicast-routing
      • (int) ip pim sparse-mode (on all the interfaces)
      • (global)ip pim rp-address 10.1.10.3 (RP’s IP address on all the routers)
    • Process:
      • S1 sends the multicast to 228.8.8.8 for e.g.
      • R1 reacts by sending UNICAST PIM Register messages to the RP.
      • RP sends unicast Register-stop messages back to R1 because RP knows that it does not have any need to forward packets sent to 228.8.8.8 since no PIM-SM router has registered.
      • the encapsulated multicast packet (in the first register by R1) will be forwarded by RP had any senders been interested in receiving packets.
      • R1 starts a 1-minute registration suppression timer after it gets a “Register-Stop” form RP.
      • 5 seconds before the timer expires, R1 sends another Register message with the “Null-Register” bit flag set without any encapsulated multicast packets.
      • if the RP still does not have any host who want to receive multicasts, it sends a “Register-Stop” message to R1 again.
      • but if the RP now knows of one router/host, it does not give a response and then R1 (when it’s timer expires) again sends its multicast packets to RP encapsulated in PIM Register messages.
  • Joining the Shared Tree
    • shared tree is also called Root Path Tree (RPT).
    • RPT is a tree with RP as the root (defines over which links multicast should be sent)
    • one such tree exists for each mcast group that is currently active in the internetwork.
    • so once RP receives the mcast packet, RP uses the RPT for that mcast group (G) to determine where to forward these packets.
    • PIM-SM routers create the RPT by sending PIM Join messages toward the RP.
    • Steps:
      • Hosts wants to join G so it sends an IGMP Join to G.
      • Routers react to IGMP Join by sending a PIM Join toward the RP to become part of the shared tree (*, 228.8.8.8). Also puts the interface connected to the host in forwarding state for the RPT for group 228.8.8.8
      • R5 (intermediate router) receives the join so R5 puts that interface in a forwarding state for the shared tree (*,228.8.8.8) and sends a join to RP
      • RP puts its interface in forwarding state for the (*,228.8.8.8) shared tree
      • by the end, RP realizes at least one host needs multicast traffic and RPT for the group is formed with R3’s interface, R5’s interface and R4’s interface
      • (*,G) represents a single RPT.
      • so now RP de-encapsulates the Register message and forwards it. (second function of Register message – first was to inform RP that it has multicast traffic to send)
      • RP sends a PIM-SM Join (10.1.1.10, G) to Router connected to the source.
      • R1 starts forwarding the G traffic to RP. Now RP receives traffic on the SPT from the source.
      • R3 sends a unicast Register-stop message to R1, to stop sending encapsulated unicast Register messages.
      • Process uses the efficient SPT from the source to RP and the shared tree (*,228.8.8.8) from the RP to the subnets that need to receive the traffic.
      • Note: it would be possible for R1 to keep sending encapped frames to RP but the encap/de-encap process would consume a lot so the best choice is to make RP join the group specific tree for that (S,G) combination
    • Shared Distribution Tree
      • traffic from RP to hosts is called “shared distribution tree” also called root-path tree (RPT) because it’s rooted at the RP.
      • S flag indicates group is using “sparse-mode”.
      • RPF is chosen on how to get to the RP not the source in this case.
    • Steady state operation
      • PIM-SM routers must send PIM Join messages to keep receiving traffic otherwise they are put back to “pruned” state.
      • PIM-SM routers decide based on if they’re getting PIM Join or if local host responds to IGMP query message with IGMP Report.
      • the downstream routers need to keep sending PIM-SM Join messages every 60 seconds to upstream routers. The receiving router then resents the Prune timer to default 3 minutes.
      • Or Mcast router will send IGMP general query to its host every 60 or 125 seconds depending on the IGMP version.
  • Examining the RP’s Mcast routing table
    • the RP has joined the SPT for the source as well as being the root of the shared tree for the group. First entry by “S” flag, second entry by “T” flag. The incoming interface is Null for the first entry because RP is the root and RPF neighbor is listed as 0.0.0.0.
  • SPT switchover
    • PIM-SM design also allows any other PIM-SM router to build an SPT b/w the router and the source DR. This lets PIM-SM avoids inefficient path.
    • when should a router move from RPT to SPT? “initiate the switch to SP-tree after receiving a significant number of data packets during a specified time interval from a particular source”. Cisco router by default switch from RPT to SPT after the first packet from the shared tree is received!!
    • you can change this by “ip pim spt-threshold rate” on any router on any group. Command only affects on the configured router.
    • Flags: SCJ for RP path and CJT for directly connecting to the source.
    • J: flag tells that the traffic was switched from RPT to SPT.
    • since the PIM-SM router has got a better path, it does not need traffic from RP, the downstream router can sends a PIM-SM Prune message to RP. This prune references (S,G) for SPT and means “stop forwarding packets from the listed IP address, to the listed group address, down the RPT). The downstream router sets a bit called RP-tree-bit which informs upstream routers that it has switched to SPT.
• Dynamically finding RPs and Using Redundant RPs
  • Methods to learn IP address of RP
    • statically configured on all routers: “ip pim rp-address address” in global config
    • Cisco Proprietary, Auto-RP to designate RP and advertise its IP so that all SM router can learn it automatically
      • two step process;
        • RP sends RP-Announce messages to reserved multicast (224.0.1.39) stating that router is a RP. Announce Message also allows RP to announce the mcast groups for which its an RP, allows some load-balancing of the RP workload among different routers. RP-Announce message is sent every 1 minute.
        • Second: one router is configured as a mapping agent. Could be the same router that is RP or different. Mapping agent learns all the RPs and the mcast groups they each support. Mapping agent multicasts another message, RP-Discovery, that identifies the RP for each range of multicast group addresses. This goes to 224.0.1.40. So mapping agent becomes part of the well-known Cisco-RP-Announce mcast group and listens for group traffic.
      • reason for Mapping agent: to support RP redundancy, basically to support multiple RPs that can act as RP for the same multicast group—the Auto-RP mapping agent decides which RP should be used to support each group at the moment. Mapping agent selects the router with the highest IP address as an RP for the group.
      • as soon as Cisco routers are configured for PIM-SM and Auto-RP, they automatically join the “well-know Cisco RP-Discovery (.40) multicast group”
      • creates a small problem. PIM-SM routers need to send a Join toward RP which they do not know! so Cisco created, “sparse dense mode”. Uses DM when it does not know the RP and SM when it knows the RP. So in normal mode with Auto-RP, routers would use dense mode long enough to learn the group-to-RP mappings from the mapping agent, and then switch over to sparse mode.
    • BootStrap Router (BSR) protocol can be used to designate the RP and advertise it’s IP address so that SM routers can understand IP automatically.
      • BSR: router acts similar to mapping agent in auto-rp. The BSR receives mapping info from the RPs, and then it advertises the info to other routers. But there are some differences:
        • BSR router does not pick the best RP for each group; it sends all group-to-RP mapping to the other PIM routers inside bootstrap messages.
        • PIM routers independently pick the currently best RP for each mcast group by running hash on bootstrap message.
        • BSR floods the mapping info on 224.0.0.13.
        • flooding of bootstrap messages does not require the routers to have a known RP or to support dense mode.
      • PIM-SM routers flood bootstrap messages out all non-rpf interfaces.
      • All PIM routers already know the unicast IP of the BSR based on the earlier receipt of bootstrap messages
      • the c-RP simply send unicast messages to BSR called c-RP Advertisements. It has Ip address and the group it supports.
  • Redundant RPs
    • Anycast RP using the Multicast Source Discovery Protocol (MSDP)
      • can use static RP configuration, Auto-RP or BSR
      • KEY: relates to how the redundant RPs are used.
        • without Anycast RP – RP redundancy allows only one router to be active RP for each mcast group.
        • with Anycast RP – RP redundancy and load sharing can be achieved with multiple RPs concurrently acting as the RP for the same group!!
      • each RP uses the same IP address. RP advertise this address (typically /32 prefix) with its IGP. Then other methods of learning (static, autorp…) direct packets to “the” RP per closest IGP routers.
      • both RPs are configured with same IP loopback address
      • Benefits:
        • multiple RPs share the load for a single mcast group
        • recovery after a failed RP happens quickly.
      • design creates a problem that must be overcome by MSDP.
      • problem: each individual RP builds its own shared tree, but any multicast source sends packets to one of the RPs.
      • Solution: RPs tell each other about all known sources by using MSDP. MSDP allows RPs to send messages to each other revealing the IP address of each source for each multicast group.
    • BootStart Router (BSR)
      • multiple BSR routers can be configured.
      • Each candidate BSR (c-BSR) sends bootstrap messages that include the priority of the BSR router and its IP address.
      • highest priority BSR wins and if tied, highest IP address BSR wins.
      • preferred BSR continues to send bootstrap messages, if the preferred BSR ceases, the redundant BSR take over.
  • Bidirectional PIM
    • last few processes of PIM-SM are changed
    • RP builds a shared tree with itself as the root.
    • when a source sends mcasts, the router receiving those mcasts does not use a PIM register message. Instead, it forwards the packet in the opposite direction of the shared tree, back up the tree toward the RP. Happens for all multicast packets from the source.
    • RP forwards the multicasts via the shared tree.
    • RP does not join the source tree for the source and the leaf routers do not join the SPT, either.
• Query messages IP protocol number is 2, Hello messages, IP protocol number is 103.
• Query messages sent to 224.0.0.2 for PIM and for PIM hello to 224.0.0.13
• default query and hello message interval is 30 second
• default hold time is 90 seconds.
• When using smaller allocation sizes for scopes, remember that Scope Relative Addressing reserves the upper 256 address of any scope range. The smallest block size that should be used is a /25 allocation because this provides a total of 512 addresses—256 assignable multicast addresses plus 256 reserved Scope Relative addresses.

Chapter 16: Intro to IP Multicast

Chapter 16: Introduction to IP Multicast

• All hosts that are connected to a LAN must use a standard method to calculate a L2 multicast address from the L3 multicast address and assign it to their NICs.
• IGMP provides communication b/w hosts and a router connected to the same subnet. CGMP = IGMP snooping helps switches learn which hosts have requested to receive the traffic for a specific multicast application. (switches learn which ports would like to receive Mcast traffic using CGMP)
• Some Multicast routing protocols (allows routers to forward multicast traffic from MCast servers to hosts. Distance Vector Multicast Routing Protocol (DVMRP), Multicast OSPF (MOSPF), and PIM-DM and PIM-SM.
• Multicast is UDP-based (unreliable). Some multicast protocol mechanisms occasionally generate duplicate packets and deliver packets out of order.
• The first 4 bits of the first octet for a class D address are always 1110.
• Range: 224.0.0.0 to 239.255.255.255 ( no need for masks), only one requirement, first 4 bits have to be 1110.
• Permanent multicast groups: 224.0.0.0 – 224.0.1.255
  • for non-routing purposes: 224.0.0.0 224.0.0.255 (e.g. 224.0.0.1 [all multicast capable hosts on a local network] and 224.0.0.3 [all multicast-capable routers on local network]). 224.0.0.4 (DVMRP routers)
  • for when packets need to be routed: 224.0.1.39 (RP announce) – 224.0.1.40 (RP discovery) (used by Auto-RP).
• Used with Source-Specific Multicast (SSM), 232.0.0.0 – 232.255.255.255
  • purpose of these applications, to allow a host to select a source for the multicast group. Helps make Mcast routing efficient, allows a host to select a better-quality source and helps network admins minimize DoS attacks. ONLY IGMPv3 capable hosts can use this feature.
• GLOP: 233.0.0.0 – 233.255.255.255
  • can be used by anyone who owns a registered ASN to create 256 global multicast addresses. Uses the value 233 in first octet and the ASN in the second and third octet. E.g: ASN 5663 would convert to: 0001011000011111. First eight bits equal to 22 and last 8 bits equal to 31, will become, 233.22.31.0 to 233.22.31.255
• Private: 239.0.0.0 – 239.255.255.255
• Multicast addresses for “transient” group: remaining multicast addresses are transient groups. Enterprise is expected to release this after use.
• Mapping IP Multicast addresses to MAC addresses:
  • e.g 228.10.24.5, replace the first 4 bits 1110 à 01-00-5E (first 6 hex of 12 hex)
  • replace next 5 bits of binary IP with 0 ALWAYS
  • 01-00-5E-0 (becomes now)
  • the last 23 bits of binary IP in the last 23 bit space of the multicast MAC address.
  • A-18-05
  • 0x01-00-5E-0A-18-05
  • possibility of duplicate addresses is there!!
• Three different tools, namely CGMP, IGMP snooping and RGMP allow switches to optimize their multicast forwarding logic by answering the question of which hosts to forward traffic to in a broadcast domain.
• IGMP:
  • IGMP messages are sent in IP datagrams with IP protocol number2, IP TTL set to 1.
  • IGMP packets pass only over a LAN and not forwarded by routers due to TTL.
  • 2 Goals: to inform mcast router that a host wants to receive packets from a specific group and to inform local multicast routers that a host wants to leave a mcast group.
  • IGMP, b/w hosts and router.
  • IGMP v2 packet:
    • Type (8 bit) has four message types: Membership query, version 1 membership report (for backward compatibility), Version 2 Membership report, Leave Group.
    • Max response time: default 100 (10 seconds) default. Allows for tuning response time for the Host Membership Report.
    • checksum
    • Group Address: set to 0.0.0.0 in general query and to group address in Group specific query.
  • REASONS for v2: better “Leave” mechanism to shorten the leave latency. Group-specific query messages permit router to send a query for a specific group instead of all groups. Provides MRT field. Querier election process: provides the method for selecting the preferred router for sending Query messages when multiple routers are connected to the same subnet.
    • IGMP v2 router sends IGMPv2 quey message every 125 seconds.
  • Multicast hosts must listen to the well-known 224.0.0.1 multicast group address to participate in IGMP and to receive mcast queries.
  • by setting the group address to be 0.0.0.0 the router is asking, “does anyone want to receive multicast traffic for any group?” Host responds with the IGMP report messages to inform Router.
  • Host sends, “solicited host membership report” and “unsolicited host membership report”
  • Multicast router only needs 1 report to forward traffic out its interface whether there are 1 or 200 users.
  • IGMPv2 uses, MRT timer to suppress many of the unnecessary IGMP reports. Timer is called “query response interval”. Report suppression is when a host receives a report sent by another host for the same mcast group for which it is planning to send a report, host does not send. 3 second MRT is expressed as 30. Hosts pick the MRT randomly b/w 0 and MRT timer.
  • IGMPv1 router takes 3 minutes to conclude that the last host on the subnet has left the group as opposed to IGMPv2 router, it takes only 3 seconds.!
  • IGMPv2 leave group and IGMPv2 Group-Specific query message work together.
  • Last Member Query Interval by default is the MRT which is 10 (1 second). The router sets the Last Member Query Count to 2. So the leave latency is less than 3 second usually.
  • IGMPv2 querier: when multiple routers are connected to a subnet. The router with the LOWEST IP address on the subnet is elected as the IGMP querier. “OTHER Querier Present Interval”. Default value is 255 seconds, because the default general IGMPv2 query interval is 125 seconds and default query response interval is 10 seconds.
  • IGMPv2 Host and IGMPv1 Routers: IGMP v2 hosts determines whether the router is v1 or v2 by the MRT fields of the periodic general IGMP query. IGMPv1 queries, this field is ZERO. IGMPv2 Host “version 1 router present timeout” timer is 400seconds.
  • IGMPv1 Host and IGMPv2 routers: determines by IGMPv1 report and figures it out. With one or more IGMPv1 hosts listening for a particular group, the router essentially suspends the optimizations that reduce leave latency. IGMPv1-host-present countdown timer = 180 in IGMPv1 and 260 seconds IGMPv2. (based on Group membership interval).
  • IGMPv3: allows a host to filter incoming traffic based on the source IP addresses from which it is willing to receive packets, through a feature called “Source-Specific Multicast” (SSM). It allows a host to indicate interest in receiving packets only from specific source addresses or from all but specific source addresses, sent to a particular multicast address.
  • destination address is 224.0.0.22 for IGMPv3 report. Message type is 0x22.
  • How does a host learn group source addresses? Cisco has designed URL Rendezvous Directory (URD) and IGMPv3 Lite to use the new features of IGMPv3 is fully available.
• LAN Multicast Optimizations
  • CGMP: L2 protocol, permits router to communicate L2 information it has learned from IGMP to switches.
  • only routers generate CGMP messages, switches listen. CGMP needs to be enabled on both ends of the router-switch connection over which CGMP is operating.
  • Destination Address on the CGMP messages is always well known MAC 0x0100.0cdd.dddd.
  • Important info in CGMP messages is: Group Destination Address (GDA) and Unicast Source Address (USA).
  • router sends a CGMP join message (every 60s) with GDA=0, and USA=it’s own mac.
  • when router receives a join request from a host, it sets the DA=well known mac, USA=host’s MAC, and GDA=group Mac. “A host with USA MAC of xx has requested multicast traffic for the GDA…., so map your CAM tables accordingly”
  • Leave: R1 sends GDA=group, and USA=0, to say that no host is interested.
  • “clear ip cgmp” command is entered at the router for clearing all CGMP entries on the switches, the router sends the “delete all groups”, CGMP leave message with gda and usa set to 0. When switches receive these messages, they delete all group entries from CAM tables.
• RGMP: is a l2 protocol that enables a router to communicate to a switch which multicast group traffic the router does and does not want to receive from the switch. Router can reduce its overhead this way.

CCIE Cert Guide — QoS Notes Part I

QOS:

• IP header has 1-byte fields called the TOS. It’s HIGH ORDER 3 bits are defined as IPP field.
• Diffserv renamed TOS byte to DS field and IPP was replaced with a 6 bit field called DSCP. The low order 2 bits of the DS filed were used for ECN.
• C&M tools makr DSCP and IPP because the IP packet remains intact as it is forwarded throughout the IP network.
• PHB: PER HOP BEHAVIOR
  • Class Selector PHB and DSCP Values
    • Class Selector (CS) PHBs provide backward compatibility with IPP.
    • Default is CS0 (most IOS will only allow default and not CS0)
    • CS PHB states that packets with larger DSCPs should be given better queuing preference.
  • Assured Forwarding PHB and DSCP Values
    • four classes for queuing purposes ALONG with 3 LEVELS of DROP probability in each queue.
    • AF PHB defines 12 DSCP values and their meanings. AFxy (where x is one of four queues and y implies one of three drop priorities.
    • First 3 bits imply queuing class and next 2 bits (3 and 4) imply drop preference.
    • To convert the AF name to decimal equivalent: AFxy foruma is: 8x + 2y = decimal value.
  • Expedited Forwarding PHB and DSCP Values
    • PHB actions:
      • queue EF packets so that they get scheduled quickly (low latency)
      • police the EF packets so that they do not consume all bandwidth.
      • EF value is 46, binary 101110
• Non-IP Header Marking Fields
  • Ethernet LAN CoS:
    • included 802.1q or ISL trunking header
    • 802.1q defines as 3 most significant bits of the 2-byte Tag Control field. Called “user priority” bits
    • ISL defines the 3 LEAST significant bits from 1 byte USER field, calling it CoS.
  • WAN marking Fields
    • Frames set to 1 are considered to be better candidates to be dropped than without set to 1.
    • Frame Relay: DE bit,
    • ATM: Cell Loss Priority (CLP) bit.
    • MPLS defines 3-bit fields called MPLS EXP.
  • Rules for non-IP markable fields:
    • Classification: ON INGRESS ONLY (COIN) and only if that interface supports that particular header field
    • Marking: MOEG – On EGRESS ONLY.
• M-QoS CLI
  • “Class Based” tools include: CB Marking, CB WFQ, CB Policing, CB shaping, CB Header Compression.
  • MQC separates the classification function of a QoS tool (class-map) from the action (PHB) that the QoS wants to perform (policy-map). 3 major commands:
    • CLASSIFICATION: class-map
      • uses “match command”.
      • match any matches any packet – any and all packets!
      • if packets don’t match either class 1 or class 2, those packets would not be marked and will retain their DSCP values.
      • upto four (cos and IPP) and eight (dscp) values can be listed on a “match cos”, “match precedence” or “match dscp” command.
      • if a class has multiple match, default is “MATCH-ALL (AND)”, but match-any can be (OR) can be defined on command.
      • to do an OR on the same command for qos values, e.g: “match dscp 0 1” == match dscp 0 OR match dscp 1.
    • MARKING: policy-map à multiple classes can be referenced under a single policy map.
    • service policy
• Marking
  • CB Marking requires CEF enabled.
  • CB marking is enabled for packets entering or exiting an interface
  • policy map is processed sequentially.
  • packets that do not explicitly match defined class are considered to match special class “class-default”.
  • for any class inside policy-map for which there is no set command, packets are not marked in that class.
  • some “sets”: set atm-clp, set fr-de, set qos-group gid, set ip dscp <dscp-value>
  • show policy-map <policy-map-name> {lists config info}
  • show policy-map <interface-spec> input | output [class] {lists statistics of policy-map}
  • load-interval interface subcommand: useful for QoS statistics. It defines the time interval over which IOS measures packet and bit rates on an interface. With lower load interval, stats change more quickly; default is 5 minutes, it can be lowered to 30 seconds.
  • if packets are matched by an earlier class statement in policy map, they won’t match the later ones.
  • on “native” vlan interfaces, policy-maps that refers to CoS cannot be enabled.
  • the “show ip nbar” command only displays statistics if the “ip nbar protocol-discovery” command is applied to an interface.
  • you can download new PDLMs from Cisco, copy it into flash memory and add the “ip nbar pdlm <name>” command.
  • packets should generally be marked as close to INGRESS point of packet as possible.
  • “Mark as close to ingress edge of the network as possible, but not so close the to the edge that the marking made is made by an untrusted device.”
  • Marking Using Policers:
    • Determines if configured traffic contract is exceeded! Has two components: traffic rate (bits per second) and burst size (# of bites)
    • if traffic within the contract, all packets are considered to have conformed to the contract, if exceeded, they have “exceeded” the contract.
    • marking down requires re-marking of QoS fields, typically IPP or DSCP values. E.g: policer marks AF11 to AF13 without discarding.
• QoS Pre-classification:
  • encapsulated traffic like IPSec, tunnel mode, GRE tunnels.. ToS byte of the original packet is automatically copied to the tunnel header BUT features like NBAR are broken.
  • QoS pre-classification works by keeping the original, unencrypted traffic in memory until the egress QoS action are taken.
  • You can enable in “tunnel interface configuration mod”(GRE and IPIP), “virtual-template configuration mode”(L2F and L2TP) or “crypto map config mode”(IPSec) by using “qos pre-classify”.
• Policy routing for Marking
  • allows capability to route packet based on information in packet beside the destination IP address. Uses “route-maps” to classify packets.
  • Policy routing can also mark the IPP field, or the entire ToS byte using the set command in a route-map.
  • Packets are examined as they enter an interface
  • traditional policy routing function of using set command to define the route may also be configured but nor required.
  • should only be used when CB marking is not available or when router has to use both policy routing and mark packets entering the SAME interface.