INE R&S ATC129 ~ ATC137 - QOS

QoS Agenda

• The Need for QoS
• QoS Models and Marking
• Queueing Technologies
• Shaping and Policing
• Frame-Relay Traffic Shaping
• 3560 Catalyst QoS

Theoretical Need for QoS

• Root Cause: Resource Contention
– Multiple flows sharing same link
• Same or multiple applications
• Each application has its own requirements
– Contention results in Queueing
• Packets may be delayed or dropped
• Effective flow throughput decreases
• Delay or Jitter exceed thresholds

Possible Solutions

• Best Solution: Avoid Contention
– Don’t over-provision
– Not always possible
• Next Best Solution: QoS
– Network congestion is controlled
– Delay/Loss/Jitter/Throughput are controlled
– Only alleviates temporarycongestion

QoS Models

• Defines contention management approach
• Two types
– Integrated Services
– Differentiated Services

Integrated Services QoS Model

• Integrated Services (IntServ)
– Every flow has an explicit reservation end-to-end
– Connection-oriented model
– Does not scale well
• Network must maintain too much state

Differentiated Services QoS Model

• Differentiated Services (DiffServ)
– Traffic is grouped into classes
• Classification process defined at network edge
• Classification can be encoded inside packet itself
– Known as packet’s marking
– QoS behavior is defined by traffic’s class
• Called Per-Hop Behavior (PHB)

QoS Marking

• Defines classification of the packet
• Different types of markings
– IPv4 & IPv6 ToSByte
• DSCP (6 bits)
• IP Precedence (3 bits)
– Layer 2 Markings
• Frame-Relay DE bit (1 bit)
• MPLS EXP bits (3 bits)
• 802.1q/ISL CoSbits (3 bits)

DSCP Default &EF PHBs

• Default
– Best Effort
– DSCP value 0 (000000)
• Expedited Forwarding (EF)
– Priority Traffic
– DSCP value 46 (101110)

DSCP AF PHB

• Assured Forwarding (AF)
– Bandwidth Guaranteed
– Four classes
• AFxywhere x= 1 –4
• Higher is more prefferred
– Three drop precedences
• AFxywhere y= 1 –3
• Higher means higher drop precedence
– DSCP value (xxxyy0)

DSCP CS PHB

• Class Selector (CS)
– Backwards compatible with IP Precedence
– Seven classes
• CSxwhere x= 1 –7
• Higher is more preferred

QoS Tools

• Used to Implement QoS Models
– Many tools rely on QoS marking
• Different Tools for
– Network Edge
– Network Core
• IntServ and DiffServ Models
– Same tools used for both

Queueing

• Queueing occurs when packets are delayed by router
• Could be Hierarchical
– PVC-Queue (Frame-Relay)
• Interface-Queue (Software Queue)
– Hardware-Queue (TX-Ring)
– Simplified in Ethernet switches
• Hardware queues only
• “Fancy” queueing methods apply to software queue
– How traffic is processed when waiting for TxR

MQC

• Modular Quality of Service Command Line Interface
– Allows multiple QoS methods per interface per direction
– “Legacy” QoS did not
• Previouslycalled CBWFQ
– Class Based Weighted Fair Queueing
• Now called HQF
– Hierarchical Queueing Framework
– As of IOS 12.4(20)T

MQC Configuration

• Define traffic classes
– class-map
– Define traffic match criteria
• Define traffic policy
– policy-map
– Define actions
• Apply policy
– service-policy [in/out]on interface

MQC Classification Options

• Match-Any vs. Match-All
• Access-Lists
• DSCP/IP Precedence
• NBAR
• Source Interface
• Source/Destination MAC address
• Can combine multiple matches in one class

MQC Classification Workflow

圖圖圖

MQC QoS Types

• Admission Control
– Policing
• Classification and Marking/Re-Marking
– Shaping
• Congestion Management & Avoidance
– Queueing Disciplines
• Link Optimization

FIFO Queueing

• Simplest and easiest to implement
– Only parameter is queue-depth
• Configuration
– Disable previous queueing strategy
• I.e. no fair-queue
– Define queue depth
• hold-queue out
• Typically used as part of other solutions
– E.g. CBWFQ/HQF

