HP Firewalls and UTM Devices Appendix Protocol Reference Part number: 5998-4171 Software version: F1000-A-EI: Feature 3722 F1000-S-EI: Feature 3722 F5000: Feature 3211 F1000-E: Feature 3174 Firewall module: Feature 3174 Enhanced firewall module: ESS 3807 U200-A: ESS 5132 U200-S: ESS 5132 Document version: 6PW100-20121228
Legal and notice information © Copyright 2012 Hewlett-Packard Development Company, L.P. No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Contents IP routing basics ··························································································································································· 1 Routing table ······································································································································································ 1 Dynamic routing protocols ······················································································································
NET ·················································································································································································· 19 IS-IS area ········································································································································································· 20 Level-1 and Level-2 ··························································································································
Supported features ························································································································································· 51 Protocols and standards ················································································································································ 51 IPv6 IS-IS ························································································································································
DR election ····························································································································································· 81 RP discovery ··························································································································································· 82 RPT building ··························································································································································
How MLDv1 works ······················································································································································· 115 How MLDv2 works ······················································································································································· 117 IPv6 multicast group filtering ······························································································································ 117 MLD st
IP routing basics The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Routing table A router maintains at least two routing tables: a global routing table and a FIB. The FIB table contains only the optimal routes, and the global routing table contains all routes. The router uses the FIB table to forward packets. For more information about the FIB table, see Network Management Configuration Guide. Table 1 categorizes routes by different criteria.
Interface—Output interface. • Dynamic routing protocols Static routes work well in small stable networks. They are easy to configure and require fewer system resources. However, in networks where topology changes occur frequently, a typical practice is to configure a dynamic routing protocol. Compared with static routing, a dynamic routing protocol is complicated to configure, requires more resources, and consumes more network resources.
Route type Preference OSPF NSSA 150 IBGP 255 EBGP 255 Unknown (route from an untrusted source) 256 Load sharing A routing protocol may find multiple optimal equal-cost routes to the same destination. You can use these routes to implement equal-cost multi-path (ECMP) load sharing. Static routing, IPv6 static routing, RIP, RIPng, OSPF, OSPFv3, IS-IS, IPv6 IS-IS, BGP, and IPv6 BGP support ECMP load sharing. Route backup Route backup can improve network availability.
Static routing The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work properly. Static routes cannot adapt to network topology changes. If a fault or a topological change occurs in the network, the network administrator must modify the static routes manually.
Default route The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. A default route is used to forward packets that match no entry in the routing table. Without a default route, a packet that does not match any routing entries is discarded. A default route can be configured in either of the following ways: • The network administrator can configure a default route with both destination and mask being 0.0.0.0. For more information, see "Static routing.
RIP The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Routing Information Protocol (RIP) is a distance-vector simple interior gateway protocol suited to small-sized networks. It employs UDP to exchange route information through port 520. Overview RIP uses a hop count to measure the distance to a destination. The hop count from a router to a directly connected network is 0. The hop count from a router to a directly connected router is 1.
• Counting to infinity—A destination with a metric value of 16 is considered unreachable. When a routing loop occurs, the metric value of a route will increment to 16 to avoid endless looping. • Split horizon—Disables RIP from sending routing information on the interface from which the information was learned to prevent routing loops and save bandwidth.
RIPv1 message format Figure 1 RIPv1 message format 0 Header 7 Command 15 Version AFI Route entries 31 Must be zero Must be zero IP address Must be zero Must be zero Metric • Command—Type of message. 1 indicates a request, which is used to request all or part of the routing information from the neighbor, and 2 indicates a response, which contains all or part of the routing information. A response message consists of up to 25 route entries. • Version—Version of RIP, 0x01 for RIPv1.
RIPv2 authentication message format RIPv2 sets the AFI field of the first route entry to 0xFFFF to identify authentication information. Figure 3 RIPv2 authentication message 0 7 Command 15 31 Version Unused 0xFFFF Authentication type Authentication (16 octets) • Authentication type—A value of 2 represents plain text authentication, while a value of 3 represents MD5.
OSPF The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Open Shortest Path First (OSPF) is a link state IGP developed by the OSPF working group of the IETF. OSPF version 2 is used for IPv4. Unless otherwise stated, OSPF refers to OSPFv2 throughout this chapter. Overview OSPF has the following features: • Wide scope—Supports various network sizes and up to several hundred routers in an OSPF routing domain.
LSA types OSPF advertises routing information in Link State Advertisements (LSAs). The following describes some commonly used LSAs: • Router LSA—Type-1 LSA, originated by all routers and flooded throughout a single area only. This LSA describes the collected states of the router's interfaces to an area. • Network LSA—Type-2 LSA, originated for broadcast and NBMA networks by the designated router, and flooded throughout a single area only. This LSA contains the list of routers connected to the network.
Figure 4 Area based OSPF network partition Backbone area and virtual links Each AS has a backbone area that distributes routing information between non-backbone areas. Routing information between non-backbone areas must be forwarded by the backbone area. OSPF requires the following: • All non-backbone areas must maintain connectivity to the backbone area. • The backbone area must maintain connectivity within itself. In practice, the requirements might not be satisfied due to lack of physical links.
Figure 6 Virtual link application 2 The virtual link between the two ABRs acts as a point-to-point connection. You can configure interface parameters, such as hello interval, on the virtual link as they are configured on a physical interface. The two ABRs on the virtual link unicast OSPF packets to each other, and the OSPF routers in between convey these OSPF packets as normal IP packets.
Figure 7 NSSA area Router types OSPF classifies routers into the following types based on their positions in the AS: • Internal router—All interfaces on an internal router belong to one OSPF area. • Area Border Router (ABR)—Belongs to more than two areas, one of which must be the backbone area. An ABR connects the backbone area to a non-backbone area. An ABR and the backbone area can be connected through a physical or logical link.
• Inter-area route • Type-1 external route • Type-2 external route The intra-area and inter-area routes describe the network topology of the AS. The external routes describe routes to external ASs. A Type-1 external route has high credibility. The cost from a router to the destination of a Type-1 external route = the cost from the router to the corresponding ASBR + the cost from the ASBR to the destination of the external route. A Type-2 external route has low credibility.
• On a NBMA network, OSPF packets are unicast, and neighbors are manually configured. On a P2MP network, OSPF packets are multicast by default, and you can configure OSPF to unicast protocol packets. DR and BDR On a broadcast or NBMA network, any two routers must establish an adjacency to exchange routing information with each other. If n routers are present on the network, n(n-1)/2 adjacencies are established.
The election votes are hello packets. Each router sends the DR elected by itself in a hello packet to all the other routers. If two routers on the network declare themselves as the DR, the router with the higher router priority wins. If router priorities are the same, the router with the higher router ID wins. If a router with a higher router priority is added to the network after DR and BDR election, the router cannot become the DR or BDR immediately because no DR election is performed for it.
IS-IS The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Overview Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol designed by the ISO to operate on the connectionless network protocol (CLNP). IS-IS was modified and extended in RFC 1195 by the IETF for application in both TCP/IP and OSI reference models, called "Integrated IS-IS" or "Dual IS-IS." IS-IS is an IGP used within an AS.
The IDP and DSP are variable in length. The length of an NSAP address varies from 8 bytes to 20 bytes. Figure 10 NSAP address format Area address The area address comprises the IDP and the HO-DSP of the DSP, which identify the area and the routing domain. Different routing domains cannot have the same area address. Typically, a router only needs one area address, and all nodes in the same area must have the same area address.
A NET comprises the following parts: • Area ID—Has a length of 1 to 13 bytes. • System ID—A system ID uniquely identifies a host or router in the area and has a fixed length of 6-byte. • SEL—Has a value of 0 and a fixed length of 1-byte. For example, for a NET is ab.cdef.1234.5678.9abc.00, the area ID is ab.cdef, the system ID is 1234.5678.9abc, and the SEL is 00. Typically, a router only needs one NET, but it can have a maximum of three NETs for smooth area merging and partitioning.
Figure 11 IS-IS topology 1 Figure 12 shows another IS-IS topology. The Level-1-2 routers connect to the Level-1 and Level-2 routers, and form the IS-IS backbone together with the Level-2 routers. No area is defined as the backbone in this topology. The backbone comprises all contiguous Level-2 and Level-1-2 routers in different areas. The IS-IS backbone does not need to be a specific area.
area, so a Level-1 router sends packets destined for other areas to the nearest Level-1-2 router. The path passing through the Level-1-2 router may not be the best. To solve this problem, IS-IS provides the route leaking feature. Route leaking enables a Level-1-2 router to advertise the routes of other Level-1 areas and the Level-2 area to the connected Level-1 area so that the Level-1 routers can select the optimal routes for packets.
A pseudonode represents a virtual node on the broadcast network. It is not a real router. In IS-IS, it is identified by the system ID of the DIS and a one-byte Circuit ID (a non-zero value). Using pseudonodes can reduce the resources consumed by SPF and simplify network topology. NOTE: On an IS-IS broadcast networks, all routers establish adjacency relationships, but they synchronize their LSDBs through the DIS. IS-IS PDUs PDU IS-IS PDUs are encapsulated in link layer frames.
Table 4 PDU types Type PDU Type Acronym 15 Level-1 LAN IS-IS hello PDU L1 LAN IIH 16 Level-2 LAN IS-IS hello PDU L2 LAN IIH 17 Point-to-Point IS-IS hello PDU P2P IIH 18 Level-1 Link State PDU L1 LSP 20 Level-2 Link State PDU L2 LSP 24 Level-1 Complete Sequence Numbers PDU L1 CSNP 25 Level-2 Complete Sequence Numbers PDU L2 CSNP 26 Level-1 Partial Sequence Numbers PDU L1 PSNP 27 Level-2 Partial Sequence Numbers PDU L2 PSNP Hello PDU IS-to-IS hello PDUs (IIHs) are used by routers
• Source ID—System ID of the router advertising the hello packet. • Holding time—If no hello packets are received from the neighbor within the holding time, the neighbor is considered down. • PDU length—Total length of the PDU in bytes. • Priority—DIS priority. • LAN ID—Includes the system ID and a one-byte pseudonode ID. Figure 17 shows the hello packet format on the point-to-point networks.
Figure 18 L1/L2 LSP format Major fields of the L1/L2 LSP are as follows: • PDU length—Total length of the PDU in bytes. • Remaining lifetime—LSP remaining lifetime in seconds. • LSP ID—Consists of the system ID, the pseudonode ID (one byte) and the LSP fragment number (one byte). • Sequence number—LSP sequence number. • Checksum—LSP checksum. • P (Partition)—Partition bit that is only for L2 LSPs. This field indicates whether the router supports partition repair.
Figure 19 LSDB overload SNP A sequence number PDU (SNP) describes the complete or partial LSPs for LSDB synchronization. SNPs include Complete SNP (CSNP) and Partial SNP (PSNP), which are further divided into Level-1 CSNP, Level-2 CSNP, Level-1 PSNP and Level-2 PSNP. A CSNP describes the summary of all LSPs for LSDB synchronization between neighboring routers. On broadcast networks, CSNPs are sent by the DIS periodically (10s by default).
Figure 21 L1/L2 PSNP format Intradomain routing protocol discriminator R No. of Octets 1 Length indicator 1 Version/Protocol ID extension 1 ID length 1 R R PDU type 1 Version 1 Reserved 1 Maximum area address 1 PDU length 2 Source ID ID length+1 Variable length fields CLV The variable fields of PDU comprise multiple Code-Length-Value (CLV) triplets. Figure 22 CLV format Table 5 shows that different PDUs contain different CLVs.
CLV Code Name PDU Type 131 Inter-Domain Routing Protocol Information L2 LSP 132 IP Interface Address IIH, LSP Supported IS-IS features Multiple instances and processes IS-IS supports multiple instances and processes. Multiple processes allow an IS-IS process to work in concert with a group of interfaces. A router can run multiple IS-IS processes, and each process corresponds to a unique group of interfaces.
more link state information in extended LSP fragments. Each virtual system can be considered a virtual router. An extended LSP fragment is advertised by a virtual system identified by an additional system ID. • Operation modes: The LSP fragment extension feature operates in the following modes: { { Mode-1—Applicable to a network where some routers do not support LSP fragment extension.
• RFC 3567, Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication • RFC 3719, Recommendations for Interoperable Networks using IS-IS • RFC 3786, Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit • RFC 3787, Recommendations for Interoperable IP Networks using IS-IS • RFC 3784, IS-IS extensions for Traffic Engineering • RFC 3847, Restart signaling for IS-IS 31
BGP The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Overview Border Gateway Protocol (BGP) is an exterior gateway protocol. It is called internal BGP (IBGP) when it runs within an AS and called external BGP (EBGP) when it runs between ASs. The current version in use is BGP-4 (RFC 4271). Unless otherwise stated, BGP refers to BGP-4 in this document.
• Notification—BGP sends a Notification message upon detecting an error and immediately closes the connection. BGP path attributes BGP uses the following path attributes in update messages for route filtering and selection: • ORIGIN The ORIGIN attribute identifies the origin of routing information (how a route became a BGP route). This attribute has the following types: { IGP—Has the highest priority. Routes generated in the local AS have the IGP attribute. { EGP—Has the second highest priority.
passing AS40 for sending data to the destination 8.0.0.0. In some applications, you can apply a routing policy to control BGP route selection by modifying the AS_PATH length. { • Filter routes—By configuring an AS path filtering list, you can filter routes based on AS numbers contained in the AS_PATH attribute. For more information about routing policies and AS path filtering lists, see Network Management Configuration Guide.
Figure 25 MED attribute MED = 0 Router B 2.1.1.1 D = 9.0.0.0 Next_hop = 2.1.1.1 MED = 0 EBGP IBGP 9.0.0.0 IBGP Router A D = 9.0.0.0 Next_hop = 3.1.1.1 MED = 100 AS 10 EBGP Router D IBGP 3.1.1.1 Router C AS 20 MED = 100 Generally, BGP only compares MEDs of routes received from the same AS. You can also use the compare-different-as-med command to force BGP to compare MED values of routes received from different ASs.
Figure 26 LOCAL_PREF attribute • COMMUNITY The COMMUNITY attribute identifies the community of BGP routes. A BGP community is a group of routes with the same characteristics. It has no geographical boundaries. Routes of different ASs can belong to the same community. A route can carry one or more COMMUNITY attribute values (each of which is represented by a four-byte integer).
3. Summary route 4. Shortest AS_PATH 5. IGP, EGP, or INCOMPLETE route in turn 6. Lowest MED value 7. Learned from EBGP, confederation, or IBGP in turn 8. Smallest next hop metric 9. Shortest CLUSTER_LIST 10. Smallest ORIGINATOR_ID 11. Advertised by the router with the smallest router ID 12. Advertised by the peer with the lowest IP address CLUSTER_IDs of route reflectors form a CLUSTER_LIST.
{ BGP has no route computation algorithm, so it cannot implement load balancing according to metrics of routes. However, BGP has abundant route selection rules, through which, it selects available routes for load balancing and adds load balancing to route selection rules. BGP implements load balancing only on routes that have the same AS_PATH, ORIGIN, LOCAL_PREF and MED, rather than using the route selection rules as described in "BGP route selection.
BGP route dampening solves the issue of route instability such as route flaps—a route comes up and disappears in the routing table frequently. When a route flap occurs, the routing protocol sends an update to its neighbor, and then the neighbor recalculates routes and modifies the routing table. Frequent route flaps consume too many resources and affect other operations. In most cases, BGP runs in complex networks, where route changes are more frequent.
information received from a client to other clients. In this way, all clients can receive routing information from one another without establishing BGP sessions. A router that is neither a route reflector nor a client is a non-client, which, as shown in Figure 29 must establish BGP sessions to the route reflector and other non-clients. Figure 29 Network diagram for a route reflector The route reflector and clients form a cluster. Typically a cluster has one route reflector.
Figure 31 Confederation network diagram A non-confederation BGP speaker does not need to know sub-ASs in the confederation. It considers the confederation as one AS, and the confederation ID as the AS number. In the above figure, AS 200 is the confederation ID. Confederation has a deficiency. When you change an AS into a confederation, you must reconfigure your routers, and the topology will be changed. In large-scale BGP networks, both route reflector and confederation can be used.
MP-BGP uses these attributes to advertise feasible and unfeasible routes of different network layer protocols. BGP speakers not supporting MP-BGP ignore updates containing these attributes and do not forward them to its peers. The system supports multiple MP-BGP extensions, including VPN extension, IPv6 extension (see Network Management Configuration Guide), and multicast extension.
• RFC 2858, Multiprotocol Extensions for BGP-4 • RFC 3392, Capabilities Advertisement with BGP-4 • RFC 2918, Route Refresh Capability for BGP-4 • RFC 2439, BGP Route Flap Damping • RFC 1997, BGP Communities Attribute • RFC 2796, BGP Route Reflection • RFC 3065, Autonomous System Confederations for BGP • RFC 4271, A Border Gateway Protocol 4 (BGP-4) • RFC 4360, BGP Extended Communities Attribute • RFC 4724, Graceful Restart Mechanism for BGP • RFC 4760, Multiprotocol Extensions for BGP-4
IPv6 static routing The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work properly. Static routes cannot adapt to network topology changes. If a fault or a topological change occurs in the network, the network administrator has to modify the static routes manually.
IPv6 default route The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. An IPv6 default route is used to forward packets that match no entry in the routing table. An IPv6 default route can be configured in either of the following ways: • The network administrator can configure a default route with a destination prefix of ::/0. For more information, see Network Management Configuration Guide.
RIPng The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Overview RIP next generation (RIPng) is an extension of RIP-2 for IPv4. Most RIP concepts are applicable in RIPng. RIPng for IPv6 has the following basic differences from RIP: • UDP port number—RIPng uses UDP port 521 for sending and receiving routing information. • Multicast address—RIPng uses FF02:9 as the link-local-router multicast address.
RIPng packet format Basic format A RIPng packet consists of a header and multiple route table entries (RTEs). The maximum number of RTEs in a packet depends on the IPv6 MTU of the sending interface. Figure 32 RIPng basic packet format Packet header description: • Command—Type of message. 0x01 indicates Request, 0x02 indicates Response. • Version—Version of RIPng. It can only be 0x01. • RTE—Route table entry. It is 20 bytes for each entry.
• Prefix length—Length of the IPv6 address prefix • Metric—Cost of a route RIPng packet processing procedure Request packet When a RIPng router first starts or must update entries in its routing table, it usually sends a multicast request packet to ask for needed routes from neighbors. The receiving RIPng router processes RTEs in the request.
OSPFv3 The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Overview Open Shortest Path First version 3 (OSPFv3) supports IPv6 and complies with RFC 2740 (OSPF for IPv6).
LSA types OSPFv3 sends routing information in LSAs, which, as defined in RFC 2740, have the following types: • Router-LSA—Originated by all routers. This LSA describes the collected states of the router's interfaces to an area, and is flooded throughout a single area only. • Network-LSA—Originated for broadcast and NBMA networks by the Designated Router. This LSA contains the list of routers connected to the network, and is flooded throughout a single area only.
SPF timer Whenever the LSDB changes, an SPF calculation happens. If recalculations become frequent, a large amount of resources are occupied. You can adjust the SPF calculation interval and delay time to protect networks from being overloaded due to frequent changes.
IPv6 IS-IS The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. Overview Intermediate System-to-Intermediate System (IS-IS) supports multiple network protocols, including IPv6. To support IPv6, the IETF added two type-length-values (TLVs) and a new network layer protocol identifier (NLPID). The two TLVs are as follows: • IPv6 Reachability—Contains routing prefix and metric information to describe network reachability and has a type value of 236 (0xEC).
IPv6 BGP The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. This chapter describes only configuration for IPv6 BGP. For BGP-related information, see Network Management Configuration Guide. BGP-4 can only carry IPv4 routing information. To support multiple network layer protocols, IETF extended BGP-4 by introducing Multiprotocol Border Gateway Protocol (MP-BGP). MP-BGP for IPv6 is called "IPv6 BGP" for short.
Multicast overview Overview As a technique that coexists with unicast and broadcast, the multicast technique effectively addresses the issue of point-to-multipoint data transmission. By enabling high-efficiency point-to-multipoint data transmission over a network, multicast greatly saves network bandwidth and reduces network load.
In unicast transmission, the traffic transmitted over the network is proportional to the number of hosts that need the information. If a large number of hosts need the information, the information source must send a separate copy of the same information to each of these hosts. Sending many copies can place a tremendous pressure on the information source and the network bandwidth. Unicast is not suitable for batch transmission of information.
Figure 38 Multicast transmission As shown in Figure 38, the multicast source sends only one copy of the information to a multicast group. Host B, Host D and Host E, which are receivers of the information, must join the multicast group. The routers on the network duplicate and forward the information based on the distribution of the group members. Finally, the information is correctly delivered to Host B, Host D, and Host E.
For a better understanding of the multicast concept, you can compare multicast transmission to the transmission of TV programs. Table 7 Comparing TV program transmission and multicast transmission TV transmission Multicast transmission A TV station transmits a TV program through a channel. A multicast source sends multicast data to a multicast group. A user tunes the TV set to the channel. A receiver joins the multicast group.
Multicast models Based on how the receivers treat the multicast sources, the multicast models include any-source multicast (ASM), source-filtered multicast (SFM), and source-specific multicast (SSM). • ASM model—In the ASM model, any sender can send information to a multicast group as a multicast source, and receivers can join a multicast group (identified by a group address) and obtain multicast information addressed to that multicast group.
Multicast addresses Network-layer multicast addresses (namely, multicast IP addresses) enables communication between multicast sources and multicast group members. In addition, a technique must be available to map multicast IP addresses to link-layer multicast MAC addresses. The membership of a group is dynamic. Hosts can join or leave multicast groups at any time. IP multicast addresses • IPv4 multicast addresses: The IANA assigned the Class D address space (224.0.0.0 to 239.255.255.
Address Description 224.0.0.12 DHCP server/relay agent. 224.0.0.13 All PIM routers. 224.0.0.14 RSVP encapsulation. 224.0.0.15 All CBT routers. 224.0.0.16 SBM. 224.0.0.17 All SBMs. 224.0.0.18 VRRP. IPv6 multicast addresses: • Figure 39 IPv6 multicast format The following describes the fields of an IPv6 multicast address, as shown in Figure 39: { { 0xFF—The most significant eight bits are 11111111, which indicates that this address is an IPv6 multicast address.
{ Scope—The Scope field contains four bits, which indicate the scope of the IPv6 internetwork for which the multicast traffic is intended. Table 11 describes the values of the Scope field. Table 11 Values of the Scope field Value Meaning 0, F Reserved. 1 Interface-local scope. 2 Link-local scope. 3 Subnet-local scope. 4 Admin-local scope. 5 Site-local scope. 6, 7, 9 through D Unassigned. 8 Organization-local scope. E Global scope. { Group ID—The Group ID field contains 112 bits.
Figure 42 An example of IPv6-to-MAC address mapping Multicast protocols This section provides only general descriptions about applications and functions of the Layer 3 multicast protocols supported by the firewalls (IGMP, PIM, IPv6 PIM, and MSDP). For more information about these protocols, see the related chapters. Layer 3 multicast protocols include multicast group management protocols and multicast routing protocols.
{ { An intra-domain multicast routing protocol discovers multicast sources and builds multicast distribution trees within an AS to deliver multicast data to receivers. Among a variety of mature intra-domain multicast routing protocols, Protocol Independent Multicast (PIM) is most widely used. Based on the forwarding mechanism, PIM has dense mode (often referred to as "PIM-DM") and sparse mode (often referred to as "PIM-SM").
Multicast routing and forwarding Overview In multicast implementations, the following types of tables implement multicast routing and forwarding: • Multicast routing table of a multicast routing protocol—Each multicast routing protocol has its own multicast routing table, such as the PIM routing table. • General multicast routing table—The multicast routing information of different multicast routing protocols forms a general multicast routing table.
{ 2. The router searches its static multicast routing table by using the IP address of the packet source as the source address and automatically chooses an optimal static multicast route. The route explicitly defines the RPF interface and the RPF neighbor. The firewall selects one of the optimal routes as the RPF route according to the following principles: { { If the firewall uses the longest match principle, it selects a matching route as the RPF route by using this principle.
from the multicast source to the receivers. The multicast forwarding table on Router C contains the (S, G) entry, with GigabitEthernet 0/1 as the incoming interface. Figure 44 RPF check process IP Routing Table on Router C Destination/Mask Interface 192.168.0.0/24 GE0/1 Router B Receiver GE0/1 Source 192.168.0.
Figure 45 Changing an RPF route As shown in Figure 45, when no static multicast route is configured, Router C's RPF neighbor on the path back to Source is Router A. The multicast information from Source travels along the path from Router A to Router C, which is the unicast route between the two routers.
Router C and Router D, to specify Router B as the RPF neighbor of Router C and Router C as the RPF neighbor of Router D, the receiver hosts will receive the multicast data from the multicast source. Multicast forwarding across unicast subnets Some networking devices might not support multicast protocols in a network. Multicast devices forward multicast traffic from a multicast source hop by hop along the forwarding tree.
Introduction to multicast traceroute packets A multicast traceroute packet is a special IGMP packet that is different from common IGMP packets in that its IGMP Type field is set to 0x1F or 0x1E and its destination IP address is a unicast address. The following types of multicast traceroute packets are available: • Query—Its IGMP Type field set to 0x1F. • Request—Its IGMP Type field set to 0x1F. • Response—Its IGMP Type field set to 0x1E. Process of multicast traceroute 1.
IGMP Overview As a TCP/IP protocol responsible for IP multicast group member management, the IGMP is used by IP hosts and adjacent multicast routers to establish and maintain their multicast group memberships. The term "router" in this document refers to both routers and routing-capable firewalls and UTM devices. IGMP versions • IGMPv1 (documented in RFC 1112) • IGMPv2 (documented in RFC 2236) • IGMPv3 (documented in RFC 3376) All IGMP versions support the ASM model.
Figure 48 IGMP queries and reports Assume that Host B and Host C are interested in multicast data addressed to multicast group G1, and Host A is interested in multicast data addressed to G2, as shown in Figure 48. The following process describes how the hosts join the multicast groups and how the IGMP querier (Router B in the figure) maintains the multicast group memberships: 1.
IGMPv2 overview Compared with IGMPv1, IGMPv2 has introduced a querier election mechanism and a leave-group mechanism. Querier election mechanism In IGMPv1, the DR elected by the Layer 3 multicast routing protocol (such as PIM) serves as the querier among multiple routers on the same subnet. IGMPv2 introduced an independent querier election mechanism. The querier election process is as follows: 1.
Enhancements in control capability of hosts IGMPv3 introduced two source filtering modes (Include and Exclude). These modes allow a host to join a designated multicast group and to choose whether to receive or reject multicast data from a designated multicast source. When a host joins a multicast group, one of the following occurs: • If it expects to receive multicast data from specific sources like S1, S2, …, it sends a report with the Filter-Mode denoted as "Include Sources (S1, S2, …).
Unlike an IGMPv1 or IGMPv2 report message, an IGMPv3 report message is destined to 224.0.0.22 and contains one or more group records. Each group record contains a multicast group address and a multicast source address list. Group records fall into the following categories: { { IS_IN—The source filtering mode is Include. The report sender requests the multicast data from only the sources defined in the specified multicast source list. IS_EX—The source filtering mode is Exclude.
Figure 50 IGMP SSM mapping As shown in Figure 50, on an SSM network, Host A, Host B, and Host C run IGMPv1, IGMPv2, and IGMPv3, respectively. To provide SSM service for all the hosts if IGMPv3 is not available on Host A and Host B, you must configure the IGMP SSM mapping feature on Router A.
Figure 51 IGMP proxying As shown in Figure 51, an IGMP proxy device has the following types of interfaces: • Upstream interface—Also called the "proxy interface." A proxy interface is an interface on which IGMP proxying is configured. It is in the direction toward the root of the multicast forwarding tree. An upstream interface acts as a host that is running IGMP. Therefore, it is also called the "host interface.
PIM Overview PIM provides IP multicast forwarding by leveraging unicast static routes or unicast routing tables generated by any unicast routing protocol, such as RIP, OSPF, IS-IS, or BGP. Independent of the unicast routing protocols running on the device, multicast routing can be implemented as long as the corresponding multicast routing entries are created through unicast routes. PIM uses the RPF mechanism to implement multicast forwarding.
Neighbor discovery In a PIM domain, a PIM router discovers PIM neighbors and maintains PIM neighboring relationship with other routers. It also builds and maintains SPTs by periodically multicasting hello messages to all other PIM routers (224.0.0.13) on the local subnet. Every PIM-enabled interface on a router sends hello messages periodically, and thus learns the PIM neighboring information pertinent to the interface. SPT building The process of building an SPT is the flood-and-prune process. 1.
The flood-and-prune process takes place periodically. A pruned state timeout mechanism is provided. A pruned branch restarts multicast forwarding when the pruned state times out and then is pruned again when it no longer has any multicast receiver. Graft When a host attached to a pruned node joins a multicast group, to reduce the join latency, PIM-DM uses a graft mechanism to resume data forwarding to that branch. The process is as follows: 1.
3. The routers compare these parameters, and either Router A or Router B becomes the unique forwarder of the subsequent (S, G) packets on the shared-media subnet. The comparison process is as follows: a. The router with a higher preference to the source wins. b. If both routers have the same preference to the source, the router with a smaller metric to the source wins. c. If a tie exists in route metric to the source, the router with a higher IP address on the downstream interface wins.
Neighbor discovery PIM-SM uses a similar neighbor discovery mechanism as PIM-DM does. For more information, see "Neighbor discovery." DR election PIM-SM also uses hello messages to elect a DR for a shared-media network (such as Ethernet). The elected DR will be the only multicast forwarder on this shared-media network. A DR must be elected in a shared-media network, no matter this network connects to multicast sources or to receivers. The receiver-side DR sends join messages to the RP.
RP discovery The RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP is enough for forwarding information throughout the network, and you can statically specify the position of the RP on each router in the PIM-SM domain. An RP can serve multiple multicast groups or all multicast groups, but a given multicast group can have only one RP to serve it at a time.
Table 12 Values in the hashing algorithm Value Description Value Hash value. G IP address of the multicast group. M Hash mask length. Ci IP address of the C-RP. & Logical operator of "and." XOR Logical operator of "exclusive-or." Mod Modulo operator, which gives the remainder of an integer division.
node from the outgoing interface list and examines whether it has receivers for that multicast group. If not, the router continues to forward the prune message to its upstream router. Multicast source registration The purpose of multicast source registration will inform the RP about the existence of the multicast source. Figure 57 Multicast source registration As shown in Figure 57, the multicast source registers with the RP as follows: 1.
Switchover to SPT In a PIM-SM domain, a multicast group corresponds to one RP and RPT. Before a switchover to SPT occurs, the source-side DR encapsulates all multicast data destined to the multicast group in register messages and sends these messages to the RP. After receiving these register messages, the RP extracts the multicast data and sends the multicast data down the RPT to the receiver-side DRs. The RP acts as a transfer station for all multicast packets.
To implement refined management, you can divide a PIM-SM domain into one global scope zone and multiple administratively scoped zones (admin-scope zones). This is called the "administrative scoping mechanism." The administrative scoping mechanism effectively releases stress on the management in a single-BSR domain and enables provision of zone-specific services through private group addresses. Admin-scope zones are divided specific to multicast groups.
Each admin-scope zone serves specific multicast groups, of which the multicast group addresses are valid only within the local zone. The multicast groups of different admin-scoped zones might have intersections. All the multicast groups other than those of the admin-scoped zones are served by the global-scoped zone.
SPT building The decision to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether the multicast group that the receiver will join falls into the SSM group range. (SSM group range reserved by IANA is 232.0.0.0/8.) Figure 60 SPT building in PIM-SSM Host A Source RP DR Server Receiver Host B DR Receiver SPT Subscribe message Multicast packets Host C As shown in Figure 60, Host B and Host C are multicast information receivers.
• RFC 5059, Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) • RFC 4607, Source-Specific Multicast for IP • Draft-ietf-ssm-overview-05, An Overview of Source-Specific Multicast (SSM) 89
MSDP Overview MSDP is an inter-domain multicast solution that addresses the interconnection of protocol independent multicast sparse mode (PIM-SM) domains. It discovers multicast source information in other PIM-SM domains. In the basic PIM-SM mode, a multicast source registers only with the RP in the local PIM-SM domain, and the multicast source information about a domain is isolated from that of another domain.
Figure 61 Where MSDP peers are in the network As shown in Figure 61, an MSDP peer can be created on any PIM-SM router. MSDP peers created on PIM-SM routers, that assume different roles, will function differently. 1. MSDP peers on RPs include the following types: { { { 2. Source-side MSDP peer—The MSDP peer nearest to the multicast source (Source), typically the source-side RP, like RP 1.
Figure 62 Inter-domain multicast delivery through MSDP The process of implementing PIM-SM inter-domain multicast delivery by leveraging MSDP peers is as follows: 1. When the multicast source in PIM-SM 1 sends the first multicast packet to multicast group G, DR 1 encapsulates the multicast data within a register message and sends the register message to RP 1. Then, RP 1 identifies the information related to the multicast source. 2.
An MSDP mesh group refers to a group of MSDP peers that have MSDP peering relationships among one another and share the same group name. When using MSDP for inter-domain multicasting, once an RP receives information form a multicast source, it no longer relies on RPs in other PIM-SM domains. The receivers can override the RPs in other domains and directly join the multicast source-based SPT. RPF check rules for SA messages As shown in Figure 63, the autonomous systems in the network are AS 1 through AS 5.
Although RP 4 and RP 5 are in the same AS (AS 3) and both are MSDP peers of RP 6, because RP 5 has a higher IP address, RP 6 accepts only the SA message from RP 5. 5. When RP 7 receives the SA message from RP 6: Because the SA message is from a static RPF peer (RP 6), RP 7 accepts the SA message and forwards it to other peer (RP 8). 6. When RP 8 receives the SA message from RP 7: A BGP or MBGP route exists between two MSDP peers in different ASs.
Figure 64 Intra-domain Anycast RP through MSDP The working process of Anycast RP is as follows: 4. The multicast source registers with the nearest RP. In this example, Source registers with RP 1, with its multicast data encapsulated in the register message. When the register message arrives at RP 1, RP 1 de-encapsulates the message. 5. Receivers send join messages to the nearest RP to join in the RPT rooted as this RP. In this example, Receiver joins the RPT rooted at RP 2. 6.
IPv6 multicast routing and forwarding Overview In IPv6 multicast implementations, the following types of tables implement multicast routing and forwarding: • Multicast routing table of an IPv6 multicast routing protocol—Each IPv6 multicast routing protocol has its own multicast routing table, such as the IPv6 PIM routing table. • General IPv6 multicast routing table—The multicast routing information of different IPv6 multicast routing protocols forms a general IPv6 multicast routing table.
{ 2. The router searches its IPv6 MBGP routing table by using the IPv6 address of the packet source as the destination address and automatically selects an optimal MBGP route. The outgoing interface of the route is the RPF interface and the next hop is the RPF neighbor. The router selects one of the optimal routes as the RPF route according to the following principles: { { If the router uses the longest match principle, it selects the longest matching route as the RPF route.
NOTE: Some device models allow you to configure special processing of IPv6 multicast packets that have failed an RPF check instead of simply dropping them. Assume that IPv6 unicast routes are available in the network, IPv6 MBGP is not configured, and IPv6 multicast packets travel along the SPT from the multicast source to the receivers, as shown in Figure 65. The IPv6 multicast forwarding table on Router C contains the (S, G) entry, with POS 5/1 as the RPF interface.
Figure 66 IPv6 multicast data transmission through a tunnel As shown in Figure 66, with a GRE tunnel established between the multicast routers Router A and Router B, Router A encapsulates the IPv6 multicast data in unicast IPv6 packets, and forwards them to Router B across the GRE tunnel through unicast routers. Then, Router B strips off the unicast IPv6 header and continues to forward the IPv6 multicast data down toward the receivers.
IPv6 PIM Overview IPv6 PIM provides IPv6 multicast forwarding by leveraging IPv6 unicast static routes or IPv6 unicast routing tables generated by any IPv6 unicast routing protocol, such as RIPng, OSPFv3, IS-ISv6, or BGP4+. IPv6 PIM uses an IPv6 unicast routing table to perform RPF check to implement IPv6 multicast forwarding.
• Assert Neighbor discovery In an IPv6 PIM domain, a PIM router discovers IPv6 PIM neighbors, maintains IPv6 PIM neighboring relationship with other routers, and builds and maintains SPTs by periodically multicasting IPv6 PIM hello messages to all other IPv6 PIM routers on the local subnet. Every IPv6 PIM enabled interface on a router sends hello messages periodically, and, therefore, learns the IPv6 PIM neighboring information pertinent to the interface.
Figure 67 SPT establishment in an IPv6 PIM-DM domain Host A Source Receiver Host B Server Receiver SPT Prune message IPv6 multicast packets Host C The flood-and-prune process takes place periodically. A pruned state timeout mechanism is provided. A pruned branch restarts multicast forwarding when the pruned state times out and then is pruned again when it no longer has any multicast receiver.
Figure 68 Assert mechanism As shown in Figure 68, the assert mechanism is as follows: 1. After Router A and Router B receive an (S, G) IPv6 multicast packet from the upstream node, both of them forward the packet to the local subnet. As a result, the downstream node Router C receives two identical multicast packets, and both Router A and Router B, on their own downstream interfaces, receive a duplicate IPv6 multicast packet that the other has forwarded. 2.
RPTs. An RPT is rooted at a router in the IPv6 PIM domain as the common node, or RP, through which the IPv6 multicast data travels along the RPT and reaches the receivers. • When a receiver is interested in the IPv6 multicast data addressed to a specific IPv6 multicast group, the router connected to this receiver sends a join message to the RP corresponding to that IPv6 multicast group. The path along which the message goes hop-by-hop to the RP forms a branch of the RPT.
Figure 69 DR election As shown in Figure 69, the DR election process is as follows: 1. Routers on the shared-media network send hello messages to one another. The hello messages contain the router priority for DR election. The router with the highest DR priority will become the DR. 2.
RPs. The BSR then encapsulates the RP-set in the bootstrap messages it periodically originates and floods the BSMs to the entire IPv6 PIM-SM domain. Figure 70 BSR and C-RPs Based on the information in the RP-sets, all routers in the network can calculate the location of the corresponding RPs based on the following rules: 1. The C-RP with the highest priority wins. 2. If all the C-RPs have the same priority, their hash values are calculated through the hashing algorithm.
Embedded RP The embedded RP mechanism enables a router to resolve the RP address from an IPv6 multicast address so that the IPv6 multicast group is mapped to an RP. This RP can take the place of the statically configured RP or the RP dynamically calculated based on the BSR mechanism. The DR does not need to learn the RP address beforehand. The specific process is as follows. At the receiver side: • a. A receiver host initiates an MLD report to announce that it is joining an IPv6 multicast group. b.
When a receiver is no longer interested in the IPv6 multicast data addressed to the multicast group G, the directly connected DR sends a prune message, which goes hop-by-hop along the RPT to the RP. After receiving the prune message, the upstream node deletes the interface connected with this downstream node from the outgoing interface list and examines whether it has receivers for that IPv6 multicast group. If not, the router continues to forward the prune message to its upstream router.
NOTE: In this section, the RP is configured to initiate a switchover to SPT. If the RP is not configured with switchover to SPT, the DR at the IPv6 multicast source side keeps encapsulating multicast data in register messages, and the registration process will not stop unless no outgoing interfaces exist in the (S, G) entry on the RP. Switchover to SPT In an IPv6 PIM-SM domain, an IPv6 multicast group corresponds to one RP and one RPT.
IPv6 administrative scoping overview Typically, an IPv6 PIM-SM domain contains only one BSR, which is responsible for advertising RP-set information within the entire IPv6 PIM-SM domain. The information for all multicast groups is forwarded within the network scope administered by the BSR. This is called the "IPv6 non-scoped BSR mechanism." To implement refined management, an IPv6 PIM-SM can be divided into one IPv6 global scope zone and multiple IPv6 administratively scoped zones (IPv6 admin-scope zones).
Figure 73 Relationship in view of geographical locations As shown in Figure 73, for the IPv6 multicast groups with the same scope field value, the IPv6 admin-scope zones must be geographically separated and isolated. The IPv6 global-scoped zone includes all routers in the IPv6 PIM-SM domain. IPv6 multicast packets that do not belong to any IPv6 admin-scope zones are forwarded in the entire IPv6 PIM-SM domain.
Value Meaning Remarks 6, 7, 9 through D Unassigned IPv6 admin-scope zone. 8 Organization-local scope IPv6 admin-scope zone. E Global scope IPv6 global-scope zone. IPv6 PIM-SSM overview The SSM model and the ASM model are opposites. The ASM model includes the IPv6 PIM-DM and IPv6 PIM-SM modes. The SSM model can be implemented by leveraging part of the IPv6 PIM-SM technique, and it is also called "IPv6 PIM-SSM." The SSM model provides a solution for source-specific multicast.
Figure 75 Building an SPT in IPv6 PIM-SSM Host A Source RP DR Server Receiver Host B DR Receiver SPT Subscribe message IPv6 multicast packets Host C As shown in Figure 75, Hosts B and C are IPv6 multicast information receivers. They send an MLDv2 report message to the respective DRs to announce that they are interested in the information about the specific IPv6 multicast source S and that sent to the IPv6 multicast group G.
• RFC 4607, Source-Specific Multicast for IP • draft-ietf-ssm-overview-05, An Overview of Source-Specific Multicast (SSM) 114
MLD Overview An IPv6 router uses the MLD protocol to discover the presence of multicast listeners on the directly attached subnets. Multicast listeners are nodes wishing to receive IPv6 multicast packets. Through MLD, the router can learn whether any IPv6 multicast listeners exist on the directly connected subnets, put corresponding records in the database, and maintain timers related to IPv6 multicast addresses.
Joining an IPv6 multicast group Figure 76 MLD queries and reports IPv6 network Querier Router A Router B Ethernet Host A (G2) Host B (G1) Host C (G1) Query Report Assume that Host B and Host C will receive IPv6 multicast data addressed to IPv6 multicast group G1, and Host A will receive IPv6 multicast data addressed to G2, as shown in Figure 76.
1. The host sends an MLD done message to all IPv6 multicast routers on the local subnet. The destination address is FF02::2. 2. After receiving the MLD done message, the querier sends a configurable number of multicast-address-specific queries to the group that the host is leaving. The destination address field and group address field of the message are both filled with the address of the IPv6 multicast group that is being queried. 3.
In MLDv1, Host B cannot select IPv6 multicast sources when it joins IPv6 multicast group G. Therefore, IPv6 multicast streams from both Source 1 and Source 2 will flow to Host B whether it needs them or not. When MLDv2 is running on the hosts and routers, Host B can explicitly express its interest in the IPv6 multicast data that Source 1 sends to G (denoted as (S1, G)), rather than the IPv6 multicast data that Source 2 sends to G (denoted as (S2, G)).
Figure 78 MLDv2 query message format 3 4 0 7 Type = 130 15 31 Code Checksum Maximum Response Delay Reserved Multicast Address (128 bits) Reserved S QRV QQIC Number of Sources (n) Source Address [1] (128 bits) Source Address [n] (128 bits) Table 15 MLDv2 query message field description Field Description Type = 130 Message type. For a query message, this field is set to 130. Code Initialized to zero. Checksum Standard IPv6 checksum.
Field Description • This field is set to 0 in a general query message or a Number of Sources multicast-address-specific query message. • This field represents the number of source addresses in a multicast-address-and-source-specific query message. Source Address( i ) IPv6 multicast source address in a multicast-address-specific query message. (i = 1, 2, .., n, where n represents the number of multicast source addresses.
MLD SSM mapping The MLD SSM mapping feature enables you to configure static MLD SSM mappings on the last-hop router to provide SSM support for receiver hosts that are running MLDv1. The SSM model assumes that the last-hop router has identified the desired IPv6 multicast sources when receivers join IPv6 multicast groups. • When a host that runs MLDv2 joins a multicast group, it can explicitly specify one or more multicast sources in its MLDv2 report.
MLD proxying In some simple tree-shaped topologies, you do not need to configure complex IPv6 multicast routing protocols, such as IPv6 PIM, on the boundary devices. Instead, you can configure MLD proxying on these devices. With MLD proxying configured, the device serves as a proxy for the downstream hosts to send MLD messages, maintain group memberships, and implement IPv6 multicast forwarding based on the memberships.
• RFC 4605, Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") 123
Support and other resources Contacting HP For worldwide technical support information, see the HP support website: http://www.hp.
Conventions This section describes the conventions used in this documentation set. Command conventions Convention Description Boldface Bold text represents commands and keywords that you enter literally as shown. Italic Italic text represents arguments that you replace with actual values. [] Square brackets enclose syntax choices (keywords or arguments) that are optional. { x | y | ... } Braces enclose a set of required syntax choices separated by vertical bars, from which you select one.
Network topology icons Represents a generic network device, such as a router, switch, or firewall. Represents a routing-capable device, such as a router or Layer 3 switch. Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports Layer 2 forwarding and other Layer 2 features. Represents a firewall product or a UTM device. Port numbering in examples The port numbers in this document are for illustration only and might be unavailable on your device.
Index ABCDHILMNOPRST 230H 231H 23H 23H 234H 235H 236H 237H 238H 239H 240H 241H 24H IS-IS PDUs,23 A 597H Administrative scoping overview,85 L B Load sharing,3 569H 598H LSA types,11 BGP configuration views,42 59H LSA types,50 570H BGP load balancing,37 60H 571H BGP message types,32 M BGP path attributes,33 MLD message types,118 572H 573H 601H BGP route advertisement rules,37 MLD proxying,122 574H 602H BGP route selection,36 MLD SSM mapping,121 57H 603H BGP speaker
Overview,49 RIPng packet format,47 RIPng packet processing procedure,48 P RIPng working mechanism,46 Packets,49 Route backup,3 PIM-DM overview,77 Route calculation,15 PIM-SM overview,80 Route preference,2 PIM-SSM overview,87 Route recursion,3 Protocols and standards,122 Route redistribution,3 Protocols and standards,76 Route types,14 Protocols and standards,95 Router types,14 Protocols and standards,113 Routing table,1 Protocols and standards,88 RPF check implementation in IPv6 multicas
