HCIE

Links

dumps written

Certifications question

vceguide

https://killexams.com/pass4sure/exam-detail/H12-261

https://www.killtest.com/HCIE-R-S/H12-261.asp

https://www.certshero.com/huawei/h12-261/practice-test

https://www.certshero.com/huawei/h12-261/practice-test

https://www.passcert.com/HCIE-R-S.html

https://cciedump.spoto.net/huawei-dumps.php

https://www.scribd.com/document/493418464/HCIE-R-S-Dumps-June-2020-Update-H12-261-ENU-V15-02-from-Netcert

labs

spoto 1

spoto huawei

https://591lab.com/product/huawei-hcie-routing-switching-lab/

https://www.spotoclub.com/overview-of-huawei-hcie-routing-and-switching-certification-exam-5749/

ADMINISTRATIVE DISTANCE

CONFIGURE IS-IS

Overview

  • NSAP - Network Service Access Point

  • IDP - The Initial Domain Part

  • DSP - The Domain Specific Part

  • AFI - Authority and Format Identifier (1 octet)

  • IDI - Initial Domain Identifier

  • LSP - Link State PDU

  • PDU - Protocol Data Unit

  • IIH - IS_IS Hello packet

  • DIS - Designeted IS

Authentication

Interface authentication: is configured in the interface view to authenticate Level-1 and Level-2 IS-to-IS Hello PDUs (IIHs).

Area authentication: is configured in the IS-IS process view to authenticate Level-1 CSNPs, PSNPs, and LSPs.

Routing domain authentication: is configured in the IS-IS process view to authenticate Level-2 CSNPS, PSNPs, and LSPs.

Fundamentals

A DIS is elected after a neighbor relationship is established. If there are multiple routers with the same highest priority on a broadcast network, the one with the largest MAC address is elected. The DISs at different levels can be the same router or different routers.

The establishment of a neighbor relationship on a P2P link is different from that on a broadcast link. A neighbor relationship on a P2P link can be established in 2-way or 3-way mode, as shown in Table 8-1. By default, the 3-way handshake mechanism is used to establish a neighbor relationship on a P2P link.

A new LSP is generated in any of the following situations:

  • Neighbor goes Up or Down.

  • related interface goes Up or Down.

  • Imported IP routes change.

  • Inter-area IP routes change.

  • A new metric value is configured for an interface.

  • Periodic updates occur.

NET

afi and idi определяют routing domain (autonomous system)

System ID - 1 to 8 octets , по умолчанию 6 байт

minimum 8 octets = AFI, System Id, SEL

maximum 20 octets =

читать net адрес надо с право налево

ISH - ISIS Hello

metric narrow - 1 - 63 - 6 bit for interface metric, complete path metric 1 - 1023 10 bit

metric wide - 24 bit for interface , complete path metric 32bit

Types of Packets:

  • Hello packet(3 вида пакетов - L1 и L2 для broadcast , L1L2 для p-t-p)

  • Link State PDU

  • Complete Sequence Numbers PDU (CSNP)

  • Partial Sequence Numbers PDU (PSNP)

Hello packet

On broadcast network use separate Hello packets for L1 and L2

On p-t-p network use single Hello packet L1L2

Hello interval - 10 sec Hold multiplier = 3

DIS посылает hello пакеты hello_interval/3 при 10 сек интервала, получается где-то 3,3 сек, это чтобы быстрее определить выход из строя DIS, Hold interval в этом случае равен 10 сек

Timers могут не совпадать на роутерах.

Link state protocol data unit (LSP)

служит для распространения маршрутной информации

lsp является сам по себе пакетом в отичии от OSPF

LSP определяется следующими полями:

  • System ID of the router that originated this LSP (6 octets; taken from the router’s NET address)

  • Pseudonode ID that differentiates between the LSP describing the router itself and the LSPs for multiaccess networks in which the router is a Designated IS (1 octet)

  • LSP Number denoting the fragment number of this LSP (1 octet). The LSP Number is also called simply the Fragment Number or Fragment for short.

System ID + Pseudonode ID + LSP Number as LSPID. For LSPs that describe routers themselves, the Pseudonode ID is always set to 0. Each LSP has sequence number(32 bit). If the sequence number of an LSP reaches the maximum value,the originating router must be turned off for enough time to allow the LSP to expire, or its System ID must be changed. sequence num не имеет цикличности.

LSP has lifetime - default 1200 sec(20 min) and is decreased. IS-IS refresh all LSP every 15 min. Если lifetime становиться равен 0, он удаляется из базы, сохраняя только заголовок, и рассылается с lifetime равным 0, это называется LSP Purge.The expired LSP can be purged from the link-state database after an additional time called ZeroAgeLifetime set to 60 seconds. This is done to ensure that the LSP’s header is retained until the purged LSP has been safely propagated to all neighbors. Cisco routers, however, appear to hold the empty LSP header for another 20 minutes.

These LSPs are identified with the same System and Pseudonode ID, and with an increasing LSP Number as the fragment number, starting from 0. Если LSP больше MTU. An important fact is that this fragmentation is performed only by the router that originates the LSP.

The topological infor- mation about the network itself and the list of connected routers are contained in a so- called Pseudonode LSP generated by the DIS on the multiaccess network.