Fair Queueing

• Also known as max-minscheduling
• Services multiple requests for a shared resource
– Step 1: Share resource equally
– Step 2: Take excessive amounts
– Step 3: Share excess equally among unsatisfied requests

Weighted Fair Queueing

• Max-min scheduling, but not equal
– Allocate bandwidth per flow proportional to weight
• Flow is defined dynamically
– Src/DstIP + Src/DstPort + ToSByte
• Weight is IP Precedence + 1

Weighted Fair Queueing

• Configuration
– fair-queue <CDT> <QUEUES> <RSVP>
– hold-queue out <MAX BUFFERS>
• Congestive Discard Threshold (CDT)
– Individual queue size threshold
• If number of flows > number of queues…
– Flow collision occurs and queues are shared
• RSVP queues
– Resource Reservation Protocol (IntServ)

CBWFQ/HQF

• Allows defining of custom flows
– Class definition using MQC Syntax
– bandwidthkeyword defines class’s “weight”
• Bandwidth is shared proportionally to weight
–Relative sharing, not absolute reservation

CBWFQ/HQF

• Every Queue in HQF is FIFO
– Includes class-default
– Buffer-limit with queue-limitcommand
• Global buffer limit with hold-queue out
– Can be turned into Fair-Queue
• Command fair-queue <FLOWS>
• All flows are equal, no weighting
• Queue limit per flow is 1/4*queue-limit

CBWFQ/HQF

• Reservations
– Absolute with bandwidth [Kbps]
– Relative with bandwidth percent [%]
• Percent of interface “bandwidth” setting
– All bandwidths must sum to interface “bandwidth”
• Class-Default
– Always guaranteed at least 1% of interface BW
• max-reserved-bandwidthnow deprecated

LLQ in HQF

• Priority Queue
– Only one per HQF configuration
• Designated with priority [X]
• Always emptied first
– Optionally policed to XKbps only in times of congestion
• Congestion defined as having TX-Ring full
– Multiple classes can have priority
• Share single queue but could be policed differently

LLQ in HQF

• Remaining Bandwidth
– Commonly used with LLQ
– Bandwidth remaining after LLQ allocations
– Command bandwidth remaining X
– Calculated as Interface_BW-LLQ_BW

WRED

• Weighted Random Early Detection
– Enhancement of RED
• Congestion avoidance, not management
– Queue drop discipline, not queueing
• Drops packets randomly before queue is full
– Alternative to tail drop
• Prevents TCP synchronization problem

WRED

• WRED tracks average queue depth
– Smoothened based on weight factor
• avg=(old_avg*(1-1/2^n))+(q_size*1/2^n)
– Drops packets based on Mark Probability Denominator
• Probability = 1/Mark_Probability_Denominator
• Drop probability increases as queue depth increases
• If queue depth exceeds maximum, tail drop occurs
• Configuration
– random-detect exponential-weighting constant
– random-detect dscp<DSCP> <MIN> <MAX> <Mark>

Traffic Shaping

• Goal is to normalize traffic flow
– Smooth out traffic bursts
– Prepares traffic for ingress policing
– Delay and Queue exceeding traffic
• IOS Traffic Shaping
– Meters traffic against pre-defined rate
– Delays exceeding traffic only

Shaping Terminology

• Traffic Shaping Terminology
– Time Committed = Tc
• Time interval in msto emit traffic bursts
• Bursts always emitted at Access Rate (AR)
– Burst Committed = Bc
• Amount of bits that could be sent every Tc
– Burst Excessive = Be
• Amount of bits overBcthat could be sent during Tc
• Must be accumulated by idle periods

Shaping Formulas

• Single-Rate Shaper (sub-rate)
– AIR = interface (port) speed
– CIR = Bc/Tc= average speed (shaping rate)
– EIR = (AIR-CIR) = excessive rate (sporadic)
– Be= EIR*Tc= excessive burst
• May be prohibited by setting Be=0 (default)

MQC Generic Traffic Shaping

