multicast mac...

the easiest way to remember the assignment of a multicast mac...

hit it wendell...


A 48-bit address that is calculated from a Layer 3 multicast address by
using 0x0100.5E as the multicast vendor code (OUI) for the first 24 bits, always binary 0 for the 25th bit, and copying the last 23 bits of the Layer 3 multicast address.

first 24 is always 0100.5e

always 0 for bit 25

then copy the last bits of the layer 3 multicast...

it never stops...

v6 anycast v. multicast...

 https://tools.ietf.org/html/rfc4291#page-13

  2.6.  Anycast Addresses


   An IPv6 anycast address is an address that is assigned to more than
   one interface (typically belonging to different nodes), with the
   property that a packet sent to an anycast address is routed to the
   "nearest" interface having that address, according to the routing
   protocols' measure of distance.

   Anycast addresses are allocated from the unicast address space, using
   any of the defined unicast address formats.  Thus, anycast addresses
   are syntactically indistinguishable from unicast addresses.  When a
   unicast address is assigned to more than one interface, thus turning
   it into an anycast address, the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address.

2.7.  Multicast Addresses


   An IPv6 multicast address is an identifier for a group of interfaces
   (typically on different nodes).  An interface may belong to any
   number of multicast groups.  Multicast addresses have the following
   format:

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

      binary 11111111 at the start of the address identifies the address
      as being a multicast address. 

quote(s) of the day... multicast...

from russ white,  eigrp for ip...

Multicast is more efficient than broadcast because the packets can be filtered by most network interface chips rather than being passed up to the IP layer to be sorted.

Updates and queries are sent as multicast packets, and the receiving router always acknowledges their receipt, using a unicast packet. 

How long will a router wait before starting the recovery mechanism? Each time it sends out a multicast packet that must be reliably delivered, an EIGRP process will wait until the RTO (retransmission timeout) period has passed before beginning a recovery action. This period is calculated from the SRTT (smooth round-trip time), which is calculated as the amount of time taken in the past for each peer on an interface to respond.

ipv6 m'cast...

mcast address         mcast group

FF01::1                           IPv6 nodes/node-local scope

FF01::2                           IPv6 routers/node-local scope

FF02::1                           IPv6 nodes/link-local scope

FF02::2                           IPv6 routers/link-local scope

FF02::5                           OSPFv3 router/link-local scope

FF02::6                           OSPFv3 designated routers/link-local scope

FF02::9                           RIPng routers/link-local scope

FF02::A                           EIGRP routers/link-local scope

FF02::D                           PIM routers/link-local scope

FF02::1:2                        DHCPv6 agents/link-local scope

FF05::2                           IPv6 routers/site-local scope

FF02::1:FF00:0/104          IPv6 solicited-node multicast address/link-local scope 

have you memorized them yet...

eigrp and multicasts...

given this frame switch scenario...

other than wireshark, the best way i've found to see the multicast traffic is using debug ip packet...

r2#
*Sep 14 05:55:11: IP: s=10.1.1.1 (Serial1/0), d=224.0.0.10, len 60, rcvd 0
*Sep 14 05:55:11: IP: s=10.1.1.1 (Serial1/0), d=224.0.0.10, len 60, input feature, packet consumed, MCI Check(85), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
r2#
*Sep 14 05:55:21: IP: s=10.1.1.3 (Serial1/0), d=224.0.0.10, len 60, rcvd 0
*Sep 14 05:55:21: IP: s=10.1.1.3 (Serial1/0), d=224.0.0.10, len 60, input feature, packet consumed, MCI Check(85), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

to make the hello's unicast, add the neighbor statement to both sides of a link...

in this case the unfortunate consequence is we lose r3, if it has not been statically added...

r2#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/2297856] via 10.1.1.1, 00:05:29, Serial1/0
r2#
*Sep 14 06:08:14: IP: s=10.1.1.1 (Serial1/0), d=10.1.1.2, len 60, rcvd 0
*Sep 14 06:08:14: IP: s=10.1.1.1 (Serial1/0), d=10.1.1.2, len 60, input feature, packet consumed, MCI Check(85), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
r2#
*Sep 14 06:08:19: IP: s=10.1.1.2 (local), d=10.1.1.1 (Serial1/0), len 60, sending
*Sep 14 06:08:19: IP: s=10.1.1.2 (local), d=10.1.1.1 (Serial1/0), len 60, sending full packet
r2#
*Sep 14 06:08:22: IP: s=10.1.1.3 (Serial1/0), d=224.0.0.10, len 60, rcvd 0
*Sep 14 06:08:22: IP: s=10.1.1.3 (Serial1/0), d=224.0.0.10, len 60, input feature, packet consumed, MCI Check(85), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

note the unicasts bewteen r1 and r2, and yet multicasts from r3, but no r3 route...

it's a different landscape...

the route table is restored when all ip's are referenced as neighbors...

r2#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/2297856] via 10.1.1.1, 00:19:15, Serial1/0
      3.0.0.0/24 is subnetted, 1 subnets
D        3.3.3.0 [90/2297856] via 10.1.1.3, 00:04:20, Serial1/0

and wireshark reports all neighbors unicast...

that requires a neighbor statement for every ip in the topology...