IS-IS encodes all topological and addressing information in Type-Length- Value records (the specification of IS-IS uses the term Code instead of Type

LSP packets are used to carry topological and addressing information in IS-IS

LSP describes its originator, its adjacencies to neighboring network objects, and related addressing. Each LSP is uniquely identified by the SystemID.PseudonodeID-LSPNumber. Each LSP has a sequence number, starting at 0x00000001 and ending at 0xFFFFFFFF. The lifespan of an LSP is limited by its Remaining Lifetime timer set to 1200 seconds and decreasing. After this timer expires, a router is required to wait at least another ZeroAgeLifetime (60 seconds) before flushing the LSP. LSPs are refreshed by default every 900 seconds. Separate LSPs are originated for Level 1 and Level 2.

Complete Sequence Number PDU(CSNP) and Partial Sequence Number PDU(PSNP)

The sequence numbers term in names of these messages refers to the range of LSPID values. CSNP packets are very similar in their function to OSPF Database Description Packets. If exceed the MTU, multiple CSNPs are sent. Each CSNP contains information about the Start LSPID and End LSPID that is described by this CSNP. The full range of possible LSPIDs starts with the value of 0000.0000.0000.00-00 (the bold part is the System ID, the following octet is the Pseudonode ID, and the octet following the dash is the LSP Number ID), and ends with the value of FFFF.FFFF.FFFF.FF-FF. This sorting of LSPIDs into ascending number and CSNPs sequen- tially listing all LSPIDs from the allowable range are the reasons for calling these PDUs Sequence Numbers PDUs. On point-to-point links, CSNP packets are exchanged usually only during initial adja- cency buildup; on broadcast networks, CSNP packets are originated periodically by the DIS.

PSNP - analog LSU and LSR

adjacency states:

  • Down: The initial state. No IIHs have been received from the neighbor.

  • Initializing: IIHs have been received from the neighbor, but it is not certain that the neighbor is properly receiving this router’s IIHs.

  • Up: IIHs have been received from the neighbor, and it is certain that the neighbor is properly receiving this router’s IIHs.

P-T-P - 2-way handshake, но уже есть rfc и для 3-way

broadcast -3-way

Local Circuit ID -для каждого интерфейса назначается. Этот номер появляется только IIH

When IP addresses of IS-IS interfaces on both ends of a link are on different network segments, a neighbor relationship can still be established on the two interfaces if the interfaces are configured not to check the IP addresses in received Hello packets. You can configure P2P interfaces not to check the IP addresses in received Hello packets. Before configuring Ethernet interfaces not to check the IP addresses, simulate Ethernet interfaces as P2P interfaces.

Fast Convergence

  • incremental SPF (i-SPF)

  • Partial Route Calculation (PRC)

  • Intelligent timer

  • LSP fast flooding

Configure IS-IS

isis [ process-id ] [ vpn-instance vpn-instance-name ]

CONFIGURE BGP

Overview

BGP state machine

  1. In Connect state, the BGP device starts the ConnectRetry timer and waits to establish a TCP connection.

    • If the TCP connection is established, the BGP device sends an Open message to the peer and changes to the OpenSent state.

    • If the TCP connection fails to be established, the BGP device moves to the Active state.

    • If the BGP device does not receive a response from the peer before the ConnectRetry timer expires, the BGP device attempts to establish a TCP connection with another peer and stays in Connect state.

  2. In Active state, the BGP device keeps trying to establish a TCP connection with the peer.

    • If the TCP connection is established, the BGP device sends an Open message to the peer, closes the ConnectRetry timer, and changes to the OpenSent state.

    • If the TCP connection fails to be established, the BGP device stays in the Active state.

    • If the BGP device does not receive a response from the peer before the ConnectRetry timer expires, the BGP device returns to the Connect state.

  3. In OpenSent state, the BGP device waits an Open message from the peer and then checks the validity of the received Open message, including the AS number, version, and authentication password.

    • If the received Open message is valid, the BGP device sends a Keepalive message and changes to the OpenConfirm state.

    • If the received Open message is invalid, the BGP device sends a Notification message to the peer and returns to the Idle state.

  4. In OpenConfirm state, the BGP device waits for a Keepalive or Notification message from the peer. If the BGP device receives a Keepalive message, it transitions to the Established state. If it receives a Notification message, it returns to the Idle state.

  5. In Established state, the BGP device exchanges Update, Keepalive, Route-refresh, and Notification messages with the peer.

    • If the BGP device receives a valid Update or Keepalive message, it considers that the peer is working properly and maintains the BGP connection with the peer.

    • If the BGP device receives an invalid Update or Keepalive message, it sends a Notification message to the peer and returns to the Idle state.

    • If the BGP device receives a Route-refresh message, it does not change its status.

    • If the BGP device receives a Notification message, it returns to the Idle state.

    • If the BGP device receives a TCP connection termination notification, it terminates the TCP connection with the peer and returns to the Idle state.

BGP Route Selection Policies

  1. Prefers the route with the largest PrefVal value.

    The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it is configured.

  2. Prefers the route with the highest Local_Pref.

    If a route does not have the Local_Pref attribute, the Local_Pref attribute of the route uses the default value 100.

  3. Prefers the manually summarized route, automatically summarized route, route imported using the network command, route imported using the import-route command, and route learned from peers. These routes are in descending order of priority.

  4. Prefers the route with the shortest AS_Path.

  5. Prefers the route with the lowest origin type. IGP is lower than EGP, and EGP is lower than Incomplete.

  6. Prefers the route with the lowest MED if routes are received from the same AS.

  7. Prefers EBGP routes, IBGP routes, LocalCross routes, and RemoteCross routes, which are listed in descending order of priority.

    LocalCross allows a PE to add the VPNv4 route of a VPN instance to the routing table of the VPN instance if the export RT of the VPNv4 route matches the import RT of another VPN instance on the PE. RemoteCross allows a local PE to add the VPNv4 route learned from a remote PE to the routing table of a VPN instance on this local PE if the export RT of the VPNv4 route matches the import RT of the VPN instance.

  8. Prefers the route with the lowest IGP metric to the BGP next hop.If there are multiple routes to the same destination, an IGP calculates the route metric using its routing algorithm.

  9. Prefers the route with the shortest Cluster_List.

  10. Prefers the route advertised by the device with the smallest router ID.

    If a route carries the Originator_ID attribute, BGP prefers the route with the smallest Originator_ID without comparing the router ID.

  11. Prefers the route learned from the peer with the lowest IP address.

RR Principles

  • Client: an IBGP device of which routes are reflected by the RR to other IBGP devices. In an AS, clients only need to directly connect to the RR.

  • Non-client: an IBGP device that is neither an RR nor a client. In an AS, a non-client must establish full-mesh connections with the RR and all the other non-clients.

  • Originator: is a device that originates routes in an AS. The Originator_ID attribute helps eliminate routing loops in a cluster.

  • Cluster: is a set of the RR and clients. The Cluster_List attribute helps eliminate routing loops between clusters.

The RR advertises routes to IBGP peers based on the following rules:

  • The RR advertises the routes learned from a non-client to all the clients.

  • The RR advertises the routes learned from a client to all the other clients and all the non-clients.

  • The RR advertises the routes learned from an EBGP peer to all the clients and non-clients.

To prevent routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster IDs of all the clusters that a route passes through.

The originator ID identifies the originator of a route and is generated by an RR to prevent routing loops in a cluster. Its value is the same as the router ID.

  • When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute to this route. The Originator_ID attribute identifies the originator of the route. If the route contains the Originator_ID attribute, the RR retains this Originator_ID attribute.

  • When a device receives a route, the device compares the originator ID of the route with the local router ID. If they are the same, the device discards the route.

Therefore, routing loops may occur between RRs in the same cluster. To solve this problem, all the RRs in the cluster must use the same cluster ID.

  • When Client1 receives an updated route from an EBGP peer, Client1 advertises this route to RR1 and RR2 using IBGP.

  • After RR1 and RR2 receive this route, they add the local cluster ID to the top of the cluster list of the route and then reflect the route to other clients (Client2 and Client3) and to each other.

  • After RR1 and RR2 receive the reflected route from each other, they check the cluster list of the route, finding that the cluster list contains their local cluster IDs. RR1 and RR2 discard this route to prevent routing loops.

Multiple cluster in AS

  • Hierarchical RR

  • Flat RR

Route Summarization

  • Automatic summarization: summarizes the routes imported by BGP. After automatic summarization is configured, BGP summarizes routes based on the natural network segment and advertises only the summarized route to peers. For example, BGP summarizes 10.1.1.1/24 and 10.2.1.1/24 (two Class A addresses with non-natural mask) into 10.0.0.0/8 (Class A address with natural mask).

  • Manual summarization: summarizes routes in the local BGP routing table. Manual summarization can help control the attributes of the summarized route and determine whether to advertise specific routes.

To prevent routing loops caused by route summarization, BGP uses the AS_Set attribute. The AS_Set attribute is an unordered set of all ASs that a route passes through. When the summarized route enters an AS in the AS_Set attribute again, BGP finds that the local AS number has been recorded in the AS_Set attribute of the route and discards this route to prevent a routing loop.

BGP Tracking

BGP tracking is a fault detection mechanism at the routing layer, whereas BFD is a fault detection mechanism at the link layer.

BGP ORF

BGP ORF allows a device to send prefix-based import policies in a Route-refresh message to BGP peers. BGP peers construct export policies based on these import policies to filter routes before sending these routes, which has the following advantages:

  • Prevents the local device from receiving a large number of unnecessary routes.

  • Reduces CPU usage of the local device.

  • Simplifies the configuration of BGP peers.

  • Improves link bandwidth efficiency.

MP-BGP

In BGP, an Update message carries three IPv4-related attributes: NLRI, Next_Hop, and Aggregator. To support multiple network layer protocols, BGP requires NLRI and Next_Hop attributes to carry information about network layer protocols. Therefore, MP-BGP uses the following new optional non-transitive attributes:

  • MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise reachable routes and next hop information.

  • MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to withdraw unreachable routes.

Configure BGP

peer { ipv4-address | ipv6-address } as-number { as-number-plain | as-number-dot }

peer ipv4-address connect-interface interface-type interface-number [ ipv4-source-address ]

peer connected-check-ignore - The device has been configured not to check the hop count when establishing peers

peer { ipv4-address | ipv6-address } ebgp-max-hop [ hop-count ]

peer { ipv4-address | ipv6-address } description description-text

ipv6-family [ unicast ]

peer { ipv4-address | ipv6-address } enable

BGP peer group

  • group group-name [ external | internal ]

  • peer group-name as-number { as-number-plain | as-number-dot } для iBGP не надо

  • peer group-name connect-interface interface-type interface-number [ ipv4-source-address ]

  • peer group-name ebgp-max-hop [ hop-count ]

  • peer group-name description description-text

  • ipv6-family [ unicast ]

  • peer group-name enable

Import Routes

import-route protocol [ process-id ] [ med med | route-policy route-policy-name ]

default-route imported используется совместно с import-route

network ipv4-address [ mask | mask-length ] [ route-policy route-policy-name ]

RR configure

peer { group-name | ipv4-address | ipv6-address } reflect-client

reflector cluster-id cluster-id By default, each RR uses its router ID as the cluster ID.

undo reflect between-clients Route reflection is prohibited between clients. By default, route reflection is allowed between clients.

Run routing-table rib-only [ route-policy route-policy-name ] BGP is prohibited from adding preferred routes to IP routing tables. By default, BGP adds preferred routes to IP routing tables.

Next-Hop

peer { ipv4-address | group-name | ipv6-address } next-hop-local

nexthop recursive-lookup route-policy *route-policy-name. Routing-policy-based next hop iteration is configured.

peer { ipv4-address | group-name } next-hop-invariable

The device is prevented from changing the next-hop address of a route imported from an IGP before advertising the route to an IBGP peer. By default, a device changes the next-hop address of a route imported from an IGP to the address of the interface connecting the device to its peer when advertising the route to an IBGP peer.

PrefVal

peer { group-name | ipv4-address | ipv6-address } preferred-value value

Local_Pref

default local-preference local-preference

By default, the Local_Pref attribute is 100.

AS_Path

apply as-path { as-number-plain | as-number-dot } &<1-10> { additive | overwrite }

peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name export

peer { ipv4-address | group-name | ipv6-address } route-policy route-policy-name import

import-route protocol [ process-id ] route-policy route-policy-name

network { ipv4-address [ mask | mask-length ] | ipv6-address prefix-length } route-policy route-policy-name

bestroute as-path-ignore

peer { ipv4-address | group-name | ipv6-address } allow-as-loop [ number ]

peer { ipv4-address | group-name | ipv6-address } public-as-only

peer { ipv4-address | group-name | ipv6-address } allow-as-loop [ number ]

Repeated local AS numbers are allowed in routes.

as-path-limit as-path-limit-num The maximum number of AS numbers in the AS_Path attribute is set. By default, the maximum number of AS numbers in the AS_Path attribute is 255.

peer { ipv4-address | group-name | ipv6-address } fake-as { as-number-plain | as-number-dot } [ prepend-global-as ]

MED Attribute

default med med

bestroute med-none-as-maximum BGP defines the MED value as the maximum value if a route does not have the MED attribute.

compare-different-as-med BGP is allowed to compare the MED values of routes received from EBGP peers in any AS. By default, BGP compares only the MEDs of the routes received from EBGP peers within the same AS.

Community

Load Balancing

Controlling BGP Routes

  • filter-policy можно ко все пирам глобально c acl and ip-prefix, на пирах с acl

  • route-policy к определенным пирам

  • as-path-filter к определенным пирам

  • ip-prefix к определенным пирам

peer { group-name | ipv4-address } route-limit limit [ percentage ] [ alert-only | idle-forever | idle-timeout times ]

The maximum number of routes that can be received from the peer or peer group is set.

Refresh or reset BGP

View

  • Run the display bgp peer [ verbose ] command to check information about all BGP peers.

  • Run the display bgp peer ipv4-address { log-info | verbose } command to check information about the specified BGP peer.

  • Run the display bgp routing-table [ ipv4-address [ { mask | mask-length } [ longer-prefixes ] ] ] command to check BGP routing information.

  • Run the display bgp group [ group-name ] command to check information about the specified BGP peer group.

  • Run the display bgp multicast peer [ [ peer-address ] verbose ] command to check information about the specified MBGP peer.

  • Run the display bgp multicast group [ group-name ] command to check information about an MBGP peer group.

  • Run the display bgp multicast network command to check the routing information that MBGP advertises.

  • Run the display bgp multicast routing-table [ ip-address [ mask-length [ longer-prefixes ] | mask [ longer-prefixes ] ] ] command to check the MBGP routing information of a specified network in the MBGP routing table.

OSPFv3

Fundamentals

NSSA area:

OSPFv3 summarization

With route summarization, if a link connected to a device within an IPv6 address range that has been summarized alternates between Up and Down, the link status change is not advertised to the devices beyond the IPv6 address range. This prevents route flapping and improves network stability.

OSPFv3 route summarization is classified as follows:

  • Route summarization on an ABR

    An ABR can summarize routes with the same prefix into one route and advertise the summarized route to other areas.

    When an ABR transmits routing information to other areas, it generates Type 3 LSAs for each network segment. If contiguous segments exist in this area, these segments can be summarized into one segment so that the ABR sends only one summarized LSA.

  • Route summarization on an ASBR

    An ASBR can summarize imported routes with the same prefix into one route and then advertise the summarized route to other areas.

    With route summarization, an ASBR summarizes imported Type 5 LSAs within the summarized address range. After route summarization, the ASBR does not generate a separate Type 5 LSA for each specific prefix within the configured range. Instead, the ASBR generates a Type 5 LSA for only the summarized prefix. In an NSSA, an ASBR summarizes multiple imported Type 7 LSAs within the summarized address range into one Type 7 LSA.

OSPFv3 vs OSPFv2

OSPFv3 and OSPFv2 are the same in the following aspects:

  • Network types and interface types

  • Interface state machines and neighbor state machines

  • LSDB

  • Flooding mechanism

  • Five types of packets: Hello, DD, LSR, LSU, and LSAck packets

  • Route calculation

OSPFv3 and OSPFv2 differ as follows:

  • In OSPFv3, only LSUs contain IP addresses.

  • OSPFv3 uses IPv6 which is based on links rather than network segments.

    Therefore, the interfaces on which OSPFv3 is to be configured must be on the same link rather than in the same network segment. In addition, the interfaces can establish OSPFv3 sessions without IPv6 global addresses.

  • OSPFv3 does not depend on IP addresses.

    OSPFv3 separates topology calculation from IP addresses. Specifically, OSPFv3 can calculate the OSPFv3 topology without IPv6 global addresses which only apply to virtual link interfaces and packet forwarding.

  • OSPFv3 packets and the LSA format change.

    • OSPFv3 packets do not contain IP addresses.

    • OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are advertised through link LSAs and intra-area prefix LSAs.

    • In OSPFv3, router IDs, area IDs, and LSA link state IDs no longer indicate IP addresses, but the IPv4 address format is still reserved.

    • Neighbors are identified by router IDs instead of IP addresses on broadcast, NBMA, or P2MP networks.

  • Information about the flooding scope is added to OSPFv3 LSAs.

    Information about the flooding scope is added to the LSA Type field of OSPFv3 LSAs. Therefore, OSPFv3 routers can process LSAs of unidentified types more flexibly.

    • OSPFv3 can store or flood unidentified packets, whereas OSPFv2 discards unidentified packets.

    • In OSPFv3, unknown LSAs with 1 as the U flag bit can be flooded, and the flooding scope of such LSAs is specified by the LSAs.

    For example, Device A and Device B can identify LSAs of a certain type. Device A and Device B are connected through Device C which, however, cannot identify these LSAs. If Device A floods such LSA to Device C, Device C can still flood the received LSAs to Device B although Device C does not identify these LSAs. Device B then processes these LSAs.

    If OSPFv2 is run, Device C discards the unidentified LSAs. As a result, these LSAs cannot reach Device B.

  • OSPFv3 supports multi-process on a link.

    In OSPFv2, one physical interface can be bound to only one multi-instance. In OSPFv3, one physical interface can be bound to multiple multi-instances that are identified by different instance IDs. In these OSPFv3 multi-instances running on one physical interface, neighbor relationships are established separately, sharing resources on the same link.

  • OSPFv3 uses IPv6 link-local addresses.

    IPv6 implements neighbor discovery and automatic configuration based on link-local addresses. Routers running IPv6 do not forward IPv6 packets whose destination address is a link-local address, and those packets can only be exchanged on the same link. The unicast link-local address starts from FE80/10.

    As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to maintain neighbor relationships and update LSDBs. Except Vlink interfaces, all OSPFv3 interfaces use link-local addresses as the source address and the next hop to transmit OSPFv3 packets.

    The advantages are as follows:

    • OSPFv3 can calculate the topology without global IPv6 addresses.

    • The packets flooded on a link are not transmitted to other links, which prevents unnecessary flooding and saves bandwidth.

  • OSPFv3 supports two new LSAs.

    • Link LSA: A device floods a link LSA on the link where it resides to advertise its link-local address and the configured global IPv6 address.

    • Intra-area prefix LSA: A device advertises an intra-area prefix LSA in the local OSPF area to inform the other routers in the area or the network (either a broadcast network or an NBMA network) of its IPv6 global address.

  • OSPFv3 identifies neighbors based on Router IDs only.

    On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on IPv4 addresses of interfaces.

    OSPFv3 identifies neighbors based on Router IDs only.

OSPFv3 GR

OSPFv3 Neighbor Relationship Flapping Suppression

OSPFv3 neighbor relationship flapping suppression works by delaying OSPFv3 neighbor relationship reestablishment or setting the link cost to the maximum value (65535).

Flapping_event: reported when the status of a neighbor relationship on an interface last changes from Full to a non-Full state. The flapping_event triggers flapping detection.

Flapping_count: number of times flapping has occurred.

Detect-interval: detection interval. The interval is used to determine whether to trigger a valid flapping_event.

Threshold: flapping suppression threshold. When the flapping_count reaches or exceeds threshold, flapping suppression takes effect.

Resume-interval: interval for exiting from OSPFv3 neighbor relationship flapping suppression. If the interval between two successive valid flapping_events is longer than resume-interval, the flapping_count is reset.

Flapping suppression works in either Hold-down or Hold-max-cost mode.

  • Hold-down mode: In the case of frequent flooding and topology changes during neighbor relationship establishment, interfaces prevent neighbor relationships from being reestablished during the suppression period, which minimizes LSDB synchronization attempts and packet exchanges.

  • Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use 65535 as the cost of the flapping link during Hold-max-cost suppression, which prevents traffic from passing through the flapping link.

OSPFv3 Packet Format

The length of an OSPFv3 packet header is 24 bytes. The OSPFv3 protocol number is 89.

Hello packet

A Hello packet includes information about the designated router (DR), backup designated router (BDR), timers, and known neighbors.

DD Packet

LSR Packet

LSU Packet

To ensure reliable LSA flooding, a router uses an LSAck packet to acknowledge the LSAs contained in an LSU packet that is received from a neighbor. If an LSA fails to be acknowledged, the router retransmits the LSA to the neighbor.

LSAck Packet

OSPFv3 LSA Format

LSA Header Format

Router-LSA

A router-LSA describes the link status and cost of a router. Router-LSAs are generated by a router and advertised within the area to which the router belongs. Figure 7-27 shows the format of a router-LSA.

Network LSA

A network-LSA describes the link status of all routers on the local network segment. Network-LSAs are generated by a DR on a broadcast or non-broadcast multiple access (NBMA) network and advertised within the area to which the DR belongs. Figure 7-28 shows the format of a network-LSA.

Inter-Area-Prefix-LSA

Inter-Area-Router-LSA(type 4)

An inter-area-router-LSA describes routes to the ASBR in other areas. It is generated by the ABR. The routes are advertised to all related areas except the area that the ASBR belongs to.

AS-External-LSA (type 5)

An as-external-LSA describes destinations outside the AS, it is originated by ASBR.

NSSA LSA(type 7)

An NSSA-LSA describes destinations outside the AS, it is originated by ASBR.

Link-LSA (type 8)

Each router generates a link LSA for each link. A link LSA describes the link-local address and IPv6 address prefix associated with the link and the link option set in the network LSA. It is transmitted only on the link.

Intra-Area-Prefix-LSA (type 9)

Each router or DR generates one or more intra-area prefix LSAs and transmits it in the local area.

  • An LSA generated on a router describes the IPv6 address prefix associated with the router LSA.

  • An LSA generated on a DR describes the IPv6 address prefix associated with the network LSA.

Configure VRRP

MAC address that is generated by the virtual router based on the VRID. A virtual router has one virtual MAC address and is in the format of 00-00-5E-00-01-{VRID} (VRRP for IPv4) or 00-00-5E-00-02-{VRID} (VRRP for IPv6). The virtual router sends ARP Reply packets carrying the virtual MAC address but not the interface MAC address.

VRRP Advertisement packets are encapsulated into IP packets and sent to the VRRP virtual IP address. In the IP packet header, the source address is the primary IP address of the interface that sends the packets (not the virtual IP address), the destination address is 224.0.0.18, the TTL is 255, and the protocol number is 112.

VRRP defines three statuses:

  • Initialize,

  • Master

  • Backup

Examples

Switching

Configure Link Aggregation (Eth-trunk)

Eth-Trunk is located at the data link layer, between the MAC address and LLC sub-layers.

Link Aggregation Methods

  • Intra-device: Member interfaces of an Eth-Trunk are located on the same device.

  • Inter-stack-device: Member interfaces of an Eth-Trunk are located on member devices of a stack. For details, see Link Aggregation in Stack Scenarios.

  • Inter-device: The inter-device link aggregation refers to E-Trunk. E-Trunk allows links between multiple devices to be aggregated using LACP. For details, see E-Trunk.

LACP, as specified in IEEE 802.3ad

Link Aggregation Control Protocol Data Units (LACPDUs)

LACP system priority.To achieve this, one device (with a higher priority) is responsible for selecting the active interfaces. The other device (with a lower priority) then selects the same interfaces as active interfaces. In priority comparisons, numerically lower values have higher priority.

M:N backup of member interfaces. LACP mode is also called M:N mode, where M refers to the number of active links and N refers to the number of backup links. If no available backup link is found and the number of active links is smaller than the lower threshold, the system shuts down the LAG. Devices at both ends determine the Actor and active links. If DeviceA and DeviceB have the same LACP system priority, the device with a smaller MAC address becomes the Actor. After the Actor is selected, both devices select active interfaces based on the interface priorities of the Actor. If priorities of interfaces on the Actor are the same, interfaces with smaller interface numbers are selected as active interfaces. An Eth-Trunk is established when both devices select the same interfaces as active interfaces. Active links then load balance traffic.

LACP preemption

When LACP preemption is enabled, interfaces with higher priorities in a LAG always function as active interfaces. LACP preemption is used in the following scenarios:

  • Port 1 becomes faulty, causing Port3 to take its place and transmit traffic. When Port 1 recovers, if LACP preemption is not enabled on the Eth-Trunk, Port 1 remains in backup state. If LACP preemption is enabled on the Eth-Trunk, after Port1 recovers, it becomes active again due to having a higher priority than Port3, which reverts to being the backup interface.

  • With LACP preemption enabled, setting a higher LACP priority for Port 3 will allow it to replace Port 1 or Port 2 as an active interface without either of them first becoming faulty. If LACP preemption is not enabled, the system does not re-select active interfaces even if the priority of a backup interface is set higher than that of an active interface.

LACP preemption delay

The LACP preemption delay is the time a backup link waits before becoming the active link after an active link becomes faulty. The LACP preemption delay is used to prevent unstable data transmission over an Eth-Trunk link caused by frequent status changes of member links.

Switchover between active and inactive links

In LACP mode, a link switchover in a LAG is triggered if a device at one end detects one of the following events:

  • An active link goes Down.

  • Ethernet OAM detects a link fault.

  • LACP detects a link fault.

  • An active interface becomes unavailable.

  • When LACP preemption is enabled, a backup interface becomes the active interface as soon as its priority is changed to be higher than that of the current active interface.

When any of the preceding events occurs, LACP takes effect with the following sequence of events:

  1. Shuts down the faulty link.

  2. Selects the backup link with the highest priority among N backup links to replace the faulty active link.

  3. The backup link with the highest priority becomes the active link and begins forwarding data.

Load Balancing Modes of Link Aggregation

problem out-of-order packets. To prevent out-of-order packets, Eth-Trunk uses flow-based load balancing.

This mechanism uses the hash algorithm to calculate the address in a data frame and generate a hash key based on which the system searches for the outbound interface in the Eth-Trunk forwarding table. Each MAC or IP address corresponds to a hash key, so the system uses different outbound interfaces to forward data. This mechanism ensures that frames of the same data flow are forwarded on the same physical link and implements load balancing of data flows.

  • For example, an Eth-Trunk supports a maximum of eight member interfaces. If physical interfaces 1, 2, 3, and 4 are bundled into an Eth-Trunk, the Eth-Trunk forwarding table contains eight entries, as shown in Figure 2. In the Eth-Trunk forwarding table, hash keys are 0, 1, 2, 3, 4, 5, 6, and 7, and the corresponding interface numbers are 1, 2, 3, 4, 1, 2, 3, and 4.

Figure 2 Example of an Eth-Trunk forwarding table

Load Balancing Modes

load balancing based on the following information:

  • Source MAC addresses of data frames

  • Destination MAC address of data frames

  • Exclusive-Or result of source and destination MAC addresses of data frames

  • Source IP addresses of data frames

  • Destination IP addresses of data frames

  • Exclusive-Or result of source and destination IP addresses of data frames

  • VLAN IDs and source physical interface numbers for Layer 2, IPv4, IPv6, and MPLS packets in enhanced load balancing mode

Link Aggregation in Stack Scenarios

Preferential forwarding of local traffic can be used

  • This function is only valid for known unicast packets, and is invalid for unknown unicast packets, broadcast packets, and multicast packets.

E-Trunk

Enhanced Trunk (E-Trunk) is an extension of the Link Aggregation Control Protocol (LACP). E-Trunk is suitable to scenarios where a CE is dual-homed to a network

??

Configuration Eth-Trunk

you can run the assign trunk command to set the maximum number of LAGs and the maximum number of member interfaces in each LAG, implementing flexible networking and meeting various service requirements.

assign trunk { trunk-group group-number | trunk-member member-number }

However, if the Eth-Trunk interface is added to an E-Trunk, you cannot change its working mode.

Adding Member Interfaces to an Eth-Trunk

Setting the Lower Threshold for the Number of Active Interfaces

least active-linknumber link-number

Configuring a Load Balancing Mode

Load balancing is valid only for outgoing traffic; therefore, the load balancing modes for the interfaces at both ends of a link can be different and do not affect each other.

On a network where an Eth-Trunk and a stack are configured, if the local-preference enable command is run to configure an Eth-Trunk interface to preferentially forward local traffic

By default, the switch load balances packets based on src-dst-ip.

other commands

lacp force-forward

The Eth-Trunk member interface in Up state is configured to forward data packets if the remote interface does not join the Eth-Trunk.

By default, an Eth-Trunk member interface in Up state does not forward data packets if the remote interface does not join the Eth-Trunk.

  • With this command configured, an Eth-Trunk interface does not support Layer 3 forwarding and cannot be used to forward packets sent to the CPU. Only member interfaces in the ForceFwd state can forward Layer 2 traffic through hardware forwarding. The ForceFwd state is automatically set when LACP negotiation fails, and cannot be changed manually. You can use the display eth-trunk command to check the value of the Status field.

  • This command applies to only the scenario where an Eth-Trunk joins a VLAN as an access, hybrid, trunk, and dot1q-tunnel interfaces.

  • When a spanning tree protocol (for example, STP, RSTP, or MSTP) is used, the member interface in ForceFwd state cannot be blocked. That is, the member interface in ForceFwd state can continue to forward data packets. When other loop prevention protocols such as ERPS and RRPP are used, the member interface in ForceFwd state can be blocked. The blocked member interface in ForceFwd state cannot forward data packets.

  • This command cannot be used with E-Trunk. That is, this command cannot be used on the Eth-Trunk that joins an E-Trunk.

  • This command cannot be used with max active-linknumber or least active-linknumber.

Check commands

Examples

Configure MSTP

configure mode:

stp mode mstp - default mode

enable stp:

stp enable - default enable

Сокращения

d c c o - dis current-conf ospf

d c c b - dis current-conf bgp

d c c is - dis current-conf is-is

d th - dis this

d ip r p o - dis ip routing proto ospf

vl ba 2 to 10 - vlan batch 2 to 10

int g 0/0/3

p l a - port link-type ac

p d v 10 - port default vlan 10

p l t - port link-type trunk

p t a v all - port trunk allow vlan all

confgure MSTP

MPLS

LSR - label switching router

LER - label edge router

LSP - label switched path

LDP - label distribution protocol

LIB - label information base

FIB - forwarding information base

LFIB - label forwarding information base

FEC - forwarding equivalence class. is a collection of packets with the same characteristics. Packets of the same FEC are forwarded in the same way on an MPLS network. FECs can be identified by the source address, destination address, source port, destination port, and VPN.

Label

4-bytes identifier that is only locally significant. A label identifies an FEC to which a packet belongs. In some cases, such as load balancing, a FEC can be mapped to multiple incoming labels. Each label, however, represents only one FEC on a device.

  • Label: 20-bit label value.

  • Exp: 3-bit, used as an extension value. Generally, this field is used as the class of service (CoS) field. When congestion occurs, devices prioritize packets that have a larger value in this field.

  • S: 1-bit value indicating the bottom of a label stack. MPLS supports nesting of multiple labels. When the S field is 1, the label is at the bottom of the label stack.

  • TTL: time to live. This 8-bit field is the same as the TTL field in IP packets.

the label next to the Layer 2 header is the top of the label stack (outer MPLS label), the label next to the Layer 3 header is the bottom of the label stack (inner MPLS label). Currently, MPLS label stacks can be applied to MPLS VPN and Traffic Engineering Fast ReRoute (TE FRR).

The label stack organizes labels according to the rule of Last-In, First-Out. The labels are processed from the top of the stack.

Label Space

  • 0 to 15: special labels. For details about special labels, see Table 1.

  • 16 to 1023: label space shared by static LSPs and static constraint-based routed LSPs (CR-LSPs).

  • 1024 or above: label space for dynamic signaling protocols, such as Label Distribution Protocol (LDP), Resource Reservation Protocol-Traffic Engineering (RSVP-TE), and MultiProtocol Border Gateway Protocol (MP-BGP).

LDP overview

LDP defines the following messages:

  • Discovery message: used to announce or maintain an LSR on a network. For example, Hello messages are discovery messages.

  • Session message: used to establish, maintain, and terminate sessions between LDP peers. For example, Initialization and Keepalive messages are session messages.

  • Advertisement message: used to create, modify, and delete label mappings for FECs.

  • Notification message: used to provide advisory and error information.

LDP uses Transmission Control Protocol (TCP) transport for Session, Advertisement, and Notification messages. LDP uses User Datagram Protocol (UDP) transport only for transmitting the Discovery message.

Basic discovery mechanism: used to discover directly-connected LSR peers on a link.

Extended discovery mechanism: used to discover LSR peers that are not directly connected on a link.

The LDP session setup process consists of the following steps:

  1. Two LSRs send Hello messages to each other.

    Each Hello message contains the transport address (device IP address) that the two LSRs use to establish an LDP session.

  2. The LSR with a larger transport address initiates a TCP connection.

    As shown in Figure 1, LSR_1 initiates a TCP connection and LSR_2 waits for the TCP connection request.

  3. After the TCP connection is successfully established, LSR_1 sends an Initialization message to negotiate with LSR_2 about parameters used for establishing the LDP session.

    These parameters include the LDP version, label distribution mode, Keepalive timer value, maximum packet data unit (PDU) length, and label space.

  4. If LSR_2 accepts parameters in the Initialization message, LSR_2 sends an Initialization message and a Keepalive message to LSR_1.

    If LSR_2 rejects the parameters in the Initialization message, LSR_2 sends a Notification message to LSR_1 to stop the establishment of the LDP session.

    Parameters in the Initialization message include the LDP version, label distribution mode, Keepalive timer value, maximum PDU length, and label space.

  5. If LSR_1 accepts the parameters in the Initialization message sent from LSR_2, LSR_1 sends a Keepalive message to LSR_2.

    If LSR_1 rejects the parameters in the Initialization message, LSR_1 sends a Notification message to LSR_2 to stop the establishment of the LDP session.

Initialization message has parameters include the LDP version, label distribution mode, Keepalive timer value, maximum packet data unit (PDU) length, and label space.

Label advertisiment mode

Label Distribution Control Modes

  • Independent mode: A local LSR can distribute a label bound to an FEC and then inform the upstream LSR, without waiting for the label distributed by the downstream LSR.

  • Ordered mode: An LSR advertises the mapping between a label and an FEC to its upstream LSR only when this LSR is the outgoing node of the FEC or receives the Label Mapping message of the next hop for the FEC.

Label retention mode

Currently, the following combinations are supported:

  • DU label advertisement mode, ordered label control mode, and liberal label retention mode (default mode)

  • DoD label advertisement mode, ordered label control mode, and conservative label retention mode

LDP Security Mechanisms

To ensure security of LDP packets, MPLS provides three security mechanisms: Message-digest algorithm 5 (MD5), Keychain, and Generalized TTL Security Mechanism (GTSM). Keychain is more secure than MD5 authentication, and only one of these mechanisms can be used for an LDP peer. GTSM protects a device against attacks of invalid LDP packets and can be used with MD5 authentication or Keychain.

LDP Reliability

LDP Label

Label distribution modes:

Downstream on Demand (DoD): Each LSR requests a label binding for a FEC following that IP routing path. There is only one binding per FEC received and only from its downstream LSR. The LIB only shows one remote binding. This is only used on Label Controlled (LC) ATM interfaces.

Unsolicited downstream (UD): Each LSR distributes a label binding for all IGP routes to all neighboring LSRs without being asked to do so. The LIB will likely show a binding from each neighbor. This is used on all interfaces except LC-ATM.

Label retention modes:

Liberal Label Retention (LLR): All labels are stored in the LIB for a given FEC. Only the label from the downstream LSR, according to the FIB, is installed in the LFIB. The others are for backup only and this facilitates FRR. Better for HA and used on all interfaces except LC-ATM.

Conservative Label Retention (CLR): Only the label from the downstream LSR is stored in the LIB. Better for memory conservation and only used on LC-ATM interfaces.

LSP control modes:

Independent: Each LSR creates a local binding for a FEC as soon as it recognizes the FEC (that is, the IP prefix is in the FIB via IGP). No other LSR is involved. Disadvantage is that some LSRs forward packets before the LSP is set up. Used in most Cisco platforms.

Ordered: LSR only creates a binding for a FEC if it realizes that it is the egress LSR, or if it received a label binding from the next-hop for this FEC. Only allocates labels for connected routes or IGP routes for which it has received a binding from the next-hop LSR. Used on Cisco ATM switches.

LSP Setup

label distribution protocol defines FECs, distributes labels, and establishes and maintains LSPs.

  • LDP

    The Label Distribution Protocol (LDP) is designed for distributing labels. It sets up an LSP hop by hop according to Interior Gateway Protocol (IGP) and Border Gateway Protocol (BGP) routing information.

  • RSVP-TE

    Resource Reservation Protocol Traffic Engineering (RSVP-TE) is an extension of RSVP and is used to set up a constraint-based routed LSP (CR-LSP). In contrast to LDP LSPs, RSVP-TE tunnels are characterized by bandwidth reservation requests, bandwidth constraints, link "colors" (designating administrative groups), and explicit paths.

  • MP-BGP

    MP-BGP is an extension to BGP and allocates labels to MPLS VPN routes and inter-AS VPN routes.

MPLS labels are distributed from downstream LSRs to upstream LSRs.

MPLS forwarding

Label operations involved in MPLS packet forwarding include push, swap, and pop:

  • Push: When an IP packet enters an MPLS domain, the ingress node adds a new label to the packet between the Layer 2 header and the IP header. Alternatively, an LSR adds a new label to the top of the label stack.

  • Swap: When a packet is transferred within the MPLS domain, a local node swaps the label at the top of the label stack in the MPLS packet for the label allocated by the next hop according to the label forwarding table.

  • Pop: When a packet leaves the MPLS domain, the label is popped out of (removed from) the MPLS packet.

    A label is invalid at the last hop of an MPLS domain. The penultimate hop popping (PHP) feature applies. On the penultimate node, the label is popped out of the packet to reduce the size of the packet that is forwarded to the last hop. Then, the last hop directly forwards the IP packet or forwards the packet by using the second label.

    By default, PHP is configured on the egress node. The egress node supporting PHP allocates the label with the value of 3 to the penultimate hop.

Detailed MPLS Forwarding

  • Tunnel ID

    Each tunnel is assigned a unique ID to ensure that upper layer applications (such as VPN and route management) on a tunnel use the same interface. The tunnel ID is 32 bits long and is valid only on the local end.

  • NHLFE

    A next hop label forwarding entry (NHLFE) is used to guide MPLS packet forwarding.

    An NHLFE specifies the tunnel ID, outbound interface, next hop, outgoing label, and label operation.

    FEC-to-NHLFE (FTN) maps each FEC to a group of NHLFEs. An FTN can be obtained by searching for tunnel IDs that are not 0x0 in a FIB. The FTN is available on the ingress only.

  • ILM

    The incoming label map (ILM) maps each incoming label to a group of NHLFEs.

    The ILM specifies the tunnel ID, incoming label, inbound interface, and label operation.

    The ILM on a transit node identifies bindings between labels and NHLFEs. Similar a FIB that provides forwarding information based on destination IP addresses, the ILM provides forwarding information based on labels.

If the label value is 3, the transit node pops out the label and processes the TTL field. After that, the transit node forwards the packets through an IP route or based on the next layer label.

MPLS TTL Processing

The TTL field in an MPLS label is 8 bits long. The TTL field is the same as that in an IP packet header. MPLS processes the TTL to prevent loops and implement traceroute. MPLS TTL processing modes includes: Uniform and Pipe modes. By default, MPLS processes the TTL in Uniform mode.

Uniform mode

the ingress node decreases the IP TTL by one and copies this new value to the MPLS TTL field. The egress node decreases the MPLS TTL by one and maps this new value to the IP TTL field.

Pipe mode

The TTL field in MPLS packets is processed in standard mode. The egress node decreases the IP TTL by one. In Pipe mode, the IP TTL only decreases by one on the ingress node and one on the egress node when packets travels across an MPLS network.

MPLS VPN

Specifically, information in a VPN instance includes the IP routing table, label forwarding table, interface bound to the VPN instance, and VPN instance management information. VPN instance management information includes the route distinguisher (RD), route filtering policy, and member interface list of the VPN instance.

  • Public routing table

  • VPN routing table

  • Public forwarding table

  • VPN forwarding table

RD:

  • RD distinguish the IPv4 prefixes with the same address space.

  • 64 bits ( 8 byte )

VPN-IPv4 address:

  • it's IPv4 address with 64-bit RD

  • VPN-IPv4 addresses transmit by VPN-IPv4 address family

When CE devices are dual-homed to PE devices, RD must be globally unique to ensure correct routing.

RT

32bit BGP extenstion community attribute , to control VPN routes advertisiment

two types : export target and import target

ipv4 routes converted to vpnv4, set export target and advertise by BGP with extended community attributes

If the export target is the same as the import target of a VPN instance on the local PE device, the local PE device adds the route to the VPN routing table

RFC 2858 MP-BGP

Then the PE device changes the Next_Hop attribute in the Route Advertisement message to its own Loopback address and adds a VPN label (randomly generated by MP-IBGP) to the route. After that, the PE device adds the Export Route Target attribute to the route and sends the route to all the PE neighbors. In VRP5.3, after MPLS is enabled on PE1, PE1 uses MP-BGP to allocate VPN labels to private network routes. PE devices can then correctly exchange VPN routes. This may cause routing loops in the VPN site. The Site or Origin (SOO) specifies the source site and prevents routing loops.

•MP_REACH_NLRI is used to advertise reachable routes and next hop information. It consists of one or more 3-tuples <Address Family Information, Next Hop Network Address Information, NLRI>.

▫Address Family Information: consists of a 2-byte Address Family Identifier (AFI) and a 1-byte Subsequent Address Family Identifier (SAFI).

▪The AFI identifies the network layer protocol, corresponding to the address family value defined by "Address Family Number" in RFC 3232. For example, 1 indicates IPv4 and 2 indicates IPv6.

▪The SAFI indicates the NLRI type. If the AFI value is 1 and the SAFI value is 128, the address in the NLRI is an MPLS-labeled VPN-IPv4 address.

▫Next Hop Network Address Information: consists of the 1-byte length of the next hop network address and the variable-length next hop network address.

▫NLRI: consists of one or more 3-tuples <length, label, prefix>. This part will be described in detail in the following slides.

•MP_UNREACH_NLRI is used to instruct a peer to delete unreachable routes. The format of this attribute is as follows:

▫AFI: same as that in the MP_REACH_NLRI attribute

▫SAFI: NLRI type, same as that in the MP_REACH_NLRI attribute

▫Withdrawn Routes: an unreachable route list, consisting of one or more NLRI fields A BGP speaker can withdraw a route by adding the NLRI same as that in a previously advertised reachable route to the Withdrawn Routes field.

EVPN

EVPN Oveview

MULTICAST

Overview

Multicast service model:

  • Any-Source multicast (ASM) model

  • Source-Specific Multicast (SSM ) model

Protocol Independent Multicast (PIM) for generate MDT дерево

PIM-DM (dense mode)

PIM-SM (sparse mode)

MDT multicast distribution tree ((root multicast source))

RPF - reverse path forwarding

MSDP - for inter-as generate MDT

MBGP - help perform RPF for inter-as check

IGMP - Internet Group Management Protocol

RPT - randevu point tree (shared tree)

SPT - source path tree

igmp group entry and igmp routing entries

The IGMP querier sends General Query messages at intervals. The interval is configurable, and the default interval is 60 seconds

. By default, the value of the timer is a random value ranging from 0 to 10, in seconds for send report message

igmpv1 use PIM for electing DR( Querier ). Leav group only on timer - 130 sec

igmpv2 - Election Queries, Leave mechanism, Leave message send on 224.0.0.2

  • ▫Max Response Time: maximum time for a member to respond to a Query message with a Report message.

  • ▪For a General Query message, the default maximum response time is 10 seconds.

  • ▪For a Group-Specific Query message, the default maximum response time is 1 second.

the lowest IP address is elected as the querier.

By default, the querier sends Group-Specific Query messages twice, at an interval of 1s. In addition, the querier starts the group membership timer (Timer-Membership). The value of the timer is the Group-Specific Query interval multiplied by Count.

igmpv3 added:

  • In addition to General Query and Group-Specific Query messages, IGMPv3 has a new Query message type: Group-and-Source-Specific Query.

  • Each IGMPv3 Report message contains the group that a host wants to join and the multicast sources from which the host wants to receive data.

  • Different members in the same multicast group may want to receive multicast data from different sources. Therefore, IGMPv3 does not require the Report message suppression mechanism**.**

  • Unlike IGMPv2, IGMPv3 does not define a Leave message. Group members send Report messages of a specified type to notify multicast routers that they have left a group.

igmpv3 report message has modes:

  • include

  • exclude

IGMPv3 does not have a Report message suppression mechanism.

igmp snooping

Aging timer = Robustness variable (2 by default) x Group-Specific Query interval (1s by default).

IGMP Proxy

224.0.0.0 to 239.255.255.255

01:00:5e: 23 bit from ipv4

PreviousNCE FabricNextHuawei

Last updated