• Configured using MQC syntax
– shape average <CIR> [Bc] [Be]
– Tcis found implicitly as Bc/CIR
• Default shaper queue is FIFO
– Can be turned into HQF by associating a child policy-map with shaped class
• Specify HQF settings in the child policy-map
• E.g. nested policies

Traffic Policing

• Normally an ingress operation
– Meters a packet flow rate
– Marks packets that exceed metered rate
• Drop is also a mark action
• Policing has two parameters
– Metering rate –CIR
– Averaging interval –Tc

Traffic Policing

• The larger is Tcthe more bursting is allowed
– Bc= CIR*Tcis maximum burst size allowed momentarily (in bytes)
– Tcis not the same as in shaping
• Be–excessive burst
– Max amount of bytes allowed above Bcduring Tc
– Only allowed if Bcwas not fully utilized before

Shaping and Policing Together

• Operations are Complimentary
– Shaping is done egress
– Policing is done ingress
• Parameters should match
– Shaping is set to match policing
– Same CIR, Bcand Be
• Policing values could be greater actually

MQC Policing Syntax

• Configuration
– police [cir] [<CIR>] [<Bc>] [<Be>]
– CIR in bps while bursts are in bytes
• Applied to an MQC class
– Three actions (colors): conform, exceed, violate
– Exceed: flow exceeds Bcbut under Bc+Be
– Violate: burst size exceeds Bc+Be

Dual-Rate Policing

• Meters against two rates
– CIR and PIR with Bcand Bebursts
– Semantics for Bechanges
• Three actions:
– Conforms –under CIR
– Exceeds –between CIR and PIR
– Violates –above PIR

Dual-Rate Policing Syntax

• Configuration
– police cir[<CIR>] bc[<Bc>] pir[<PIR>] be [<Be>]
• Normally used to implement two-rate access
– Customer is guaranteed CIR
– Allowed to send up to PIR
– Traffic between PIR and CIR remarked
• E.g. lower DSCP

Frame-Relay Traffic Shaping

• Allows shaping at PVC level
– Responds to Frame-Relay BECN notifications
• Introduces Queue Hierarchy
– Per-VC + Per-Interface Queue
• Two main methods to shape Frame-Relay
– Legacy FRTS
– MQC FRTS

Legacy FRTS

• Enabled using the interface command
– frame-relay traffic-shaping
– Automatically forces CIR of 56Kbps to all PVCs
• PVC(s) rate(s) defined using map-class
– map-classis applied to DLCI/Subinterface
• frame-relay class (interface)
• class (frame-relay interface-dlci)

Legacy FRTS and HQF

• HQF Queueing defined in service-policy
– Maximum bandwidth = minCIR(CIR/2 by default)
• No shaping allowed in the service-policy
• Interface queue becomes dual-FIFO with FRTS
– Needed to implement fragmentation and interleaving

MQC FRTS

• Not compatible with legacy FRTS
– No frame-relay traffic shapinginterface command
• Still uses map-classto map FRTS settings to PVCs
• Shaping parameters defined in service-policy under map-class

RSVP

• Signals IntServflow reservations
– PATH messages flow downstream from source
– RESV messages flow upstream from destination
– Reservation contains
• Flow Spec
– Tspec(traffic spec, token bucket parameters: rate/burst)
– Rspec(Reservation spec, type of service)
• Filter Spec: Flow sources to reserve resources for

RSVP

• RSVP performs admission control
– Based on interface bandwidth and Tspec
– Configurable: ip rsvp bandwidth <X>
• Every installed flow has
– A policer associated with flow
– WFQ queue/weight dedicated to flow
• RSVP requires CBWFQ or WFQ

RSVP

• RSVP does not work with HQF
– Should be WFQ of CBWFQ with WFQ in class-default
• RSVP works with Per-VC queue
– Requires Legacy FRTS
– PVC queue must be WFQ/CBWFQ
– Configuration: ip rsvp resource-provider

RSVP Example

• Sender
– ip rsvp sender-host
• Receiver
– ip rsvp reservation-host
• Transit nodes
– ip rsvp bandwidth

Catalyst 3560 QoS

• Hardware Optimized
– Harder to verify
– Simplified functions
• Multi-stage process
– Ingress functions
– Egress functions
• Concept of internal QoS label