r3#sh run | beg router
router eigrp 1
 network 3.0.0.0
 network 10.0.0.0
 neighbor 10.1.1.2 Serial1/0
 neighbor 10.1.1.1 Serial1/0

and of course, wendell covers this in the ocg...

Caveat:  When Using EIGRP Static Neighbors IOS changes how it processes EIGRP packets on any interface referenced by an EIGRP neighbor command. Keeping in mind the design goal for this feature—to reduce multiasts

IOS disables all EIGRP multicast packet processing on an interface when an EIGRP neighbor command has been configured.

be very afraid...

multicast notes...

multicast notes

  DVMRP (distance vector mulitcast routing protocol)

     based on rip; generates a routing table with the multicast group it has knowledge of with corresponding distances between router and destination. uses reverse path flooding, sending a copy of a received packet out all interfaces except the one upon which it was received

PIM Dense Mode (PIM-DM) uses dense multicast routing. It implicitly builds shortest-path trees by flooding multicast traffic domain wide, and then pruning back branches of the tree where no receivers are present. PIM-DM is straightforward to implement but generally has poor scaling properties. The first multicast routing protocol, DVMRP used dense-mode multicast routing.^[1] See the PIM Internet Standard RFC 3973

PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage. See the PIM Internet Standard RFC 4601.

Of these, PIM-SM has the widest deployment.  PIM-SM is commonly used in IPTV systems for routing multicast streams between VLANs, Subnets or local area networks.

Why PIM-SM? For large networks with bandwidth constraints; also the flexibility that comes with source and destination multicasting occurring anywhere in the network. PIM-SM is considered the best choice for a new multicast implementation

Sparse mode

See rfc4601 http://www.rfc-editor.org/rfc/rfc4601.txt

Protocol Independent Multicast - Sparse-Mode (PIM-SM) is a protocol for efficiently routing Internet Protocol (IP) packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes (and their routers) will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group.

Multicast clients

A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members.

• In order to join a multicast group, G, a host conveys its membership information through the Internet Group Management Protocol (IGMP).
• The router then forwards data packets addressed to a multicast group G to only those interfaces on which explicit joins have been received.
• A Designated Router (DR) sends periodic Join/Prune messages toward a group-specific Rendezvous Point (RP) for each group for which it has active members.
• Note that one router will be automatically or statically designated as the rendezvous point (RP), and all routers must explicitly join through the RP.
• Each router along the path toward the RP builds a wild card (any-source) state for the group and sends Join/Prune messages on toward the RP.
• The term route entry is used to refer to the state maintained in a router to represent the distribution tree.
• A route entry may include such fields as:
• source address
• the group address
• the incoming interface from which packets are accepted
• the list of outgoing interfaces to which packets are sent
• timers, flag bits, etc.
• The wild card route entry's incoming interface points toward the RP
• The outgoing interfaces point to the neighboring downstream routers that have sent Join/Prune messages toward the RP as well as the directly connected hosts which have requested membership to group G.
• This state creates a shared, RP-centered, distribution tree that reaches all group members.

Multicast sources

• When a data source first sends to a group, its Designated Router (DR) unicasts Register messages to the Rendezvous Point (RP) with the source's data packets encapsulated within.
• If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel un-encapsulated to the RP.
• Whether they arrive encapsulated or natively, the RP forwards the source's de-capsulated data packets down the RP-centered distribution tree toward group members.
• If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off the shared RP-centered tree.
• For low data rate sources, neither the RP, nor last-hop routers need join a source-specific shortest path tree and data packets can be delivered via the shared RP-tree.

Once the other routers which need to receive those group packets have subscribed, the RP will unsubscribe to that multicast group, unless it also needs to forward packets to another router or node. Additionally, the routers will use reverse-path forwarding to ensure that there are no loops for packet forwarding among routers that wish to receive multicast packets.

Deployment

To support IP multicast, the sending and receiving nodes, intermediate routers and the network infrastructure between them must be multicast-enabled. In deploying IP multicast as an end-to-end solution, you will need to consider the following four areas:

Addressing

You must have an IP multicast address to communicate with a group of receivers rather than a single receiver, and you must have a mechanism for mapping this address onto MAC layer multicast addresses where they exist. End node hosts must have network interface cards (NICs) that efficiently filter for LAN data link layer addresses which are mapped back to the network layer IP multicast addresses. IP address space is divided into four sections-Classes A, B, C and D. The first three classes are used for unicast traffic. Class D addresses are reserved for multicast traffic and are allocated dynamically. (See IP Group Addressing below.)

Dynamic Host Registration

The end node host must have software supporting Internet Group Management Protocol (IGMP-defined in RFC 2236) to communicate requests to join a multicast group and receive multicast traffic. IGMP specifies how the host should inform the network that it is a member of a particular multicast group.

Multicast Routing

The network must be able to build packet distribution trees that allow sources to send packets to all receivers. These trees ensure that only one copy of a packet exists on any given network. There are several standards for routing IP multicast traffic. The Cisco-recommended solution is Protocol Independent Multicast (PIM), a multicast protocol that can be used with all unicast IP routing protocols.

Multicast Applications

End node hosts must have IP multicast application software such as video conferencing and must be able to support IP multicast transmission and reception in the TCP/IP protocol stack.