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
2013/12/07
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 R5R1, 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
• Remove the 6to4 tunnels connecting R3, R4, and R5.
• Using their Loopback 0 IPv4 addresses connect R3, R4, and R5
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
• 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.
• 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.
2013/12/05
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
• 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身上有過濾條件
• 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
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
• 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
WB1 9.25 IPv6 PIM and MLD
9.25 IPv6 PIM and MLD
• Enable IPv6 Multicast routing on R1, R3, R4, R5 and R6.
• Ensure PIM does not run on the Frame-Relay link between R4 and R5.
• Configure R5 to join the multicast group FF08::8/128 on its VLAN 58
interface.
• R5 should only accept MLD Reports for the group range FF08::/64 and
should limit the maximum number of multicast states on the interface
towards SW2 to 10.
• Send the general queries every 10 seconds on R5’s VLAN 58 interface.
--------------------------------------------------
R1, R3, R4, R5, R6:
ipv6 multicast-routing
R1:
interface Serial 0/1
no ipv6 pim
R3:
interface Serial 1/2
no ipv6 pim
R4:
interface Serial 0/0/0
no ipv6 pim
R5:
ipv6 access-list MLD_FILTER
permit ipv6 any ff08::/64
!
interface FastEthernet 0/0
ipv6 mld access-group MLD_FILTER
ipv6 mld join-group ff08::8
ipv6 mld query-interval 10
ipv6 mld limit 10
--------------------------------------------------
The access-list entry {permit|deny} ipv6 <part1> <part2> allows
for both SSM and normal multicast group filtering.
If you want to filter just MLDv1 joins, leave <part1> as “any” this specifies any source.
The parameter configured in <part2> is responsible for the multicast-group being joined.
--------------------------------------------------
Rack1R5#show ipv6 pim interface
Rack1R5#show ipv6 pim neighbor
• Enable IPv6 Multicast routing on R1, R3, R4, R5 and R6.
• Ensure PIM does not run on the Frame-Relay link between R4 and R5.
• Configure R5 to join the multicast group FF08::8/128 on its VLAN 58
interface.
• R5 should only accept MLD Reports for the group range FF08::/64 and
should limit the maximum number of multicast states on the interface
towards SW2 to 10.
• Send the general queries every 10 seconds on R5’s VLAN 58 interface.
--------------------------------------------------
R1, R3, R4, R5, R6:
ipv6 multicast-routing
R1:
interface Serial 0/1
no ipv6 pim
R3:
interface Serial 1/2
no ipv6 pim
R4:
interface Serial 0/0/0
no ipv6 pim
R5:
ipv6 access-list MLD_FILTER
permit ipv6 any ff08::/64
!
interface FastEthernet 0/0
ipv6 mld access-group MLD_FILTER
ipv6 mld join-group ff08::8
ipv6 mld query-interval 10
ipv6 mld limit 10
--------------------------------------------------
The access-list entry {permit|deny} ipv6 <part1> <part2> allows
for both SSM and normal multicast group filtering.
If you want to filter just MLDv1 joins, leave <part1> as “any” this specifies any source.
The parameter configured in <part2> is responsible for the multicast-group being joined.
--------------------------------------------------
Rack1R5#show ipv6 pim interface
Rack1R5#show ipv6 pim neighbor
WB1 9.24 IPv6 MP-BGP
9.24 IPv6 MP-BGP
• Configure R1 and R5 in BGP autonomous systems 100 and 500
respectively, and form a peering relationship over the Frame-Relay cloud.
• Create two new loopback interfaces on R1 with IPv6 addresses
2003:X:0:1::1/64 and 2003:X:0:11::11/61, and advertise them into BGP.
• Ensure R5 sees only an optimal summary route encompassing both IPv6
prefixes.
----------------------
R1:
interface Loopback 101
ipv6 address 2003:1:0:1::1/64
!
interface Loopback 102
ipv6 address 2003:1:0:11::11/61
!
router bgp 100
address-family ipv6 unicast
neighbor 2001:1:0:1234::5 remote-as 500
neighbor 2001:1:0:1234::5 activate
network 2003:1:0:1::/64
network 2003:1:0:10::/61
aggregate-address 2003:1::/59 summary-only
R5:
router bgp 500
address-family ipv6 unicast
neighbor 2001:1:0:1234::1 remote-as 100
neighbor 2001:1:0:1234::1 activate
----------------
Rack1R1#show bgp ipv6 unicast summary
Rack1R1#show bgp ipv6 unicast
Rack1R5#show bgp ipv6 unicast
• Configure R1 and R5 in BGP autonomous systems 100 and 500
respectively, and form a peering relationship over the Frame-Relay cloud.
• Create two new loopback interfaces on R1 with IPv6 addresses
2003:X:0:1::1/64 and 2003:X:0:11::11/61, and advertise them into BGP.
• Ensure R5 sees only an optimal summary route encompassing both IPv6
prefixes.
----------------------
R1:
interface Loopback 101
ipv6 address 2003:1:0:1::1/64
!
interface Loopback 102
ipv6 address 2003:1:0:11::11/61
!
router bgp 100
address-family ipv6 unicast
neighbor 2001:1:0:1234::5 remote-as 500
neighbor 2001:1:0:1234::5 activate
network 2003:1:0:1::/64
network 2003:1:0:10::/61
aggregate-address 2003:1::/59 summary-only
R5:
router bgp 500
address-family ipv6 unicast
neighbor 2001:1:0:1234::1 remote-as 100
neighbor 2001:1:0:1234::1 activate
----------------
Rack1R1#show bgp ipv6 unicast summary
Rack1R1#show bgp ipv6 unicast
Rack1R5#show bgp ipv6 unicast
WB1 9.23 IPv6 NAT-PT
9.23 IPv6 NAT-PT
• Configure R6 so that SW1 can access the IPv4 address 150.X.4.4 as
2000::9601:404.
• SW1 should source IPv6 packets off its VLAN 67 interface and R6 should
translate it to the IPv4 address 155.X.146.7.
• Create a static route on SW1 to ensure traffic for 2000::/96 does not
transit SW1’s Fa0/3 to reach R6.
---------------
R6:
interface FastEthernet 0/0.67
ipv6 nat
!
interface FastEthernet 0/0.146
ipv6 nat
!
ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
!
ipv6 nat prefix 2000::/96
!
! 我沒下，也可以
!
ipv6 router rip RIPNG
redistribute connected
SW1
!
! 我是下 ipv6 route 2000::9601:0404/128 fc00:1:0:67::6
!
ipv6 route 2000::/96 fc00:1:0:67::6
-----------------------
Rack1R6#debug ipv6 nat detailed
Rack1SW1#ping ipv6 2000::9601:0404
• Configure R6 so that SW1 can access the IPv4 address 150.X.4.4 as
2000::9601:404.
• SW1 should source IPv6 packets off its VLAN 67 interface and R6 should
translate it to the IPv4 address 155.X.146.7.
• Create a static route on SW1 to ensure traffic for 2000::/96 does not
transit SW1’s Fa0/3 to reach R6.
---------------
R6:
interface FastEthernet 0/0.67
ipv6 nat
!
interface FastEthernet 0/0.146
ipv6 nat
!
ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
!
ipv6 nat prefix 2000::/96
!
! 我沒下，也可以
!
ipv6 router rip RIPNG
redistribute connected
SW1
!
! 我是下 ipv6 route 2000::9601:0404/128 fc00:1:0:67::6
!
ipv6 route 2000::/96 fc00:1:0:67::6
-----------------------
Rack1R6#debug ipv6 nat detailed
Rack1SW1#ping ipv6 2000::9601:0404
WB1 9.22 IPv6 Filtering
9.22 IPv6 Filtering
• Configure R3’s Frame-Relay interface so that only FTP and HTTP traffic
from the users on VLAN 67 can access the interface.
• Allow DNS queries and responses from the same subnet, and ensure IPv6
routing will not be affected.
• Enable HTTP Server on R5
----------------------------------------------
題目應該要提醒 VLAN 67 <---------經過 R3 -------------> R5，filtering下在R3的Serial 1/0上
於是進出都要下囉....因為沒有分client / server
R3:
ipv6 access-list FILTER_OUT
permit tcp fc00:1:0:67::/64 any eq 80
permit tcp fc00:1:0:67::/64 any range 20 21
permit udp fc00:1:0:67::/64 any eq 53
!
ipv6 access-list FILTER_IN
permit tcp any eq 80 fc00:1:0:67::/64
permit tcp any range 20 21 fc00:1:0:67::/64
permit udp any eq 53 fc00:1:0:67::/64
permit 89 any any
!
interface Serial 1/0
ipv6 traffic-filter FILTER_OUT out
ipv6 traffic-filter FILTER_IN in
R5
ip http server
----------------------------------------------
Rack1SW1#ping 2001:1:0:1234::3
Rack1SW1#ping 2001:1:0:1234::5
Rack1R3#show ipv6 ospf neighbor
Rack1SW1#telnet 2001:1:0:1234::5 80
Rack1SW1#telnet 2001:1:0:1234::5 80 /source-interface vlan 67
• Configure R3’s Frame-Relay interface so that only FTP and HTTP traffic
from the users on VLAN 67 can access the interface.
• Allow DNS queries and responses from the same subnet, and ensure IPv6
routing will not be affected.
• Enable HTTP Server on R5
----------------------------------------------
題目應該要提醒 VLAN 67 <---------經過 R3 -------------> R5，filtering下在R3的Serial 1/0上
於是進出都要下囉....因為沒有分client / server
R3:
ipv6 access-list FILTER_OUT
permit tcp fc00:1:0:67::/64 any eq 80
permit tcp fc00:1:0:67::/64 any range 20 21
permit udp fc00:1:0:67::/64 any eq 53
!
ipv6 access-list FILTER_IN
permit tcp any eq 80 fc00:1:0:67::/64
permit tcp any range 20 21 fc00:1:0:67::/64
permit udp any eq 53 fc00:1:0:67::/64
permit 89 any any
!
interface Serial 1/0
ipv6 traffic-filter FILTER_OUT out
ipv6 traffic-filter FILTER_IN in
R5
ip http server
----------------------------------------------
Rack1SW1#ping 2001:1:0:1234::3
Rack1SW1#ping 2001:1:0:1234::5
Rack1R3#show ipv6 ospf neighbor
Rack1SW1#telnet 2001:1:0:1234::5 80
Rack1SW1#telnet 2001:1:0:1234::5 80 /source-interface vlan 67
WB1 9.21 IPv6 Redistribution
9.21 IPv6 Redistribution
• Perform mutual redistribute between OSPFv3, RIPng and EIGRPv6 on
R5.
• Ensure each protocol prefers to reach native prefixes using internal paths.
-------------
R5:
ipv6 router ospf 1
redistribute rip RIPNG metric 8
redistribute eigrp 100 metric 8
redistribute connected metric 8
!
ipv6 router rip RIPNG
redistribute eigrp 100 include-connected metric 8
redistribute ospf 1 include-connected metric 8
!
ipv6 router eigrp 100
redistribute rip RIPNG include-connected metric 1000 0 255 1 1500
redistribute ospf 1 include-connected metric 1000 0 255 1 1500
!
R6:
ipv6 router ospf 1
distance ospf external 171
-------------
Rack1R6#show ipv6 route rip
Rack1R6#show ipv6 route eigrp
Rack1R6#show ipv6 route ospf
• Perform mutual redistribute between OSPFv3, RIPng and EIGRPv6 on
R5.
• Ensure each protocol prefers to reach native prefixes using internal paths.
-------------
R5:
ipv6 router ospf 1
redistribute rip RIPNG metric 8
redistribute eigrp 100 metric 8
redistribute connected metric 8
!
ipv6 router rip RIPNG
redistribute eigrp 100 include-connected metric 8
redistribute ospf 1 include-connected metric 8
!
ipv6 router eigrp 100
redistribute rip RIPNG include-connected metric 1000 0 255 1 1500
redistribute ospf 1 include-connected metric 1000 0 255 1 1500
!
R6:
ipv6 router ospf 1
distance ospf external 171
-------------
Rack1R6#show ipv6 route rip
Rack1R6#show ipv6 route eigrp
Rack1R6#show ipv6 route ospf
WB1 9.20 OSPFv3 Summarization
9.20 OSPFv3 Summarization
• Configure OSPFv3 Area 58 on the link between SW2 and R5.
• Create two new interfaces, Loopback 100 and Loopback 101 on SW2 with
IPv6 addresses FC00:X:0:8::8/64 and FC00:X:0:88::88/64 respectively.
• Advertise both Loopbacks into OSPF Area 58 on SW2.
• Configure R5 to summarize the two subnets to an optimal prefix.
----------------------------------------
R5:
ipv6 router ospf 1
area 58 range fc00:1::/56
!
interface FastEthernet 0/0
ipv6 ospf 1 area 58
SW2:
ipv6 unicast-routing
!
interface Vlan 58
ipv6 ospf 1 area 58
!
interface Loopback100
ipv6 address fc00:1:0:8::8/64
ipv6 ospf 1 area 58
!
interface Loopback101
ipv6 address fc00:1:0:88::88/64
ipv6 ospf 1 area 58
------------------------------------
Rack1R5#show ipv6 ospf neighbor
Rack1R5#show ipv6 route ospf
Rack1R3#show ipv6 route ospf
Rack1SW1#show ipv6 route ospf
Rack1R6#show ipv6 route ospf
• Configure OSPFv3 Area 58 on the link between SW2 and R5.
• Create two new interfaces, Loopback 100 and Loopback 101 on SW2 with
IPv6 addresses FC00:X:0:8::8/64 and FC00:X:0:88::88/64 respectively.
• Advertise both Loopbacks into OSPF Area 58 on SW2.
• Configure R5 to summarize the two subnets to an optimal prefix.
----------------------------------------
R5:
ipv6 router ospf 1
area 58 range fc00:1::/56
!
interface FastEthernet 0/0
ipv6 ospf 1 area 58
SW2:
ipv6 unicast-routing
!
interface Vlan 58
ipv6 ospf 1 area 58
!
interface Loopback100
ipv6 address fc00:1:0:8::8/64
ipv6 ospf 1 area 58
!
interface Loopback101
ipv6 address fc00:1:0:88::88/64
ipv6 ospf 1 area 58
------------------------------------
Rack1R5#show ipv6 ospf neighbor
Rack1R5#show ipv6 route ospf
Rack1R3#show ipv6 route ospf
Rack1SW1#show ipv6 route ospf
Rack1R6#show ipv6 route ospf
WB1 9.19 OSPFv3 Virtual Links
9.19 OSPFv3 Virtual Links
• Restore the discontiguous OSPFv3 Area 0 by provisioning a virtual link
between R3 and SW1.
-----------
R3:
ipv6 router ospf 1
area 37 virtual-link 150.1.7.7
SW1:
ipv6 router ospf 1
area 37 virtual-link 150.1.3.3
--------------
Rack1R3#show ipv6 ospf neighbor
Rack1R3#show ipv6 ospf virtual-links
Rack1R6#show ipv6 route ospf
• Restore the discontiguous OSPFv3 Area 0 by provisioning a virtual link
between R3 and SW1.
-----------
R3:
ipv6 router ospf 1
area 37 virtual-link 150.1.7.7
SW1:
ipv6 router ospf 1
area 37 virtual-link 150.1.3.3
--------------
Rack1R3#show ipv6 ospf neighbor
Rack1R3#show ipv6 ospf virtual-links
Rack1R6#show ipv6 route ospf
WB1 9.18 OSPFv3 over NBMA
9.18 OSPFv3 over NBMA
• Configure OSPFv3 area 0 on the Frame-Relay links of R5, R2, and R3.
• Use a network type that does not elect a DR, and ensure that OSPF does
not send broadcast hello packets.
---------------------------------------------
R2:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.2.2
!
interface Serial 0/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::5
R3:
interface Serial 1/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::5
R5:
ipv6 router ospf 1
router-id 150.1.5.5
!
interface Serial 0/0/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::3
ipv6 ospf neighbor fe80::2
---------------------------------------------
Rack1R5#show ipv6 ospf neighbor
Rack1R5#show ipv6 ospf int se 0/0/0
• Configure OSPFv3 area 0 on the Frame-Relay links of R5, R2, and R3.
• Use a network type that does not elect a DR, and ensure that OSPF does
not send broadcast hello packets.
---------------------------------------------
R2:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.2.2
!
interface Serial 0/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::5
R3:
interface Serial 1/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::5
R5:
ipv6 router ospf 1
router-id 150.1.5.5
!
interface Serial 0/0/0
ipv6 ospf 1 area 0
ipv6 ospf network point-to-multipoint non-broadcast
ipv6 ospf neighbor fe80::3
ipv6 ospf neighbor fe80::2
---------------------------------------------
Rack1R5#show ipv6 ospf neighbor
Rack1R5#show ipv6 ospf int se 0/0/0
WB1 9.17 OSPFv3
9.17 OSPFv3
• Configure OSPFv3 as the routing protocol on the links connecting R3,
SW1, and R6.
• Manually configure the router identifiers for all OSPFv3 processes to
match the IPv4 Loopback 0 addresses on these routers.
• Use Area 0 on the link between SW1 and R6 and use Area 37 on the link
between R3 and SW1.
• Change the network type to point-to-point on the link between R3 and
SW1.
• Make the default hello/dead intervals on the segment connecting R6 and
SW1 10 times less than the default.
-----------------------------
R3:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.3.3
!
interface FastEthernet 0/0
ipv6 ospf 1 area 37
ipv6 ospf network point-to-point
R6:
ipv6 router ospf 1
router-id 150.1.6.6
!
interface FastEthernet 0/0.67
ipv6 ospf hello-interval 1
ipv6 ospf 1 area 0
SW1:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.7.7
!
interface Vlan 67
ipv6 ospf hello-interval 1
ipv6 ospf 1 area 0
!
interface FastEthernet 0/3
ipv6 ospf 1 area 37
ipv6 ospf network point-to-point
---------------------
Rack1SW1#show ipv6 ospf neighbor
Rack1SW1#show ipv6 ospf 1
Rack1SW1#show ipv6 ospf interface fastEthernet 0/3
Rack1SW1#show ipv6 ospf interface Vlan 67
• Configure OSPFv3 as the routing protocol on the links connecting R3,
SW1, and R6.
• Manually configure the router identifiers for all OSPFv3 processes to
match the IPv4 Loopback 0 addresses on these routers.
• Use Area 0 on the link between SW1 and R6 and use Area 37 on the link
between R3 and SW1.
• Change the network type to point-to-point on the link between R3 and
SW1.
• Make the default hello/dead intervals on the segment connecting R6 and
SW1 10 times less than the default.
-----------------------------
R3:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.3.3
!
interface FastEthernet 0/0
ipv6 ospf 1 area 37
ipv6 ospf network point-to-point
R6:
ipv6 router ospf 1
router-id 150.1.6.6
!
interface FastEthernet 0/0.67
ipv6 ospf hello-interval 1
ipv6 ospf 1 area 0
SW1:
ipv6 unicast-routing
!
ipv6 router ospf 1
router-id 150.1.7.7
!
interface Vlan 67
ipv6 ospf hello-interval 1
ipv6 ospf 1 area 0
!
interface FastEthernet 0/3
ipv6 ospf 1 area 37
ipv6 ospf network point-to-point
---------------------
Rack1SW1#show ipv6 ospf neighbor
Rack1SW1#show ipv6 ospf 1
Rack1SW1#show ipv6 ospf interface fastEthernet 0/3
Rack1SW1#show ipv6 ospf interface Vlan 67
2013/12/04
CCIE R&S Version 5 Updates Now Official
終於...該來的還是來了...加油吧～～～Huck
http://blog.ine.com/2013/12/03/ccie-rs-version-5-updates-now-official/
Today Cisco posted their official announcement on the upcoming changes for CCIE Routing & Switching Version 5. The majority of the announcement is along the same lines as previously rumored changes, except for the official launch date, which is now scheduled for June 4th 2014. This should bring a great sigh of relief to you if you’re currently nearing the end of your CCIE R&S v4 preparation, as you now have a 6 month window to pass the v4 lab exam before the change to v5 occurs.
https://learningnetwork.cisco.com/docs/DOC-22703
http://www.cisco.com/web/learning/certifications/expert/ccie_rs/index.html
http://blog.ine.com/2013/12/03/ccie-rs-version-5-updates-now-official/
Today Cisco posted their official announcement on the upcoming changes for CCIE Routing & Switching Version 5. The majority of the announcement is along the same lines as previously rumored changes, except for the official launch date, which is now scheduled for June 4th 2014. This should bring a great sigh of relief to you if you’re currently nearing the end of your CCIE R&S v4 preparation, as you now have a 6 month window to pass the v4 lab exam before the change to v5 occurs.
https://learningnetwork.cisco.com/docs/DOC-22703
http://www.cisco.com/web/learning/certifications/expert/ccie_rs/index.html
WB1 9.16 EIGRPv6 Default Routing
9.16 EIGRPv6 Default Routing
• Configure R6 to advertise a default route into the EIGRPv6 routing
domain.
-----------------
R6:
interface FastEthernet0/0.146
ipv6 summary-address eigrp 100 ::/0 5
-----------------
Rack1R5#show ipv6 route eigrp
Notice that SW2 uses the static default route learned via auto-configuration
because of its better AD:
Rack1SW2#show ipv6 route
• Configure R6 to advertise a default route into the EIGRPv6 routing
domain.
-----------------
R6:
interface FastEthernet0/0.146
ipv6 summary-address eigrp 100 ::/0 5
-----------------
Rack1R5#show ipv6 route eigrp
Notice that SW2 uses the static default route learned via auto-configuration
because of its better AD:
Rack1SW2#show ipv6 route
WB1 9.15 EIGRPv6 Metric Manipulation
9.15 EIGRPv6 Metric Manipulation
• Allow EIGRPv6 to perform load balancing between multiple paths with
unequal metrics so long as the metrics are within the range of the optimal
metric scaled three times.
• Configure R4’s Serial link to R5 to have a delay that is twice good as R4’s
Frame-Relay link.
--------------------------------------------------------------
R4, R5, R6, SW2:
ipv6 router eigrp 100
metric weight 0 0 0 1 0 0
variance 3
R4:
interface Serial 0/0/0
delay 2000
!
interface Serial 0/1/0
delay 1000
--------------------------------------------------------------
Rack1R4#show ipv6 protocols
Rack1R4#show ipv6 route FC00:1::/60
Rack1R4# show ipv6 eigrp topology FC00:1::/60
Rack1R4#show ipv6 cef FC00:1::/60 internal
• Allow EIGRPv6 to perform load balancing between multiple paths with
unequal metrics so long as the metrics are within the range of the optimal
metric scaled three times.
• Configure R4’s Serial link to R5 to have a delay that is twice good as R4’s
Frame-Relay link.
--------------------------------------------------------------
R4, R5, R6, SW2:
ipv6 router eigrp 100
metric weight 0 0 0 1 0 0
variance 3
R4:
interface Serial 0/0/0
delay 2000
!
interface Serial 0/1/0
delay 1000
--------------------------------------------------------------
Rack1R4#show ipv6 protocols
Rack1R4#show ipv6 route FC00:1::/60
Rack1R4# show ipv6 eigrp topology FC00:1::/60
Rack1R4#show ipv6 cef FC00:1::/60 internal
WB1 9.14 EIGRPv6 Prefix Filtering
9.14 EIGRPv6 Prefix Filtering
• Configure R5 to block the IPv6 prefix corresponding to R6’s Loopback 100
interface from entering the local routing table.
• Permit any other IPv6 prefixes.
------------
R5:
no ipv6 prefix-list R6_LOOP100
!
! Notice the last line in the prefix-list which permits all
! IPv6 prefixes
!
ipv6 prefix-list R6_LOOP100 seq 10 deny FC00:1:0:6::/64
Ipv6 prefix-list R6_LOOP100 seq 20 permit ::/0 le 128
!
ipv6 router eigrp 100
distribute-list prefix-list R6_LOOP100 in
--------------------
Rack1R5#show ipv6 route eigrp
Rack1R5#show ipv6 route FC00:1:0:6::/64
• Configure R5 to block the IPv6 prefix corresponding to R6’s Loopback 100
interface from entering the local routing table.
• Permit any other IPv6 prefixes.
------------
R5:
no ipv6 prefix-list R6_LOOP100
!
! Notice the last line in the prefix-list which permits all
! IPv6 prefixes
!
ipv6 prefix-list R6_LOOP100 seq 10 deny FC00:1:0:6::/64
Ipv6 prefix-list R6_LOOP100 seq 20 permit ::/0 le 128
!
ipv6 router eigrp 100
distribute-list prefix-list R6_LOOP100 in
--------------------
Rack1R5#show ipv6 route eigrp
Rack1R5#show ipv6 route FC00:1:0:6::/64
WB1 9.13 EIGRPv6 Summarization
9.13 EIGRPv6 Summarization
• Ensure that R5 advertises an optimal summary prefix for the IPv6
addresses of R5’s and SW2’s Loopback 100 interfaces.
---------------
R5:
interface Serial 0/0/0
ipv6 summary-address eigrp 100 FC00:1::/60
!
interface Serial 0/1/0
ipv6 summary-address eigrp 100 FC00:1::/60
---------------
Rack1R4#show ipv6 route eigrp
• Ensure that R5 advertises an optimal summary prefix for the IPv6
addresses of R5’s and SW2’s Loopback 100 interfaces.
---------------
R5:
interface Serial 0/0/0
ipv6 summary-address eigrp 100 FC00:1::/60
!
interface Serial 0/1/0
ipv6 summary-address eigrp 100 FC00:1::/60
---------------
Rack1R4#show ipv6 route eigrp
WB1 9.12 EIGRPv6
9.12 EIGRPv6
• Enable the EIGRPv6 routing process on R4, R5, R6 and SW2.
• Enable EIGRPv6 on all interfaces connecting R4, R5, R6 and SW2.
• Create new Loopback 100 interfaces on the mentioned routers with the
IPv6 addresses FC00:X:0:Y::Y/64, where X is your rack number in
decimal notation and Y is the router number.
• Advertise these Loopback interfaces into EIGRPv6.
• Enable EIGRPv6 on the Frame-Relay interfaces of R4, and R5.
• Authenticate the EIGRPv6 adjacency over VLAN 146 using the password
value of CISCO.
-----------------------------------------------------------------------------------
R4:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
key chain EIGRPV6
key 1
key-string CISCO
!
interface FastEthernet 0/1
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 EIGRPV6
!
interface Loopback100
ipv6 address fc00:1:0:4::4/64
ipv6 eigrp 100
!
interface Serial0/0/0
ipv6 eigrp 100
!
interface Serial0/1/0
ipv6 eigrp 100
R5:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
interface Serial 0/0/0
ipv6 eigrp 100
!
interface Serial0/1/0
ipv6 eigrp 100
!
interface FastEthernet 0/0
ipv6 eigrp 100
!
interface Loopback100
ipv6 address fc00:1:0:5::5/64
ipv6 eigrp 100
R6:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
key chain EIGRPV6
key 1
key-string CISCO
!
interface FastEthernet 0/0.146
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 EIGRPV6
!
interface Loopback100
ipv6 address fc00:1:0:6::6/64
ipv6 eigrp 100
SW2:
sdm prefer dual-ipv4-and-ipv6 routing
ipv6 unicast-routing
!
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
!
interface Vlan 58
ipv6 eigrp 100
!
interface Loopback 100
ipv6 address fc00:1:0:8::8/64
ipv6 eigrp 100
---------------
Rack1R5#show ipv6 eigrp 100 interfaces
Rack1R5#show ipv6 protocols
Rack1R5#show ipv6 eigrp neighbors
Rack1R4#show ipv6 eigrp neighbors fastEthernet 0/1
Rack1R4#show ipv6 eigrp interfaces detail fastEthernet 0/1
Rack1SW2#show ipv6 route eigrp
Rack1SW2#ping fc00:1:0:6::6 source loopback 100
• Enable the EIGRPv6 routing process on R4, R5, R6 and SW2.
• Enable EIGRPv6 on all interfaces connecting R4, R5, R6 and SW2.
• Create new Loopback 100 interfaces on the mentioned routers with the
IPv6 addresses FC00:X:0:Y::Y/64, where X is your rack number in
decimal notation and Y is the router number.
• Advertise these Loopback interfaces into EIGRPv6.
• Enable EIGRPv6 on the Frame-Relay interfaces of R4, and R5.
• Authenticate the EIGRPv6 adjacency over VLAN 146 using the password
value of CISCO.
-----------------------------------------------------------------------------------
R4:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
key chain EIGRPV6
key 1
key-string CISCO
!
interface FastEthernet 0/1
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 EIGRPV6
!
interface Loopback100
ipv6 address fc00:1:0:4::4/64
ipv6 eigrp 100
!
interface Serial0/0/0
ipv6 eigrp 100
!
interface Serial0/1/0
ipv6 eigrp 100
R5:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
interface Serial 0/0/0
ipv6 eigrp 100
!
interface Serial0/1/0
ipv6 eigrp 100
!
interface FastEthernet 0/0
ipv6 eigrp 100
!
interface Loopback100
ipv6 address fc00:1:0:5::5/64
ipv6 eigrp 100
R6:
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
key chain EIGRPV6
key 1
key-string CISCO
!
interface FastEthernet 0/0.146
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 EIGRPV6
!
interface Loopback100
ipv6 address fc00:1:0:6::6/64
ipv6 eigrp 100
SW2:
sdm prefer dual-ipv4-and-ipv6 routing
ipv6 unicast-routing
!
ipv6 unicast-routing
ipv6 router eigrp 100
no shutdown
!
!
interface Vlan 58
ipv6 eigrp 100
!
interface Loopback 100
ipv6 address fc00:1:0:8::8/64
ipv6 eigrp 100
---------------
Rack1R5#show ipv6 eigrp 100 interfaces
Rack1R5#show ipv6 protocols
Rack1R5#show ipv6 eigrp neighbors
Rack1R4#show ipv6 eigrp neighbors fastEthernet 0/1
Rack1R4#show ipv6 eigrp interfaces detail fastEthernet 0/1
Rack1SW2#show ipv6 route eigrp
Rack1SW2#ping fc00:1:0:6::6 source loopback 100
WB1 9.11 RIPng Default Routing
9.11 RIPng Default Routing
• Configure R6 to advertise a default route into the RIPng routing domain
with an initial metric of 5.
----------------------------------------------
R6:
interface FastEthernet 0/0.146
ipv6 rip RIPNG default-information originate metric 5
• Configure R6 to advertise a default route into the RIPng routing domain
with an initial metric of 5.
----------------------------------------------
R6:
interface FastEthernet 0/0.146
ipv6 rip RIPNG default-information originate metric 5
WB1 9.10 RIPng Metric Manipulation
9.10 RIPng Metric Manipulation
• Enable IPv6 and RIPng on the Serial link connecting R4 and R5.
• Ensure that R4 prefers the Serial link to reach the Loopback 100 interface
of R5 and uses the Frame-Relay link ONLY as a backup.
• Do not use summarization to accomplish this task.
------------------------------------------------------
R4:
interface Serial 0/1/0
ipv6 enable
ipv6 rip RIPNG enable
!
interface Serial 0/0/0
ipv6 rip RIPNG metric-offset 2
R5:
interface Serial 0/1/0
ipv6 enable
ipv6 rip RIPNG enable
• Enable IPv6 and RIPng on the Serial link connecting R4 and R5.
• Ensure that R4 prefers the Serial link to reach the Loopback 100 interface
of R5 and uses the Frame-Relay link ONLY as a backup.
• Do not use summarization to accomplish this task.
------------------------------------------------------
R4:
interface Serial 0/1/0
ipv6 enable
ipv6 rip RIPNG enable
!
interface Serial 0/0/0
ipv6 rip RIPNG metric-offset 2
R5:
interface Serial 0/1/0
ipv6 enable
ipv6 rip RIPNG enable
WB1 9.9 RIPng Prefix Filtering
9.9 RIPng Prefix Filtering
• Configure R5 to block the IPv6 prefix corresponding to R6’s Loopback 100
interface from entering the local routing table.
• Permit any other IPv6 prefixes
-----------------------
R5:
ipv6 prefix-list FILTER_R6_LO100 deny fc00:1:0:6::/64
ipv6 prefix-list FILTER_R6_LO100 permit ::/0 le 128
!
ipv6 router rip RIPNG
distribute-list prefix-list FILTER_R6_LO100 in
-----------------------
show ipv6 route rip
clear ipv6 rip [pid]
show ipv6 route rip
• Configure R5 to block the IPv6 prefix corresponding to R6’s Loopback 100
interface from entering the local routing table.
• Permit any other IPv6 prefixes
-----------------------
R5:
ipv6 prefix-list FILTER_R6_LO100 deny fc00:1:0:6::/64
ipv6 prefix-list FILTER_R6_LO100 permit ::/0 le 128
!
ipv6 router rip RIPNG
distribute-list prefix-list FILTER_R6_LO100 in
-----------------------
show ipv6 route rip
clear ipv6 rip [pid]
show ipv6 route rip
WB1 9.8 RIPng Summarization
9.8 RIPng Summarization
• Create a new Loopback 100 interface on R5 with the IPv6 address
FC00:X:0:5::5/64 where X is your rack number in decimal notation and
advertise this interface into RIPng.
• Ensure that R1 and R4 advertise only the summary prefix for the
Loopback 100 interfaces of R1, R4, and R5 to R6 across the VLAN 146
segment.
--------------------------------------
R1:
interface FastEthernet 0/0
ipv6 rip RIPNG summary fc00:1::/61
R4:
interface FastEthernet 0/1
ipv6 rip RIPNG summary fc00:1::/61
R5:
interface Loopback 100
ipv6 address fc00:1:0:5::5/64
ipv6 rip RIPNG enable
--------------------------------------
• Create a new Loopback 100 interface on R5 with the IPv6 address
FC00:X:0:5::5/64 where X is your rack number in decimal notation and
advertise this interface into RIPng.
• Ensure that R1 and R4 advertise only the summary prefix for the
Loopback 100 interfaces of R1, R4, and R5 to R6 across the VLAN 146
segment.
--------------------------------------
R1:
interface FastEthernet 0/0
ipv6 rip RIPNG summary fc00:1::/61
R4:
interface FastEthernet 0/1
ipv6 rip RIPNG summary fc00:1::/61
R5:
interface Loopback 100
ipv6 address fc00:1:0:5::5/64
ipv6 rip RIPNG enable
--------------------------------------
WB1 9.7 RIPng over NBMA
9.7 RIPng over NBMA
• Enable RIPng on the Frame-Relay interfaces of R1, R4, and R5 using the
process name “RIPNG”.
• Ensure that R1 and R4 can reach each other’s Loopback 100 subnets
even if any of their VLAN 146 interfaces are down.
------------------------------------------------
R1:
interface Serial 0/0
ipv6 rip RIPNG enable
R4:
interface Serial0/0/0
ipv6 rip RIPNG enable
R5:
ipv6 unicast-routing
!
ipv6 router rip RIPNG
no split-horizon
!
interface Serial 0/0/0
ipv6 rip RIPNG enable
-------------------------------------
• Enable RIPng on the Frame-Relay interfaces of R1, R4, and R5 using the
process name “RIPNG”.
• Ensure that R1 and R4 can reach each other’s Loopback 100 subnets
even if any of their VLAN 146 interfaces are down.
------------------------------------------------
R1:
interface Serial 0/0
ipv6 rip RIPNG enable
R4:
interface Serial0/0/0
ipv6 rip RIPNG enable
R5:
ipv6 unicast-routing
!
ipv6 router rip RIPNG
no split-horizon
!
interface Serial 0/0/0
ipv6 rip RIPNG enable
-------------------------------------
WB1 9.6 RIPng
9.6 RIPng
• Enable RIPng on the VLAN 146 segment connecting R1, R4, and R6
using the process name “RIPNG”.
• Create new Loopback 100 interfaces on R1, R4, and R6 with the IPv6
addresses FC00:X:0:Y::Y/64, where X is your rack number in decimal
notation and Y is your router number.
• Advertise these Loopback interfaces into RIPng.
--------------------------------------
R1:
ipv6 unicast-routing
!
interface FastEthernet 0/0
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:1::1/64
ipv6 rip RIPNG enable
R4:
ipv6 unicast-routing
!
interface FastEthernet 0/1
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:4::4/64
ipv6 rip RIPNG enable
R6:
ipv6 unicast-routing
!
interface FastEthernet 0/0.146
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:6::6/64
ipv6 rip RIPNG enable
• Enable RIPng on the VLAN 146 segment connecting R1, R4, and R6
using the process name “RIPNG”.
• Create new Loopback 100 interfaces on R1, R4, and R6 with the IPv6
addresses FC00:X:0:Y::Y/64, where X is your rack number in decimal
notation and Y is your router number.
• Advertise these Loopback interfaces into RIPng.
--------------------------------------
R1:
ipv6 unicast-routing
!
interface FastEthernet 0/0
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:1::1/64
ipv6 rip RIPNG enable
R4:
ipv6 unicast-routing
!
interface FastEthernet 0/1
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:4::4/64
ipv6 rip RIPNG enable
R6:
ipv6 unicast-routing
!
interface FastEthernet 0/0.146
ipv6 rip RIPNG enable
!
interface Loopback100
ipv6 address fc00:1:0:6::6/64
ipv6 rip RIPNG enable
2013/12/02
WB1 9.5 IPv6 Auto-Configuration
9.5 IPv6 Auto-Configuration
• Use the unique local address FC00:X:0:58::5/64 for R5’s VLAN 58
interface, where X is your rack number in decimal notation.
• Configure an additional IPv6 address of FC00:X:0:85::5/64 on the same
interface of R5.
• Configure R5 to broadcast both prefixes using ICMPv6 ND RAs, but only
allow the hosts to use the second prefix for auto-configuration.
• The valid and preferred lifetime for both prefixes should be set to 4 hours.
• R5 should advertise itself as the default router on the segment every 40
seconds with a lifetime interval of 60 seconds.
• SW2 should learn its IPv6 address on VLAN 58 automatically and use R5
as its default gateway.
-----------------------------------------------------------------
IPv6 has a special feature called auto-configuration. It replaces many functions
served by DHCP in IPv4 networks (yet there is a special DHCPv6 edition of the
DHCP protocol). With IPv6 auto-configuration, an IPv6 host may automatically
learn the IPv6 prefixes assigned to the local segment, as well as determine the
default routers on that segment. A special type of link-local IPv6 addressing and
the ICMPv6 ND (Neighbor Discovery) protocol accomplish this.
Router Advertisements can be sent at a specified interval or the feature can be
suppressed completely (“suppress-ra” is enabled by default on Ethernet
interfaces. This default behavior can be changed with the no ipv6 nd suppressra)
depending on how you configure your Cisco router. Note that you must
enable IPv6 unicast routing in order to send router advertisements. The following
commands control the IPv6 RA announcements:
ipv6 nd ra-interval – specifies the periodic interval to send RAs.
ipv6 nd ra-lifetime – specifies the validity interval of the router’s IPv6
address
ipv6 nd prefix – manipulates the IPv6 network prefixes included into RA. By
default, all prefixes are included.
You may adjust the interval that the prefix is valid and preferred with every
command. Additionally, you may instruct the hosts not to use this prefix for autoconfiguration,
by using the no-autoconfig keyword.
-----------------------------------------------------------------
R5:
ipv6 unicast-routing
!
interface FastEthernet 0/0
ipv6 address fc00:1:0:58::5/64
ipv6 address fc00:1:0:85::5/64
ipv6 nd prefix fc00:1:0:58::/64 14400 14400 no-autoconfig
ipv6 nd prefix fc00:1:0:85::/64 14400 14400
ipv6 nd ra-interval 40
ipv6 nd ra-lifetime 60
no ipv6 nd suppress-ra (我在R5上設定為no ipv6 nd ra suppress)
SW2:
sdm prefer dual-ipv4-and-ipv6 routing
!
interface Vlan 58
ipv6 address autoconfig default
-----------------------------------------------------------------
Rack1SW2#show ipv6 interface vlan 58
Vlan58 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20F:34FF:FEFC:6CC6
No Virtual link-local address(es):
Stateless address autoconfig enabled
Global unicast address(es):
FC00:1:0:85:20F:34FF:FEFC:6CC6, subnet is FC00:1:0:85::/64 [EUI/CAL/PRE]
valid lifetime 14366 preferred lifetime 14366
Joined group address(es):
FF02::1
FF02::1:FFFC:6CC6
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 39146)
Default router is FE80::C004:12FF:FE30:0 on Vlan58
Rack1SW2#
Rack1R5#show ipv6 interface fastEthernet 0/0 prefix
IPv6 Prefix Advertisements FastEthernet0/0
Codes: A - Address, P - Prefix-Advertisement, O - Pool
U - Per-user prefix, D - Default
N - Not advertised, C - Calendar
PD default [LA] Valid lifetime 2592000, preferred lifetime 604800
PA FC00:1:0:58::/64 [L] Valid lifetime 14400, preferred lifetime 14400
PA FC00:1:0:85::/64 [LA] Valid lifetime 14400, preferred lifetime 14400
Rack1R5#
ICMP Neighbor Discovery events debugging is on
Rack1R5#
Rack1R5#
*Mar 1 11:15:27.205: ICMPv6-ND: REACH -> STALE: FE80::D8B4:129B:CFAB:4619
Rack1R5#
*Mar 1 11:15:43.713: ICMPv6-ND: Request to send RA for FE80::C004:12FF:FE30:0
*Mar 1 11:15:43.717: ICMPv6-ND: Sending RA from FE80::C004:12FF:FE30:0 to FF02::1 on FastEthernet0/0
*Mar 1 11:15:43.721: ICMPv6-ND: MTU = 1500
*Mar 1 11:15:43.721: ICMPv6-ND: prefix = FC00:1:0:58::/64 onlink
*Mar 1 11:15:43.721: ICMPv6-ND: 14400/14400 (valid/preferred)
*Mar 1 11:15:43.725: ICMPv6-ND: prefix = FC00:1:0:85::/64 onlink autoconfig
*Mar 1 11:15:43.729: ICMPv6-ND: 14400/14400 (valid/preferred)
Rack1R5#
• Use the unique local address FC00:X:0:58::5/64 for R5’s VLAN 58
interface, where X is your rack number in decimal notation.
• Configure an additional IPv6 address of FC00:X:0:85::5/64 on the same
interface of R5.
• Configure R5 to broadcast both prefixes using ICMPv6 ND RAs, but only
allow the hosts to use the second prefix for auto-configuration.
• The valid and preferred lifetime for both prefixes should be set to 4 hours.
• R5 should advertise itself as the default router on the segment every 40
seconds with a lifetime interval of 60 seconds.
• SW2 should learn its IPv6 address on VLAN 58 automatically and use R5
as its default gateway.
-----------------------------------------------------------------
IPv6 has a special feature called auto-configuration. It replaces many functions
served by DHCP in IPv4 networks (yet there is a special DHCPv6 edition of the
DHCP protocol). With IPv6 auto-configuration, an IPv6 host may automatically
learn the IPv6 prefixes assigned to the local segment, as well as determine the
default routers on that segment. A special type of link-local IPv6 addressing and
the ICMPv6 ND (Neighbor Discovery) protocol accomplish this.
Router Advertisements can be sent at a specified interval or the feature can be
suppressed completely (“suppress-ra” is enabled by default on Ethernet
interfaces. This default behavior can be changed with the no ipv6 nd suppressra)
depending on how you configure your Cisco router. Note that you must
enable IPv6 unicast routing in order to send router advertisements. The following
commands control the IPv6 RA announcements:
ipv6 nd ra-interval – specifies the periodic interval to send RAs.
ipv6 nd ra-lifetime – specifies the validity interval of the router’s IPv6
address
ipv6 nd prefix – manipulates the IPv6 network prefixes included into RA. By
default, all prefixes are included.
You may adjust the interval that the prefix is valid and preferred with every
command. Additionally, you may instruct the hosts not to use this prefix for autoconfiguration,
by using the no-autoconfig keyword.
-----------------------------------------------------------------
R5:
ipv6 unicast-routing
!
interface FastEthernet 0/0
ipv6 address fc00:1:0:58::5/64
ipv6 address fc00:1:0:85::5/64
ipv6 nd prefix fc00:1:0:58::/64 14400 14400 no-autoconfig
ipv6 nd prefix fc00:1:0:85::/64 14400 14400
ipv6 nd ra-interval 40
ipv6 nd ra-lifetime 60
no ipv6 nd suppress-ra (我在R5上設定為no ipv6 nd ra suppress)
SW2:
sdm prefer dual-ipv4-and-ipv6 routing
!
interface Vlan 58
ipv6 address autoconfig default
-----------------------------------------------------------------
Rack1SW2#show ipv6 interface vlan 58
Vlan58 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20F:34FF:FEFC:6CC6
No Virtual link-local address(es):
Stateless address autoconfig enabled
Global unicast address(es):
FC00:1:0:85:20F:34FF:FEFC:6CC6, subnet is FC00:1:0:85::/64 [EUI/CAL/PRE]
valid lifetime 14366 preferred lifetime 14366
Joined group address(es):
FF02::1
FF02::1:FFFC:6CC6
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 39146)
Default router is FE80::C004:12FF:FE30:0 on Vlan58
Rack1SW2#
Rack1R5#show ipv6 interface fastEthernet 0/0 prefix
IPv6 Prefix Advertisements FastEthernet0/0
Codes: A - Address, P - Prefix-Advertisement, O - Pool
U - Per-user prefix, D - Default
N - Not advertised, C - Calendar
PD default [LA] Valid lifetime 2592000, preferred lifetime 604800
PA FC00:1:0:58::/64 [L] Valid lifetime 14400, preferred lifetime 14400
PA FC00:1:0:85::/64 [LA] Valid lifetime 14400, preferred lifetime 14400
Rack1R5#
ICMP Neighbor Discovery events debugging is on
Rack1R5#
Rack1R5#
*Mar 1 11:15:27.205: ICMPv6-ND: REACH -> STALE: FE80::D8B4:129B:CFAB:4619
Rack1R5#
*Mar 1 11:15:43.713: ICMPv6-ND: Request to send RA for FE80::C004:12FF:FE30:0
*Mar 1 11:15:43.717: ICMPv6-ND: Sending RA from FE80::C004:12FF:FE30:0 to FF02::1 on FastEthernet0/0
*Mar 1 11:15:43.721: ICMPv6-ND: MTU = 1500
*Mar 1 11:15:43.721: ICMPv6-ND: prefix = FC00:1:0:58::/64 onlink
*Mar 1 11:15:43.721: ICMPv6-ND: 14400/14400 (valid/preferred)
*Mar 1 11:15:43.725: ICMPv6-ND: prefix = FC00:1:0:85::/64 onlink autoconfig
*Mar 1 11:15:43.729: ICMPv6-ND: 14400/14400 (valid/preferred)
Rack1R5#
WB1 9.4 IPv6 EUI-64 Addressing
9.4 IPv6 EUI-64 Addressing
• Configure globally aggregatable IPv6 addresses in the format
2001:X:0:146::Y/64 on the VLAN 146 interfaces of R1, R4, and R6.
• Here X is your rack number in decimal notation, (e.g. 10 for Rack10, not
the hex 0A) and the router will automatically derive Y based on the
interface MAC address.
--------------------------------------------------------
R1:
interface FastEthernet 0/0
ipv6 address 2001:1:0:146::/64 eui-64
R4:
interface FastEthernet 0/1
ipv6 address 2001:1:0:146::/64 eui-64
R6:
interface FastEthernet 0/0.146
ipv6 address 2001:1:0:146::/64 eui-64
--------------------------------------------------------
Extended Unique Identifiers (EUIs) are 64-bit values assigned to physical
interfaces. EUI’s are similar in many respects to IEEE MAC addresses, in that
they identity a physical interface, but EUI’s are designed to be used universally,
not just with the hardware addresses.
IPv6 uses EUI-64 to construct a unique host address on a shared Ethernet
segment automatically. When you use the eui-64 keyword, the IOS uses the
48-bit hardware address of the Ethernet interface as the foundation to construct
the unique 64-bit Interface identifier of the IPv6 address.
Specifically this is accomplished by inverting the 7th most significant bit of the
Ethernet MAC address, called the Universal/Local (U/L) bit, and then inserting 16
bits of padding in the format FFFE in the middle.
From the above output we can see that the EUI-64 derived host address of R1’s
Fa0/0 interface is 20D:65FF:FE84:6560. This means that the MAC address of
R1’s Fa0/0 interface is 000D:6584:6560. Note that the link-local address of the
interface automatically uses the format FE80::[EUI-64] unless manually modified.
Rack1R1#show interfaces fastEthernet 0/0 | include add
Hardware is Gt96k FE, address is c200.0b0c.0000 (bia c200.0b0c.0000)
Internet address is 155.1.146.1/24
Rack1R1#
Rack1R1#
Rack1R1#show ipv6 interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C000:BFF:FE0C:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C000:BFF:FE0C:0, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF0C:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R1#
Rack1R4#sh interfaces fastEthernet 0/1 | include address
Hardware is Gt96k FE, address is c203.1230.0001 (bia c203.1230.0001)
Internet address is 155.1.146.4/24
Rack1R4#
Rack1R4#show ipv6 interface fa0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C003:12FF:FE30:1
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C003:12FF:FE30:1, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF30:1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R4#
Rack1R6#sh interfaces fastEthernet 0/0 | include address
Hardware is Gt96k FE, address is c205.1230.0000 (bia c205.1230.0000)
Rack1R6#
Rack1R6#show ipv6 interface fa0/0.146
FastEthernet0/0.146 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C005:12FF:FE30:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C005:12FF:FE30:0, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF30:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R6#
• Configure globally aggregatable IPv6 addresses in the format
2001:X:0:146::Y/64 on the VLAN 146 interfaces of R1, R4, and R6.
• Here X is your rack number in decimal notation, (e.g. 10 for Rack10, not
the hex 0A) and the router will automatically derive Y based on the
interface MAC address.
--------------------------------------------------------
R1:
interface FastEthernet 0/0
ipv6 address 2001:1:0:146::/64 eui-64
R4:
interface FastEthernet 0/1
ipv6 address 2001:1:0:146::/64 eui-64
R6:
interface FastEthernet 0/0.146
ipv6 address 2001:1:0:146::/64 eui-64
--------------------------------------------------------
Extended Unique Identifiers (EUIs) are 64-bit values assigned to physical
interfaces. EUI’s are similar in many respects to IEEE MAC addresses, in that
they identity a physical interface, but EUI’s are designed to be used universally,
not just with the hardware addresses.
IPv6 uses EUI-64 to construct a unique host address on a shared Ethernet
segment automatically. When you use the eui-64 keyword, the IOS uses the
48-bit hardware address of the Ethernet interface as the foundation to construct
the unique 64-bit Interface identifier of the IPv6 address.
Specifically this is accomplished by inverting the 7th most significant bit of the
Ethernet MAC address, called the Universal/Local (U/L) bit, and then inserting 16
bits of padding in the format FFFE in the middle.
From the above output we can see that the EUI-64 derived host address of R1’s
Fa0/0 interface is 20D:65FF:FE84:6560. This means that the MAC address of
R1’s Fa0/0 interface is 000D:6584:6560. Note that the link-local address of the
interface automatically uses the format FE80::[EUI-64] unless manually modified.
Rack1R1#show interfaces fastEthernet 0/0 | include add
Hardware is Gt96k FE, address is c200.0b0c.0000 (bia c200.0b0c.0000)
Internet address is 155.1.146.1/24
Rack1R1#
Rack1R1#
Rack1R1#show ipv6 interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C000:BFF:FE0C:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C000:BFF:FE0C:0, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF0C:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R1#
Rack1R4#sh interfaces fastEthernet 0/1 | include address
Hardware is Gt96k FE, address is c203.1230.0001 (bia c203.1230.0001)
Internet address is 155.1.146.4/24
Rack1R4#
Rack1R4#show ipv6 interface fa0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C003:12FF:FE30:1
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C003:12FF:FE30:1, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF30:1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R4#
Rack1R6#sh interfaces fastEthernet 0/0 | include address
Hardware is Gt96k FE, address is c205.1230.0000 (bia c205.1230.0000)
Rack1R6#
Rack1R6#show ipv6 interface fa0/0.146
FastEthernet0/0.146 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C005:12FF:FE30:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1:0:146:C005:12FF:FE30:0, subnet is 2001:1:0:146::/64 [EUI]
Joined group address(es):
FF02::1
FF02::1:FF30:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Rack1R6#
WB1 9.3 IPv6 Global Aggregatable Addressing
9.3 IPv6 Global Aggregatable Addressing
• Configure globally aggregatable IPv6 addresses in the format
2001:X:0:1234::Y/64 on the Frame-Relay interfaces of R1, R2, R3, R4,
and R5.
Here X is your rack number in decimal notation, (e.g. 10 for Rack 10, not
the hex 0A) and Y is your router number (7 for SW1).
-----------------
R1:
interface Serial 0/0
ipv6 address 2001:1:0:1234::1/64
frame-relay map ipv6 2001:1:0:1234::5 105
frame-relay map ipv6 2001:1:0:1234::2 105
frame-relay map ipv6 2001:1:0:1234::3 105
frame-relay map ipv6 2001:1:0:1234::4 105
R2:
interface Serial 0/0
ipv6 address 2001:1:0:1234::2/64
frame-relay map ipv6 2001:1:0:1234::5 205
frame-relay map ipv6 2001:1:0:1234::1 205
frame-relay map ipv6 2001:1:0:1234::3 205
frame-relay map ipv6 2001:1:0:1234::4 205
R3:
interface Serial 1/0
ipv6 address 2001:1:0:1234::3/64
frame-relay map ipv6 2001:1:0:1234::5 305
frame-relay map ipv6 2001:1:0:1234::1 305
frame-relay map ipv6 2001:1:0:1234::2 305
frame-relay map ipv6 2001:1:0:1234::4 305
R4:
interface Serial 0/0/0
ipv6 address 2001:1:0:1234::4/64
frame-relay map ipv6 2001:1:0:1234::5 405
frame-relay map ipv6 2001:1:0:1234::1 405
frame-relay map ipv6 2001:1:0:1234::2 405
frame-relay map ipv6 2001:1:0:1234::3 405
R5:
interface Serial 0/0/0
ipv6 address 2001:1:0:1234::5/64
frame-relay map ipv6 2001:1:0:1234::1 501
frame-relay map ipv6 2001:1:0:1234::2 502
frame-relay map ipv6 2001:1:0:1234::3 503
frame-relay map ipv6 2001:1:0:1234::4 504
-----------------
Globally Aggregatable IPv6 addresses, AKA global unicast addresses, are
publicly allocated and routable on the Internet. Global unicast addresses start
with the binary prefix 001 (2000::/3), and therefore encompass the range 2000:: -
3FFF::. By design the allocation of these addresses through Internet registries
such as ARIN and APNIC are hierarchical, unlike IPv4 allocation. RIPE-450 (IPv6
Address Allocation and Assignment Policy) defines this hierarchical design
methodology.
Although this range is extremely large – 1/8th of the total IPv6 address space –
generally only the prefix 2001::/16 is currently used for allocation. Other ranges,
such as the 6to4 Tunnel range of 2002::/16, are generally used for special
purposes.
Once assigned, the behavior of a global unicast address is identical to that of a
ULA address, but as its name implies it has global routing significance.
-----------------
Rack1R5#
ping 2001:1:0:1234::1
ping 2001:1:0:1234::2
ping 2001:1:0:1234::3
ping 2001:1:0:1234::4
ping 2001:1:0:1234::5
show frame-relay map
• Configure globally aggregatable IPv6 addresses in the format
2001:X:0:1234::Y/64 on the Frame-Relay interfaces of R1, R2, R3, R4,
and R5.
Here X is your rack number in decimal notation, (e.g. 10 for Rack 10, not
the hex 0A) and Y is your router number (7 for SW1).
-----------------
R1:
interface Serial 0/0
ipv6 address 2001:1:0:1234::1/64
frame-relay map ipv6 2001:1:0:1234::5 105
frame-relay map ipv6 2001:1:0:1234::2 105
frame-relay map ipv6 2001:1:0:1234::3 105
frame-relay map ipv6 2001:1:0:1234::4 105
R2:
interface Serial 0/0
ipv6 address 2001:1:0:1234::2/64
frame-relay map ipv6 2001:1:0:1234::5 205
frame-relay map ipv6 2001:1:0:1234::1 205
frame-relay map ipv6 2001:1:0:1234::3 205
frame-relay map ipv6 2001:1:0:1234::4 205
R3:
interface Serial 1/0
ipv6 address 2001:1:0:1234::3/64
frame-relay map ipv6 2001:1:0:1234::5 305
frame-relay map ipv6 2001:1:0:1234::1 305
frame-relay map ipv6 2001:1:0:1234::2 305
frame-relay map ipv6 2001:1:0:1234::4 305
R4:
interface Serial 0/0/0
ipv6 address 2001:1:0:1234::4/64
frame-relay map ipv6 2001:1:0:1234::5 405
frame-relay map ipv6 2001:1:0:1234::1 405
frame-relay map ipv6 2001:1:0:1234::2 405
frame-relay map ipv6 2001:1:0:1234::3 405
R5:
interface Serial 0/0/0
ipv6 address 2001:1:0:1234::5/64
frame-relay map ipv6 2001:1:0:1234::1 501
frame-relay map ipv6 2001:1:0:1234::2 502
frame-relay map ipv6 2001:1:0:1234::3 503
frame-relay map ipv6 2001:1:0:1234::4 504
-----------------
Globally Aggregatable IPv6 addresses, AKA global unicast addresses, are
publicly allocated and routable on the Internet. Global unicast addresses start
with the binary prefix 001 (2000::/3), and therefore encompass the range 2000:: -
3FFF::. By design the allocation of these addresses through Internet registries
such as ARIN and APNIC are hierarchical, unlike IPv4 allocation. RIPE-450 (IPv6
Address Allocation and Assignment Policy) defines this hierarchical design
methodology.
Although this range is extremely large – 1/8th of the total IPv6 address space –
generally only the prefix 2001::/16 is currently used for allocation. Other ranges,
such as the 6to4 Tunnel range of 2002::/16, are generally used for special
purposes.
Once assigned, the behavior of a global unicast address is identical to that of a
ULA address, but as its name implies it has global routing significance.
-----------------
Rack1R5#
ping 2001:1:0:1234::1
ping 2001:1:0:1234::2
ping 2001:1:0:1234::3
ping 2001:1:0:1234::4
ping 2001:1:0:1234::5
show frame-relay map
2013/12/01
WB1 9.2 IPv6 Unique Local Addressing
9.2 IPv6 Unique Local Addressing
• Enable IPv6 processing on the links between R6 & SW1 and R3 & SW1.
• Use the ULA IPv6 prefixes FC00:X:0:67::Y/64 and FC00:X:0:37::Y/64 for
the links between SW1 & R6 and R3 & SW1 respectively.
• Here X is your rack number in decimal notation, (e.g. 10 for Rack10, not
the hex 0A) and Y is your router number (7 for SW1).
-----------------------------------------------------------
It is necessary to change the SDM (Switch Database Manager) template for the
3560 switches in order to configure IPv6 addressing. Changes to the running
SDM preferences will be stored in memory. Reload the switch for them to take
effect.
SW1:
sdm prefer dual-ipv4-and-ipv6 routing
exit
wr
reload
-----------------------------------------------------------
R3:
interface FastEthernet 0/0
ipv6 address FC00:1:0:37::3/64
R6:
interface FastEthernet 0/0.67
ipv6 address FC00:1:0:67::6/64
SW1:
sdm prefer dual-ipv4-and-ipv6 routing
!
interface FastEthernet 0/3
ipv6 address FC00:1:0:37::7/64
!
interface Vlan 67
ipv6 address FC00:1:0:67::7/64
!
-----------------------------------------------------------
Unique Local IPv6 Unicast Addressing (ULA), defined in RFC 4193, deprecates
the previously used Site-Local (FEC0::/10) addressing. ULA addresses in IPv6
are synonymous with the RFC 1918 private addresses found in IPv4, i.e. the
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 prefixes. Considered private, ULA
addresses are not publicly routable prefixes on the Internet.
The format of the ULA is:
FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits).
The randomly generated Unique ID helps avoid address collisions. Other than
the addressing format, ULA addressing exhibits no other unique behavior when
compared to normal publicly routable IPv6 addresses.
-----------------------------------------------------------
• Enable IPv6 processing on the links between R6 & SW1 and R3 & SW1.
• Use the ULA IPv6 prefixes FC00:X:0:67::Y/64 and FC00:X:0:37::Y/64 for
the links between SW1 & R6 and R3 & SW1 respectively.
• Here X is your rack number in decimal notation, (e.g. 10 for Rack10, not
the hex 0A) and Y is your router number (7 for SW1).
-----------------------------------------------------------
It is necessary to change the SDM (Switch Database Manager) template for the
3560 switches in order to configure IPv6 addressing. Changes to the running
SDM preferences will be stored in memory. Reload the switch for them to take
effect.
SW1:
sdm prefer dual-ipv4-and-ipv6 routing
exit
wr
reload
-----------------------------------------------------------
R3:
interface FastEthernet 0/0
ipv6 address FC00:1:0:37::3/64
R6:
interface FastEthernet 0/0.67
ipv6 address FC00:1:0:67::6/64
SW1:
sdm prefer dual-ipv4-and-ipv6 routing
!
interface FastEthernet 0/3
ipv6 address FC00:1:0:37::7/64
!
interface Vlan 67
ipv6 address FC00:1:0:67::7/64
!
-----------------------------------------------------------
Unique Local IPv6 Unicast Addressing (ULA), defined in RFC 4193, deprecates
the previously used Site-Local (FEC0::/10) addressing. ULA addresses in IPv6
are synonymous with the RFC 1918 private addresses found in IPv4, i.e. the
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 prefixes. Considered private, ULA
addresses are not publicly routable prefixes on the Internet.
The format of the ULA is:
FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) + Interface ID (64 bits).
The randomly generated Unique ID helps avoid address collisions. Other than
the addressing format, ULA addressing exhibits no other unique behavior when
compared to normal publicly routable IPv6 addresses.
-----------------------------------------------------------
WB1 9.1 IPv6 Link-Local Addressing
9.1 IPv6 Link-Local Addressing
• Configure link-local IPv6 addresses on the Frame-Relay cloud between
R1, R2, R3, R4, and R5.
• Use the IPv6 addressing format FE80::Y, where Y is the router number.
--------------------------------
R1:
interface Serial 0/0
ipv6 address fe80::1 link-local
frame-relay map ipv6 fe80::5 105 broadcast
frame-relay map ipv6 fe80::2 105
frame-relay map ipv6 fe80::3 105
frame-relay map ipv6 fe80::4 105
R2:
interface Serial 0/0
ipv6 address fe80::2 link-local
frame-relay map ipv6 fe80::5 205 broadcast
frame-relay map ipv6 fe80::1 205
frame-relay map ipv6 fe80::3 205
frame-relay map ipv6 fe80::4 205
R3:
interface Serial 1/0
ipv6 address fe80::3 link-local
frame-relay map ipv6 fe80::5 305 broadcast
frame-relay map ipv6 fe80::1 305
frame-relay map ipv6 fe80::2 305
frame-relay map ipv6 fe80::4 305
R4:
interface Serial 0/0/0
ipv6 address fe80::4 link-local
frame-relay map ipv6 fe80::5 405 broadcast
frame-relay map ipv6 fe80::1 405
frame-relay map ipv6 fe80::2 405
frame-relay map ipv6 fe80::3 405
R5:
interface Serial 0/0/0
ipv6 address fe80::5 link-local
frame-relay map ipv6 fe80::1 501 broadcast
frame-relay map ipv6 fe80::2 502 broadcast
frame-relay map ipv6 fe80::3 503 broadcast
frame-relay map ipv6 fe80::4 504 broadcast
--------------------------------
Link-local IPv6 addresses are significant only within the context of a single link.
This means that packets with link-local addresses cannot be routed between
interfaces, and link-local addresses may overlap as long as they exist on different
interfaces. The address format for IPv6 link-local addresses are FE80::/10, and
they are synonymous with the range 169.254.0.0/16 in IPv4.
Packets with link-local sources or destinations are mostly used by the router’s
control plane protocols, such as IPv6 routing protocols. For broadcast segments,
such as Ethernet, link-local reachability is implicit due to automatic resolution
through ICMP Neighbor Discovery (ICMPND). However, since multipoint NBMA
interfaces do not support Inverse ICMPND, it is necessary to ensure link-local
IPv6 address reachability over these links by configuring static mappings.
Without these mappings, routing protocols may not be able to establish
adjacencies or properly encapsulate packets.
--------------------------------
Rack1R5# show frame-relay map
When pinging link-local addresses it is necessary to tell the router which interface
to send traffic out. Since the link-local address can exist on multiple interfaces
the router, requires you to indicate the “Output Interface”. You must specify the
interface using the full interface name without spaces (e.g. Serial0/0/0)
Rack1R5# ping ipv6 fe80::1
Output Interface: Serial0/0Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::1, timeout is 2 seconds:
Packet sent with a source address of FE80::5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/61/80 ms
• Configure link-local IPv6 addresses on the Frame-Relay cloud between
R1, R2, R3, R4, and R5.
• Use the IPv6 addressing format FE80::Y, where Y is the router number.
--------------------------------
R1:
interface Serial 0/0
ipv6 address fe80::1 link-local
frame-relay map ipv6 fe80::5 105 broadcast
frame-relay map ipv6 fe80::2 105
frame-relay map ipv6 fe80::3 105
frame-relay map ipv6 fe80::4 105
R2:
interface Serial 0/0
ipv6 address fe80::2 link-local
frame-relay map ipv6 fe80::5 205 broadcast
frame-relay map ipv6 fe80::1 205
frame-relay map ipv6 fe80::3 205
frame-relay map ipv6 fe80::4 205
R3:
interface Serial 1/0
ipv6 address fe80::3 link-local
frame-relay map ipv6 fe80::5 305 broadcast
frame-relay map ipv6 fe80::1 305
frame-relay map ipv6 fe80::2 305
frame-relay map ipv6 fe80::4 305
R4:
interface Serial 0/0/0
ipv6 address fe80::4 link-local
frame-relay map ipv6 fe80::5 405 broadcast
frame-relay map ipv6 fe80::1 405
frame-relay map ipv6 fe80::2 405
frame-relay map ipv6 fe80::3 405
R5:
interface Serial 0/0/0
ipv6 address fe80::5 link-local
frame-relay map ipv6 fe80::1 501 broadcast
frame-relay map ipv6 fe80::2 502 broadcast
frame-relay map ipv6 fe80::3 503 broadcast
frame-relay map ipv6 fe80::4 504 broadcast
--------------------------------
Link-local IPv6 addresses are significant only within the context of a single link.
This means that packets with link-local addresses cannot be routed between
interfaces, and link-local addresses may overlap as long as they exist on different
interfaces. The address format for IPv6 link-local addresses are FE80::/10, and
they are synonymous with the range 169.254.0.0/16 in IPv4.
Packets with link-local sources or destinations are mostly used by the router’s
control plane protocols, such as IPv6 routing protocols. For broadcast segments,
such as Ethernet, link-local reachability is implicit due to automatic resolution
through ICMP Neighbor Discovery (ICMPND). However, since multipoint NBMA
interfaces do not support Inverse ICMPND, it is necessary to ensure link-local
IPv6 address reachability over these links by configuring static mappings.
Without these mappings, routing protocols may not be able to establish
adjacencies or properly encapsulate packets.
--------------------------------
Rack1R5# show frame-relay map
When pinging link-local addresses it is necessary to tell the router which interface
to send traffic out. Since the link-local address can exist on multiple interfaces
the router, requires you to indicate the “Output Interface”. You must specify the
interface using the full interface name without spaces (e.g. Serial0/0/0)
Rack1R5# ping ipv6 fe80::1
Output Interface: Serial0/0Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::1, timeout is 2 seconds:
Packet sent with a source address of FE80::5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/61/80 ms
WB1 8.34 Catalyst IGMP Profiles
8.34 Catalyst IGMP Profiles
• Configure SW4 to permit only the IGMP reports for groups in ranges
232.0.0.0/8 and 239.0.0.0/8 from R4.
---------------------------------------------------------
Catalyst switches allow filtering of IGMP messages sent by directly connected
hosts to multicast routers. This feature is similar to the ip igmp access-group
command used on routers, but this command applies to transit IGMP
messages. This functionality is accomplished by using IGMP profiles. IGMP
profiles have global numbers, and every profile defines a list of ranges plus the
accompanying operation – “permit” or “deny” (default). In the first case, the
switch permits IGMP reports for the groups specified by the range and denies
everything else. In the second case, the switch denies the group range
configured and permits everything else. To configure the profile, use the
command
ip igmp profile <global-number>
range low-address1 [high-address1]
range low-address2 [high-address2]
...
[permit|deny]
The profile applies ingress to layer 2 ports only using the interface-level
command ip igmp filter <number> and affects all IGMP reports sent by
hosts connected to the particular port.
--------------------------------------------------
SW4:
ip igmp profile 1
permit
range 232.0.0.0 232.255.255.255
range 239.0.0.0 239.255.255.255
!
interface FastEthernet 0/4
ip igmp filter 1
---------------------------------------------------------
Join R4’s VLAN 146 interface to a couple of groups. One group should match the
profile criteria, while the other should not. After this, verify what IGMP groups are
seen on the switch, using the IGMP snooping function.
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
R4:
interface FastEthernet0/1
ip igmp join-group 232.4.4.4
ip igmp join-group 233.4.4.4
ip igmp join-group 234.4.4.4
ip igmp join-group 239.4.4.4
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 232.4.4.4 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
146 239.4.4.4 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
• Configure SW4 to permit only the IGMP reports for groups in ranges
232.0.0.0/8 and 239.0.0.0/8 from R4.
---------------------------------------------------------
Catalyst switches allow filtering of IGMP messages sent by directly connected
hosts to multicast routers. This feature is similar to the ip igmp access-group
command used on routers, but this command applies to transit IGMP
messages. This functionality is accomplished by using IGMP profiles. IGMP
profiles have global numbers, and every profile defines a list of ranges plus the
accompanying operation – “permit” or “deny” (default). In the first case, the
switch permits IGMP reports for the groups specified by the range and denies
everything else. In the second case, the switch denies the group range
configured and permits everything else. To configure the profile, use the
command
ip igmp profile <global-number>
range low-address1 [high-address1]
range low-address2 [high-address2]
...
[permit|deny]
The profile applies ingress to layer 2 ports only using the interface-level
command ip igmp filter <number> and affects all IGMP reports sent by
hosts connected to the particular port.
--------------------------------------------------
SW4:
ip igmp profile 1
permit
range 232.0.0.0 232.255.255.255
range 239.0.0.0 239.255.255.255
!
interface FastEthernet 0/4
ip igmp filter 1
---------------------------------------------------------
Join R4’s VLAN 146 interface to a couple of groups. One group should match the
profile criteria, while the other should not. After this, verify what IGMP groups are
seen on the switch, using the IGMP snooping function.
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
R4:
interface FastEthernet0/1
ip igmp join-group 232.4.4.4
ip igmp join-group 233.4.4.4
ip igmp join-group 234.4.4.4
ip igmp join-group 239.4.4.4
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 232.4.4.4 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
146 239.4.4.4 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
WB1 8.33 Catalyst Multicast VLAN Registration
8.33 Catalyst Multicast VLAN Registration
• Configure SW1 so that multicast traffic sent by R1 on VLAN 146 is
received by R5 on VLAN 58.
• Use the configuration that allows R1 to dynamically tracking sources in
other VLANs.
------------------------------
Multicast VLAN registration (MVR) is a special type of multicast traffic delivery
suited to the access layer of metro Ethernet networks, especially for ring
topologies. In these networks, it is common to allocate a VLAN based on a
network’s geographic region. In this configuration, when you send a video
multicast feed to receivers on multiple VLANs, the feed will be replicated for
every VLAN across the ring topology, causing bandwidth over-utilization.
MVR uses a single dedicated VLAN across the whole ring to deliver a multicast
feed to all receivers. The actual receivers reside in different VLANs, but the
switches intercept their IGMP Join requests and pull the multicast feed from the
MVR VLAN to the receiver VLAN. Thus, MVR allows multicast traffic to cross
VLAN boundaries based on client IGMP reports. This function is similar to IGMP
snooping, but the two work independently. You can have both features enable on
the switch, but MVR will only inspect IGMP reports for groups explicitly
configured to be supported by MVR.
There are two modes for the MVR feature: dynamic and compatible. Before we
look into the differences, notice that that MVR and multicast routing are mutually
exclusive. When MVR is enabled, the switch performs like a Layer 2 device with
respect to multicast traffic, and multicast-routing should remain disabled.
However, the switch still inspects IGMP messages and may forward them to the
port where a multicast router is connected or not. Back to the modes - the first
mode is called dynamic. This mode allows the multicast router connected to the
switch ring to listen to the IGMP messages and dynamically create respective
mroute states. That is, IGMP join messages from the clients are forwarded to the
multicast source port, allowing the broadcast of unneeded channels to be
stopped. The other mode, called compatible (the default in switches), inspects
the IGMP messages but does not forward them to multicast router ports. This
was the default mode of operation of the MVR feature in 3500XL switches. If you
use compatible mode, make sure you configured static IGMP joins on the
multicast router to feed the multicast streams down. The default mode assumes
that the source constantly sends down all multicast channels, and does not
process client IGMP joins.
Configure MVR by follow the steps below:
Step 1:
Enable MVR globally using the commands mvr and mvr group <mcastgroup>
<count>. This will enable the MVR feature for the particular group or
for the number of groups specified by the <count> argument and starting at
<mcast-group> address. Note that you cannot have more than 256 address
configured for MVR, and they should never alias. Here aliasing means that two
multicast IP addresses map to the same multicast MAC address (see the
previous task). For example addresses 228.1.1.1 and 230.1.1.1 would alias to
the same MAC address and would be rejected.
Step 2:
Define the MVR VLAN – this is the VLAN that will span multiple switches and
carry the actual multicast traffic feed. This VLAN should be allowed on all trunks
to permit multicast delivery. The command is mvr vlan <vlan-id>. You may
also define the MVR mode by using the command mvr {dynamic|compatible}
Step 3:
Configure the source and receiver interfaces, using the interface-mode command
mvr type {source|receiver}. Additionally, you may configure ports for
immediate leave, using the command mvr immediate. When this command is
enabled, any single IGMP Leave would cause the switch to prune the port from
receiving multicast feeds. This is good for the ports that have only one host
connected.
Step 4:
Optionally, configure static group joins using the command mvr vlan <vlanid>
group <ip-address> on receiver ports. This is similar to the static join
command configured ona router, but it allows pulling multicast traffic from the
MVR VLAN. Another optional command is mvr querytime <1/10 of
second>. This command is similar to the igmp query-max-response-time
configured on routers. The switch passively listens to IGMP general
queries sent from multicast routers, and then starts the querytime timer,
waiting for client replies. If no replies are received during the interval, the switch
prunes the port from the list of output ports for the group.
Notice that you cannot configure trunk ports as MVR receivers.
SW1:
no ip multicast-routing distributed
mvr
mvr vlan 146
mvr group 239.1.1.100
mvr mode dynamic
!
interface FastEthernet 0/1
mvr type source
!
interface FastEthernet 0/5
mvr type receiver
---------------------------------------------
Check the MVR settings on SW1. Since the mode is dynamic, R1 should receive
IGMP Joins from R5.
Rack1SW1#show mvr
MVR Running: TRUE
MVR multicast VLAN: 146
MVR Max Multicast Groups: 256
MVR Current multicast groups: 1
MVR Global query response time: 5 (tenths of sec)
MVR Mode: dynamic
Rack1SW1#
Rack1SW1#show mvr interface
Port Type Status Immediate Leave
---- ---- ------ ---------------
Fa1/0/1 SOURCE ACTIVE/UP DISABLED
Fa1/0/5 RECEIVER ACTIVE/UP DISABLED
Rack1SW1#
Rack1SW1#show mvr members
MVR Group IP Status Members
------------ ------ -------
239.001.001.100 ACTIVE Fa1/0/1(d)
Rack1SW1#
在R5上啟動Multicast，將Fa0/0加入239.1.1.100的group中
R5:
ip multicast-routing
interface FastEthernet 0/0
ip pim dense-mode
ip igmp join-group 239.1.1.100
Rack1SW1#show mvr members
MVR Group IP Status Members
------------ ------ -------
239.001.001.100 ACTIVE Fa1/0/1(d), Fa1/0/5(d)
Rack1SW1#
Rack1R1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:26:18 00:02:49 155.1.58.5
224.0.1.40 FastEthernet0/0 00:26:28 00:02:21 155.1.146.6
Rack1R1#
Now source the multicast feed from R1 and check that R5 actually receives the
multicast packets by using the appropriate debug command. Notice that you will
need to disable multicast route caching on R5 for this to work.
Rack1R1#ping 239.1.1.100 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
...
Rack1R5#debug ip mpacket
IP multicast packets debugging is on
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=89, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=90, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=91, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
• Configure SW1 so that multicast traffic sent by R1 on VLAN 146 is
received by R5 on VLAN 58.
• Use the configuration that allows R1 to dynamically tracking sources in
other VLANs.
------------------------------
Multicast VLAN registration (MVR) is a special type of multicast traffic delivery
suited to the access layer of metro Ethernet networks, especially for ring
topologies. In these networks, it is common to allocate a VLAN based on a
network’s geographic region. In this configuration, when you send a video
multicast feed to receivers on multiple VLANs, the feed will be replicated for
every VLAN across the ring topology, causing bandwidth over-utilization.
MVR uses a single dedicated VLAN across the whole ring to deliver a multicast
feed to all receivers. The actual receivers reside in different VLANs, but the
switches intercept their IGMP Join requests and pull the multicast feed from the
MVR VLAN to the receiver VLAN. Thus, MVR allows multicast traffic to cross
VLAN boundaries based on client IGMP reports. This function is similar to IGMP
snooping, but the two work independently. You can have both features enable on
the switch, but MVR will only inspect IGMP reports for groups explicitly
configured to be supported by MVR.
There are two modes for the MVR feature: dynamic and compatible. Before we
look into the differences, notice that that MVR and multicast routing are mutually
exclusive. When MVR is enabled, the switch performs like a Layer 2 device with
respect to multicast traffic, and multicast-routing should remain disabled.
However, the switch still inspects IGMP messages and may forward them to the
port where a multicast router is connected or not. Back to the modes - the first
mode is called dynamic. This mode allows the multicast router connected to the
switch ring to listen to the IGMP messages and dynamically create respective
mroute states. That is, IGMP join messages from the clients are forwarded to the
multicast source port, allowing the broadcast of unneeded channels to be
stopped. The other mode, called compatible (the default in switches), inspects
the IGMP messages but does not forward them to multicast router ports. This
was the default mode of operation of the MVR feature in 3500XL switches. If you
use compatible mode, make sure you configured static IGMP joins on the
multicast router to feed the multicast streams down. The default mode assumes
that the source constantly sends down all multicast channels, and does not
process client IGMP joins.
Configure MVR by follow the steps below:
Step 1:
Enable MVR globally using the commands mvr and mvr group <mcastgroup>
<count>. This will enable the MVR feature for the particular group or
for the number of groups specified by the <count> argument and starting at
<mcast-group> address. Note that you cannot have more than 256 address
configured for MVR, and they should never alias. Here aliasing means that two
multicast IP addresses map to the same multicast MAC address (see the
previous task). For example addresses 228.1.1.1 and 230.1.1.1 would alias to
the same MAC address and would be rejected.
Step 2:
Define the MVR VLAN – this is the VLAN that will span multiple switches and
carry the actual multicast traffic feed. This VLAN should be allowed on all trunks
to permit multicast delivery. The command is mvr vlan <vlan-id>. You may
also define the MVR mode by using the command mvr {dynamic|compatible}
Step 3:
Configure the source and receiver interfaces, using the interface-mode command
mvr type {source|receiver}. Additionally, you may configure ports for
immediate leave, using the command mvr immediate. When this command is
enabled, any single IGMP Leave would cause the switch to prune the port from
receiving multicast feeds. This is good for the ports that have only one host
connected.
Step 4:
Optionally, configure static group joins using the command mvr vlan <vlanid>
group <ip-address> on receiver ports. This is similar to the static join
command configured ona router, but it allows pulling multicast traffic from the
MVR VLAN. Another optional command is mvr querytime <1/10 of
second>. This command is similar to the igmp query-max-response-time
configured on routers. The switch passively listens to IGMP general
queries sent from multicast routers, and then starts the querytime timer,
waiting for client replies. If no replies are received during the interval, the switch
prunes the port from the list of output ports for the group.
Notice that you cannot configure trunk ports as MVR receivers.
SW1:
no ip multicast-routing distributed
mvr
mvr vlan 146
mvr group 239.1.1.100
mvr mode dynamic
!
interface FastEthernet 0/1
mvr type source
!
interface FastEthernet 0/5
mvr type receiver
---------------------------------------------
Check the MVR settings on SW1. Since the mode is dynamic, R1 should receive
IGMP Joins from R5.
Rack1SW1#show mvr
MVR Running: TRUE
MVR multicast VLAN: 146
MVR Max Multicast Groups: 256
MVR Current multicast groups: 1
MVR Global query response time: 5 (tenths of sec)
MVR Mode: dynamic
Rack1SW1#
Rack1SW1#show mvr interface
Port Type Status Immediate Leave
---- ---- ------ ---------------
Fa1/0/1 SOURCE ACTIVE/UP DISABLED
Fa1/0/5 RECEIVER ACTIVE/UP DISABLED
Rack1SW1#
Rack1SW1#show mvr members
MVR Group IP Status Members
------------ ------ -------
239.001.001.100 ACTIVE Fa1/0/1(d)
Rack1SW1#
在R5上啟動Multicast，將Fa0/0加入239.1.1.100的group中
R5:
ip multicast-routing
interface FastEthernet 0/0
ip pim dense-mode
ip igmp join-group 239.1.1.100
Rack1SW1#show mvr members
MVR Group IP Status Members
------------ ------ -------
239.001.001.100 ACTIVE Fa1/0/1(d), Fa1/0/5(d)
Rack1SW1#
Rack1R1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:26:18 00:02:49 155.1.58.5
224.0.1.40 FastEthernet0/0 00:26:28 00:02:21 155.1.146.6
Rack1R1#
Now source the multicast feed from R1 and check that R5 actually receives the
multicast packets by using the appropriate debug command. Notice that you will
need to disable multicast route caching on R5 for this to work.
Rack1R1#ping 239.1.1.100 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
...
Rack1R5#debug ip mpacket
IP multicast packets debugging is on
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=89, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=90, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=91, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
WB1 8.32 Catalyst IGMP Snooping
8.32 Catalyst IGMP Snooping
• Configure R6’s Fa0/0 interface with the ip address 155.1.146.6/24
• Join the multicast group 239.1.1.100 on the VLAN 146 interfaces of R4
and R6.
• Configure the switches to assist in optimal traffic flooding across the
switched topology for VLAN 146.
• Ensure a switch stops flooding out of a given port as soon as it receives
an IGMPv2 report.
--------------------------------------------------
Multicast poses special difficulties in switched Ethernet networks. By default, IP
Multicast addresses are mapped to Ethernet multicast MAC addresses per the
following procedure:
1) The multicast Ethernet MAC address range starts at 01:00:5E:00:00:00 and
goes through 01:00:5E:7F:FF:FF. The highest bit of the 4th byte in these
addresses is fixed at 1, and thus only low-order 23 bits can vary. This allocation
is historical.
2) Based on this range, the low-order 23 bits of the multicast IP address are
mapped into the low-order 23 bits of the MAC address.
3) The high order 4 bits of the Layer 3 IP address is fixed to 1110 to indicate the
Class D address space between 224.0.0.0 and 239.255.255.255. Thus, 28 bits
remain for IP Multicast group numbering.
Therefore, there are 2^5 multicast groups mapped to the same multicast MAC
address. However, this is only a part of the puzzle. As you remember, Ethernet
switches flood multicast traffic out of all ports by default. In heavily loaded
networks, this might result in excessive bandwidth usage. In order to overcome
this issue, it’s possible for switches to listen to IGMP and PIM messages
received on Layer 2 ports. Based on the information snooped from these
messages, switches may selectively prune some ports from unneeded multicast
traffic. This procedure is called IGMP snooping and allows for selective multicast
flooding in switched networks.
Notice that in order to work effectively, IGMP snooping must be implemented on
Layer 3 capable switches. This is because Layer 2 devices cannot distinguish
IGMP and PIM packets from any other multicast frames, and must process all
multicast traffic at the CPU level. Thus, a layer 2 switch’s performance might be
severely impacted by intense multicast flows.
IGMP snooping is enabled by default on Catalyst multi-layer switches. Snooping
is enabled globally and on a per-VLAN basis. If you want to disable IGMP
snooping globally on all VLANs, use the command no ip igmp snooping.
Use the command no ip igmp snooping vlan <VLAN-ID> to disable it for
a single VLAN. Generally, switches automatically discover switchports connected
to multicast-capable routers by listening to PIM and DVMRP messages, and
flood all multicast groups on such ports. If you want to statically configure a port
as connected to a multicast router, use the command ip igmp snooping
vlan <vlan-id> mrouter interface <interface-id>.
If your switch has just one host connected to every layer 2 switch-port, you may
want to enable the IGMP Snooping Immediate Leave feature using the command
ip igmp snooping vlan <vlan-id> immediate-leave. When you
enable this feature, the switch will immediately remove a port from the flood list
for a given group once it receives the IGMPv2 Leave message on an interface
that is part of a particular group.
---------------------------------------------------------------
R1:
ip multicast-routing
!
interface FastEthernet0/0
ip address 155.1.146.1 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
R4:
ip multicast-routing
!
interface FastEthernet0/1
ip address 155.1.146.4 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
R6:
ip multicast-routing
!
interface FastEthernet0/0
ip address 155.1.146.6 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
SW1:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/1
switchport access vlan 146
SW2:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/6
switchport access vlan 146
SW4:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/4
switchport access vlan 146
!
---------------------------------------------------------------
First, check the IGMP Snooping general settings for VLAN 146. Notice that
“IGMPv2 immediate leave” is enabled for this VLAN.
Rack1SW1#show ip igmp snooping vlan 146
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 146:
--------
IGMP snooping : Enabled
IGMPv2 immediate leave : Enabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Rack1SW1#
---------------------------------------------------------------
Now join R1’s VLAN 146 interface to the IGMP group 239.1.1.100 and check that
IGMP snooping actually processes the IGMP packets. From the commands
output, you can see that there are two ports in the flood list for the group – one
for the receiver, and the other for the multicast router (R4).
R1:
interface FastEthernet 0/0
ip igmp join-group 239.1.1.100
Rack1SW1#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/1, Fa1/0/13,
Fa1/0/19
146 239.1.1.100 igmp v2 Fa1/0/1, Fa1/0/13,
Fa1/0/19
Rack1SW1#
Rack1SW1#sh ip igmp snooping mrouter vlan 146
Vlan ports
---- -----
146 Fa1/0/1(dynamic), Fa1/0/13(dynamic), Fa1/0/19(dynamic)
Rack1SW1#
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
Rack1SW4#show ip igmp snooping mrouter vlan 146
Vlan ports
---- -----
146 Fa1/0/4(dynamic), Fa1/0/13(dynamic)
Rack1SW4#
---------------------------------------------------------------
From R1 ping the multicast group:
R1:
Ping 239.1.1.100 repeat 1000
Multicast router information is learned via PIM messages. There are two
multicast routers on VLAN 146 – R4 and R6. Confirm that R4 actually receives
the IGMP report from R1.
Rack1R1#ping 239.1.1.100 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
Reply to request 0 from 155.1.146.1, 16 ms
Reply to request 1 from 155.1.146.1, 12 ms
Reply to request 1 from 155.1.146.4, 24 ms
Reply to request 1 from 155.1.146.6, 24 ms
Reply to request 2 from 155.1.146.4, 12 ms
Reply to request 2 from 155.1.146.6, 28 ms
Reply to request 2 from 155.1.146.1, 16 ms
Reply to request 3 from 155.1.146.1, 12 ms
Reply to request 3 from 155.1.146.6, 28 ms
Reply to request 3 from 155.1.146.4, 28 ms
Reply to request 4 from 155.1.146.1, 12 ms
Reply to request 4 from 155.1.146.4, 24 ms
Reply to request 4 from 155.1.146.6, 24 ms
Reply to request 5 from 155.1.146.1, 12 ms
Reply to request 5 from 155.1.146.4, 56 ms
Reply to request 5 from 155.1.146.6, 52 ms
Reply to request 6 from 155.1.146.1, 12 ms
Reply to request 6 from 155.1.146.4, 52 ms
Reply to request 6 from 155.1.146.6, 32 ms
Reply to request 7 from 155.1.146.1, 8 ms
Reply to request 7 from 155.1.146.4, 48 ms
Reply to request 7 from 155.1.146.6, 48 ms
Reply to request 8 from 155.1.146.1, 12 ms
Reply to request 8 from 155.1.146.4, 56 ms
Reply to request 8 from 155.1.146.6, 52 ms
Reply to request 9 from 155.1.146.1, 12 ms
Reply to request 9 from 155.1.146.4, 36 ms
Reply to request 9 from 155.1.146.6, 32 ms
Rack1R1#
Rack1R4#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/1 00:09:13 00:02:22 155.1.146.1
224.0.1.40 FastEthernet0/1 00:09:15 00:02:19 155.1.146.4
Rack1R4#
Rack1R6#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:09:26 00:01:55 155.1.146.1
224.0.1.40 FastEthernet0/0 00:09:28 00:02:59 155.1.146.6
Rack1R6#
Rack1R1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:10:06 00:02:38 155.1.146.6
224.0.1.40 FastEthernet0/0 00:10:16 00:02:31 155.1.146.6
Rack1R1#
• Configure R6’s Fa0/0 interface with the ip address 155.1.146.6/24
• Join the multicast group 239.1.1.100 on the VLAN 146 interfaces of R4
and R6.
• Configure the switches to assist in optimal traffic flooding across the
switched topology for VLAN 146.
• Ensure a switch stops flooding out of a given port as soon as it receives
an IGMPv2 report.
--------------------------------------------------
Multicast poses special difficulties in switched Ethernet networks. By default, IP
Multicast addresses are mapped to Ethernet multicast MAC addresses per the
following procedure:
1) The multicast Ethernet MAC address range starts at 01:00:5E:00:00:00 and
goes through 01:00:5E:7F:FF:FF. The highest bit of the 4th byte in these
addresses is fixed at 1, and thus only low-order 23 bits can vary. This allocation
is historical.
2) Based on this range, the low-order 23 bits of the multicast IP address are
mapped into the low-order 23 bits of the MAC address.
3) The high order 4 bits of the Layer 3 IP address is fixed to 1110 to indicate the
Class D address space between 224.0.0.0 and 239.255.255.255. Thus, 28 bits
remain for IP Multicast group numbering.
Therefore, there are 2^5 multicast groups mapped to the same multicast MAC
address. However, this is only a part of the puzzle. As you remember, Ethernet
switches flood multicast traffic out of all ports by default. In heavily loaded
networks, this might result in excessive bandwidth usage. In order to overcome
this issue, it’s possible for switches to listen to IGMP and PIM messages
received on Layer 2 ports. Based on the information snooped from these
messages, switches may selectively prune some ports from unneeded multicast
traffic. This procedure is called IGMP snooping and allows for selective multicast
flooding in switched networks.
Notice that in order to work effectively, IGMP snooping must be implemented on
Layer 3 capable switches. This is because Layer 2 devices cannot distinguish
IGMP and PIM packets from any other multicast frames, and must process all
multicast traffic at the CPU level. Thus, a layer 2 switch’s performance might be
severely impacted by intense multicast flows.
IGMP snooping is enabled by default on Catalyst multi-layer switches. Snooping
is enabled globally and on a per-VLAN basis. If you want to disable IGMP
snooping globally on all VLANs, use the command no ip igmp snooping.
Use the command no ip igmp snooping vlan <VLAN-ID> to disable it for
a single VLAN. Generally, switches automatically discover switchports connected
to multicast-capable routers by listening to PIM and DVMRP messages, and
flood all multicast groups on such ports. If you want to statically configure a port
as connected to a multicast router, use the command ip igmp snooping
vlan <vlan-id> mrouter interface <interface-id>.
If your switch has just one host connected to every layer 2 switch-port, you may
want to enable the IGMP Snooping Immediate Leave feature using the command
ip igmp snooping vlan <vlan-id> immediate-leave. When you
enable this feature, the switch will immediately remove a port from the flood list
for a given group once it receives the IGMPv2 Leave message on an interface
that is part of a particular group.
---------------------------------------------------------------
R1:
ip multicast-routing
!
interface FastEthernet0/0
ip address 155.1.146.1 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
R4:
ip multicast-routing
!
interface FastEthernet0/1
ip address 155.1.146.4 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
R6:
ip multicast-routing
!
interface FastEthernet0/0
ip address 155.1.146.6 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.100
SW1:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/1
switchport access vlan 146
SW2:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/6
switchport access vlan 146
SW4:
ip igmp snooping vlan 146 immediate-leave
!
interface FastEthernet0/4
switchport access vlan 146
!
---------------------------------------------------------------
First, check the IGMP Snooping general settings for VLAN 146. Notice that
“IGMPv2 immediate leave” is enabled for this VLAN.
Rack1SW1#show ip igmp snooping vlan 146
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Vlan 146:
--------
IGMP snooping : Enabled
IGMPv2 immediate leave : Enabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Rack1SW1#
---------------------------------------------------------------
Now join R1’s VLAN 146 interface to the IGMP group 239.1.1.100 and check that
IGMP snooping actually processes the IGMP packets. From the commands
output, you can see that there are two ports in the flood list for the group – one
for the receiver, and the other for the multicast router (R4).
R1:
interface FastEthernet 0/0
ip igmp join-group 239.1.1.100
Rack1SW1#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/1, Fa1/0/13,
Fa1/0/19
146 239.1.1.100 igmp v2 Fa1/0/1, Fa1/0/13,
Fa1/0/19
Rack1SW1#
Rack1SW1#sh ip igmp snooping mrouter vlan 146
Vlan ports
---- -----
146 Fa1/0/1(dynamic), Fa1/0/13(dynamic), Fa1/0/19(dynamic)
Rack1SW1#
Rack1SW4#show ip igmp snooping groups vlan 146
Vlan Group Type Version Port List
-----------------------------------------------------------------------
146 224.0.1.40 igmp v2 Fa1/0/4, Fa1/0/13
146 239.1.1.100 igmp v2 Fa1/0/4, Fa1/0/13
Rack1SW4#
Rack1SW4#show ip igmp snooping mrouter vlan 146
Vlan ports
---- -----
146 Fa1/0/4(dynamic), Fa1/0/13(dynamic)
Rack1SW4#
---------------------------------------------------------------
From R1 ping the multicast group:
R1:
Ping 239.1.1.100 repeat 1000
Multicast router information is learned via PIM messages. There are two
multicast routers on VLAN 146 – R4 and R6. Confirm that R4 actually receives
the IGMP report from R1.
Rack1R1#ping 239.1.1.100 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
Reply to request 0 from 155.1.146.1, 16 ms
Reply to request 1 from 155.1.146.1, 12 ms
Reply to request 1 from 155.1.146.4, 24 ms
Reply to request 1 from 155.1.146.6, 24 ms
Reply to request 2 from 155.1.146.4, 12 ms
Reply to request 2 from 155.1.146.6, 28 ms
Reply to request 2 from 155.1.146.1, 16 ms
Reply to request 3 from 155.1.146.1, 12 ms
Reply to request 3 from 155.1.146.6, 28 ms
Reply to request 3 from 155.1.146.4, 28 ms
Reply to request 4 from 155.1.146.1, 12 ms
Reply to request 4 from 155.1.146.4, 24 ms
Reply to request 4 from 155.1.146.6, 24 ms
Reply to request 5 from 155.1.146.1, 12 ms
Reply to request 5 from 155.1.146.4, 56 ms
Reply to request 5 from 155.1.146.6, 52 ms
Reply to request 6 from 155.1.146.1, 12 ms
Reply to request 6 from 155.1.146.4, 52 ms
Reply to request 6 from 155.1.146.6, 32 ms
Reply to request 7 from 155.1.146.1, 8 ms
Reply to request 7 from 155.1.146.4, 48 ms
Reply to request 7 from 155.1.146.6, 48 ms
Reply to request 8 from 155.1.146.1, 12 ms
Reply to request 8 from 155.1.146.4, 56 ms
Reply to request 8 from 155.1.146.6, 52 ms
Reply to request 9 from 155.1.146.1, 12 ms
Reply to request 9 from 155.1.146.4, 36 ms
Reply to request 9 from 155.1.146.6, 32 ms
Rack1R1#
Rack1R4#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/1 00:09:13 00:02:22 155.1.146.1
224.0.1.40 FastEthernet0/1 00:09:15 00:02:19 155.1.146.4
Rack1R4#
Rack1R6#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:09:26 00:01:55 155.1.146.1
224.0.1.40 FastEthernet0/0 00:09:28 00:02:59 155.1.146.6
Rack1R6#
Rack1R1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.100 FastEthernet0/0 00:10:06 00:02:38 155.1.146.6
224.0.1.40 FastEthernet0/0 00:10:16 00:02:31 155.1.146.6
Rack1R1#
訂閱：
文章 (Atom)