Catalyst 3560 QoS Workflow

Catalyst 3560 Classification
• Enabling MLS QoS will erase existing marking
– Disable using no mlsqosrewrite ip dscp
• Trusting Existing Marking
– mlsqostrust cos|dscp|ip-precedence
– Other markings modified according to mapping tables
• mlsqosmap

Catalyst 3560 Classification

• Marking packets explicitly
– MQC syntax via interface policy-maps
– Usesaccess-listand class-map
– Marking could be set using set dscpcommand
• For Non-IP packet CoSis automatically translated from DSCP
• Classification could be interface or VLAN-based

VLAN-Based Classification

• Enabled per-interface
– mls qos vlan-based
• QoS-Policy applied to SVI
– Affects all interfaces in VLAN
– Cannot be combined with physical interface policy
– Only marking (set action) allowed at first level

Ingress Policing

• Individual Policers
– Applied per-class per-port
– Configured via police <CIR> <Bc>
• Aggregate Policers
– Shared among classes
– Only apply to one physical interface
– Configured via mlsqosaggregate-policer

Ingress Remarking

• Policing normally does not change DSCP
• Policing Action
– policed-dscp-transmit
– Normally an “exceed” action
• Remarks packet if flow exceeds CIR
– Uses table mlsqosmap policed-dscp
– Remarked DSCP used for queue selection

Egress Queueing

• There are four egress queues per port
– SRR is the queueing discipline
• Packets are mapped to queues based on QoS label (DSCP/CoS)
– Trusted or enforced value
– Maps to queue-id and drop threshold
• Weighted Tail Drop is the drop policy

SRR Queueing

• Shaped Round Robin
– Modification of WRR
– Allows for weighted bandwidth allocation
– Supports individual queue shaping
– Supports port shaping
• Shaping delays packets in SRR queues
– Achieves target flow/port speed

SRR Queueing

• Each queue is either…
– Shared
• Shares available bandwidth
• Every queue has relative weight
– Shaped
• Guarantees bandwidth and shapes it
• Every queue has absolute weight
• Allocated BW subtracted from available bandwidth
• Shaping settings override sharing settings

SRR Queueing

• srr-queue bandwidth limit <%>
– set port speed limit in percents of physical speed
• srr-queue bandwidth share x1 x2 x3 x4
– shares interface bandwidth (after limiting)
– share proportions x1:x2:x3:x4
• srr-queue bandwidth shape x1 x2 x3 x4
– Shapes queue to 1/xof port physical speed
– Guarantees this amount of bandwidth to queue

Priority Queue in SRR

• Queue 1 can be enabled as PQ
• Configuration via priority-queue out
– All SRR weights have no effect on this queue
• PQ is not limited in any way
– May starve other queues on the port
• Ensure you map only voice bearer to this queue

SRR Configuration

interface FastEthernet0/13
  speed 10
  srr-queue bandwidth shape 10 0 0 0
  srr-queue bandwidth share 1 20 20 20
  srr-queue bandwidth limit 20

Mapping packets to SRR

• Default mapping tables
– DSCP to Queue-Id/Drop Threshold
• mls qos srr-queue output dscp-map
– CoSto Queue-Id/Drop Threshold
• mls qos srr-queue output cos-map
• CoSused for non-IP packets
• DSCP used for IP/IPv6 packets

WB1 9.31 ISATAP Tunneling

9.31 ISATAP Tunneling

• Remove the 6to4 tunnels connecting R3, R4, and R5.
• Using their Loopback 0 IPv4 addresses connect  R3, R4, and R5 R1, SW1, and SW2 via
ISATAP tunnels.
• Use the /64 IPv6 prefix 2001:1:0:345::/64 to allocate IPv6 addresses to the
tunnel endpoints.
• Create additional IPv6 Loopback interfaces on all three routers with the
IPv6 addresses 2001:1:0:Y::Y/64, and use static routing to obtain full
connectivity.

------------------

R3:
no interface Tunnel345
!
interface Tunnel345
ipv6 address 2001:1:0:345::/64 eui-64
tunnel source Loopback0
tunnel mode ipv6ip isatap
!
interface Loopback100
ipv6 address 2001:1:0:3::3/64
!
ipv6 route 2001:1:0:4::/64 2001:1:0:345:0:5efe:9601:404
ipv6 route 2001:1:0:5::/64 2001:1:0:345:0:5efe:9601:505

R4:
no interface Tunnel345
!
interface Tunnel345
ipv6 address 2001:1:0:345::/64 eui-64
tunnel source Loopback0
tunnel mode ipv6ip isatap
!
interface Loopback100
ipv6 address 2001:1:0:4::4/64
!
ipv6 route 2001:1:0:3::/64 2001:1:0:345:0:5efe:9601:303
ipv6 route 2001:1:0:5::/64 2001:1:0:345:0:5efe:9601:505

R5:
no interface Tunnel345
!
interface Tunnel345
ipv6 address 2001:1:0:345::/64 eui-64
tunnel source Loopback0
tunnel mode ipv6ip isatap
!
interface Loopback100
ipv6 address 2001:1:0:5::5/64
!
ipv6 route 2001:1:0:4::/64 2001:1:0:345:0:5efe:9601:404
ipv6 route 2001:1:0:3::/64 2001:1:0:345:0:5efe:9601:303

--------------------

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is a technology that
contrasts 6to4 automatic tunnels. While 6to4 automatically generates a /48 prefix
out of an IPv4 address, ISATAP uses the IPv4 domain as a “multi-access” media
with IPv4 addresses being the rough equivalent of Ethernet MAC addresses.

Specifically, ISATAP constructs the interface identifier (last 64 bits) of the IPv6
address based on the IPv4 address of a host using the EUI-64 rules. Thus, given
that you already have a /64 IPv6 prefix, you can allocate IPv6 addresses to
tunnel endpoints performing simple manipulations over the IPv4 endpoint
addresses. Specifically, the interface ID is constructed as follows:

EUI-64 = 0000 (16 bits) + 5EFE (16 bits) + IPv4 Address (32 bits).

Therefore, if you select the prefix 2001:1:0:345::/64, then R3 will have the IP
address:

2001:1:0:345:0:5efe:9601:0303/64

Where 9601 is for 150.1 and 0303 is for last two octets of the IP address. When
configuring an IOS router for ISATAP, you can automatically generate interface
ID’s with the eui-64 keyword.

Unlike the 6to4 tunnels, ISATAP tunnels cannot automatically extract the
destination. Therefore, you must use static routes that point to the exact IPv6
endpoint on the other end of the tunnel.

------------------------

Rack1R5#show interfaces tunnel 345
Rack1R5#show ipv6 interface tunnel 345
Rack1R5#ping 2001:1:0:345:0:5efe:9601:404
Rack1R5#ping 2001:1:0:345:0:5efe:9601:303
Rack1R5#ping 2001:1:0:4::4
Rack1R5#ping 2001:1:0:3::3

WB1 9.30 Automatic 6to4 Tunneling

9.30 Automatic 6to4 Tunneling

• Using the IPv4 Loopback 0 interfaces create automatic 6to4 tunnels
connecting R3, R4, and R5.
• Create additional Loopback interfaces on every router with the subnet
number 0 and the prefix length of 64 under the respective 6to4 /48 prefix.
• Use static routing to obtain connectivity between the newly allocated
subnets.

---------------------------

R3:
interface Tunnel 345
tunnel source Loopback0
tunnel mode ipv6ip 6to4
ipv6 address 2002:9601:303::3/64
!
ipv6 route 2002::/16 Tunnel 345
!
interface Loopback200
ipv6 address 2002:9601:303:1::3/64

R4:
interface Tunnel 345
tunnel source Loopback0
tunnel mode ipv6ip 6to4
ipv6 address 2002:9601:404::5/64
!
ipv6 route 2002::/16 Tunnel 345
!
interface Loopback200
ipv6 address 2002:9601:404:1::4/64

R5:
interface Tunnel 345
tunnel source Loopback0
tunnel mode ipv6ip 6to4
ipv6 address 2002:9601:505::5/64
!
ipv6 route 2002::/16 Tunnel 345
!
interface Loopback200
ipv6 address 2002:9601:505:1::5/64

-----------------------------

Automatic 6to4 tunnels are multipoint by design. The idea is to allow automatic
routing across an IPv4 cloud based on a part of the destinations IPv6 address.
Specifically, the format of the 6to4 IPv6 address is as follows:

2002 (16 bits):IPv4 address (32 bits):Subnet ID(16 bits):Interface ID (64 bits)

When a packet is routed across the 6to4 tunnel, the router extracts the IPv4
address embedded in the IPv6 address and uses it to build the IPv4 destination
address of the tunnel header. The receiving router strips the header, extracts the
IPv6 packet, and routes it based on the IPv6 routing table.

As you can imagine, 6to4 subnets have some addressing restrictions. First, you
need to use the 16-bit prefix 2002, as it is the common reservation for all 6to4
deployments. Second, you need to select the public IPv4 address used to create
the /48 prefix. It is common to pick any interface of the border router and then
allocate the /64 subnets to other devices on the network, as long as the address
is publicly routable.

6to4 tunnels are a transition mechanism for hosts that do not have native IPv6
connectivity, allowing them to reach other nodes that have full connectivity to the
IPv6 Internet. Due to the multipoint nature of the 6to4 tunnels, only static routing
is possible with this technology. However, it is common to simply route the whole
2002::/16 prefix to the 6to4 tunnel.

In our case, the use of Loopback 0 subnets results in the following IPv6 6to4
prefixes:

R3: 150.1.3.3 = 2002:9601:303::/48
R4: 150.1.4.4 = 2002:9601:404::/48
R5: 150.1.5.5 = 2002:9601:505::/48

“9601” in hex corresponds to “150.1” in decimal, and on R3 “303” corresponds to
“3.3”.

-----------------------------

Rack1R5#show interfaces tunnel 345
Rack1R5#ping ipv6 2002:9601:404:1::4
Rack1R5#ping ipv6 2002:9601:303:1::3

WB1 9.29 IPv6 Tunneling

9.29 IPv6 Tunneling

• Create new Loopback interfaces on R2, R5, and R6 with the IP addresses
2001:X:0:Y::Y/64 where Y is the router number and X is your rack number
in decimal notation (e.g. 10 for rack 10, 11 for rack 11 etc.)
• Create tunnels between R5 & R6 and R2 & R6. Use the IPv6 addresses
2001:X:0:56::Y/64 for the tunnel between R5 and R6 and the IPv6 address
2001:X:0:26::Y/64 for the tunnel between R2 and R6.
• The tunnel connecting R2 and R6 should use encapsulation suitable for
transporting different Layer 3 protocols.
• The tunnel connecting R5 and R6 should use the encapsulation
specifically designed for transporting IPv6 over IPv4.
• Use static routing to obtain connectivity.

---------------------

R2:
ipv6 unicast-routing
!
interface Loopback100
ipv6 address 2001:1:0:2::2/64
!
interface tunnel 26
tunnel source Loopback0
tunnel destination 150.1.6.6
ipv6 address 2001:1:0:26::2/64
!
ipv6 route ::/0 Tunnel 26

R5:
ipv6 unicast-routing
!
interface Loopback100
ipv6 address 2001:1:0:5::5/64
!
interface tunnel 56
tunnel source Loopback0
tunnel destination 150.1.6.6
ipv6 address 2001:1:0:56::5/64
tunnel mode ipv6ip
!
ipv6 route ::/0 Tunnel 56

R6:
ipv6 unicast-routing
!
interface Loopback100
ipv6 address 2001:1:0:6::6/64
!
interface tunnel 26
tunnel source Loopback0
tunnel destination 150.1.2.2
ipv6 address 2001:1:0:26::6/64
!
interface tunnel 56
tunnel source Loopback0
tunnel destination 150.1.5.5
ipv6 address 2001:1:0:56::6/64
tunnel mode ipv6ip
!
ipv6 route 2001:1:0:5::/64 Tunnel 56
ipv6 route 2001:1:0:2::/64 Tunnel 26

-------------

IPv6 can be transported across IPv4 clouds using various tunneling techniques.
The most common are static point-to-point tunnels, using either GRE (generic
routing encapsulation), or IPv6 in IPv4 encapsulation (a special protocol type
designed to carry only IPv6 packets). Designed to carry a multi-protocol payload,
GRE has a slightly larger overhead than IPv6 in IPv4 encapsulation.

-------------

Rack1R6#show interfaces tunnel 26
Rack1R6#show interfaces tunnel 56
Rack1R2#ping 2001:1:0:5::5 source loopback 100

----------

IPv6 IP tunnels use IP protocol number 41 for transport. This protocol number
does not have a keyword shortcut in extended IP access-lists in IOS. Therefore
to permit or deny an IPv6IP tunnel, the syntax access-list 100
[permit|deny] 41 any any is required.

WB1 9.28 IPv6 SSM

9.28 IPv6 SSM

• Configure R5 to join the group FF36::8 but only accept the multicast
streams sourced from R6’s IPv6 address on VLAN 146.

---------------------------------------------------------------------------

R5:
interface FastEthernet 0/0
ipv6 mld join-group ff36::8 2001:1:0:146:21A:2FFF:FE78:4678

---------------------------------------------------------------------------

Rack1R5#show ipv6 mroute

Rack1R4#show ipv6 mroute

Rack1R6#ping ipv6 FF36::8 repeat 1000
Output Interface: FastEthernet0/0.146

WB1 9.27 IPv6 Embedded RP

9.27 IPv6 Embedded RP

• Configure R6 to stop announcing itself as an RP.
• Configure R5 to join the group FF76:0640:2001:CC1E::8 on its VLAN 58
interface.
• Make sure R1 can still ping this group without any router in the domain
learning the RP information via the BSR.

------------------------------------------------------------------

R5:
interface FastEthernet 0/0
ipv6 mld join-group ff76:0640:2001:CC1E::8

R6:
no ipv6 pim bsr candidate rp FC00:1:0:6::6 priority 100
!
interface Loopback300
ipv6 address 2001:CC1E::6/128
ipv6 eigrp 100
ipv6 rip RIPNG enable

------------------------------------------------------------------

Rack1R5#show ipv6 pim range-list

Rack1R4#show ipv6 pim range-list

Rack1R1#ping ipv6 FF76:640:2001:CC1E::8 repeat 1000
Output Interface: FastEthernet0/0

Rack1R4#show ipv6 mroute


---------------------------

P.S 你應該不會從R1 ping的到R5 ，因為R5身上有過濾條件

Thanks for this correction.  
i also had the same problem, and spent quite a bit of time scratching my head on why R4 was not getting the new group in the Range-List.   The issue is definitely a result of the 9.25 filter (MLD_FILTER)..
In this particular task (9.27  Embedded RP), we are asked to join the group on R5's vlan58 (F0/0).    However, as the previous task (9.25 MLD_FILTER)  placed a filter on that interface, the new groups is never seen by R4 (as is needed).
Three Options (SG needs updating):
1.  remove filter on F0/0 (as Belal suggests above)
2.  or move  the join group to another interface (which does not have the FILTER)
3.  or modify the MLD_FILTER to include this new multicast group

WB1 9.26 IPv6 PIM BSR

9.26 IPv6 PIM BSR

• Configure R6 as the RP for the multicast domain and R4 as the BSR to
propagate this information.
• R1 should be able to ping the multicast group joined by R5.

--------------------------------------

R6:
ipv6 pim bsr candidate rp fc00:1:0:6::6 priority 100

R4:
ipv6 pim bsr candidate bsr fc00:1:0:4::4 priority 100

R5:
ipv6 route fc00:1:0:4::/64 Serial 0/1/0 multicast

R1:
!
ipv6 route FC00:1:0:4::/64 FastEthernet0/0 FE80::215:62FF:FE41:FD9D multicast

--------------------------------------

Rack1R1#show ipv6 pim bsr election
Rack1R5#show ipv6 pim bsr election
Rack1R1#show ipv6 pim range-list
Rack1R5#sh ipv6 pim range-list
Rack1R5#show ipv6 mroute

Rack1R1#ping ff08::8 repeat 10000
Output Interface: Serial 0/0

Rack1R4#show ipv6 mroute

Rack1R5#show ipv6 mroute