HP VPN Firewall Appliances Appendix Protocol Reference Part number: 5998-4171 Software version: F1000-A-EI/F1000-S-EI (Feature 3726) F1000-E (Release 3177) F5000 (Feature 3211) F5000-S/F5000-C (Release 3808) VPN firewall modules (Release 3177) 20-Gbps VPN firewall modules (Release 3817) Document version: 6PW101-20130923
Legal and notice information © Copyright 2013 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 ·················································································································································································· 21 IS-IS area ········································································································································································· 21 Level-1 and Level-2 ··························································································································
Protocols and standards ················································································································································ 52 IPv6 IS-IS ····································································································································································· 53 Overview·······················································································································································
RP discovery ··························································································································································· 83 RPT building ··························································································································································· 85 Multicast source registration································································································································· 85 Switch
How MLDv2 works ······················································································································································· 119 IPv6 multicast group filtering ······························································································································ 119 MLD state ······························································································································································ 120 Recei
IP routing basics The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. 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.
• NextHop—Next hop. • 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 RIP 100 OSPF ASE 150 OSPF NSSA 150 IBGP 255 EBGP 255 Unknown (route from an untrusted source) 256 Load sharing A routing protocol might 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 firewall modules. Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work correctly. 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 firewall modules. 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 firewall modules. 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.
Routing loop prevention RIP uses the following mechanisms to prevent routing loops: • 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.
RIP message format A RIP message consists of a header and up to 25 route entries. (A RIPv2 authentication message uses the first route entry as the authentication entry, so it has up to 24 route entries.) 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.
• IP address—Destination IP address. It can be a natural network address, subnet address or host address. • Subnet mask—Mask of the destination address. • Next hop—If set to 0.0.0.0, it indicates that the originator of the route is the best next hop; otherwise it indicates a next hop better than the originator of the route. RIPv2 authentication message format RIPv2 sets the AFI field of the first route entry to 0xFFFF to identify authentication information.
• RFC 1724, RIP Version 2 MIB Extension • RFC 2082, RIPv2 MD5 Authentication • RFC 2091, Triggered Extensions to RIP to Support Demand Circuits • RFC 2453, RIP Version 2 10
OSPF The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. 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 met 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 firewall modules. 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 DSP includes the high order part of DSP (HO-DSP), System ID, and SEL, where the HO-DSP identifies the area, the System ID identifies the host, and the SEL identifies the type of service. 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.
NET A network entity title (NET) indicates the network layer information of an IS. It does not include transport layer information. A NET is a special NSAP address with the SEL being 0. The length of a NET ranges from 8 bytes to 20 bytes, same as a NSAP 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.
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 might 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.
The DIS creates and updates pseudonodes, as well as generates their LSPs, to describe all routers on the network. 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.
• Version—Set to 1(0x01). • Maximum area address—Maximum number of area addresses supported.
Major fields of the L1/L2 LAN IIH are as follows: • Reserved/Circuit type—The first six bits are reserved with a value of 0. The last two bits indicate the router type—00 means reserved, 01 indicates L1, 10 indicates L2, and 11 indicates L1/2. • 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.
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 (10 seconds 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.
{ • Extended LSP—Extended LSPs are generated by virtual systems. The system ID in its LSP ID field is the virtual system ID. After additional system IDs are configured, an IS-IS router can advertise 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.
• RFC 3358, Optional Checksums in ISIS • RFC 3373, Three-Way Handshake for IS-IS Point-to-Point Adjacencies • 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
BGP The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. 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.
{ { • Affect route selection—BGP gives priority to the route with the shortest AS_PATH length if other factors are the same. As shown in Figure 23, the BGP router in AS 50 gives priority to the route passing AS 40 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.
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.
{ { IGP routing protocols, such as RIP and OSPF, compute metrics of routes, and then implement load balancing over routes with the same metric and to the same destination. The route selection criterion is metric. 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.
The system supports both manual and automatic route summarization. Manual route summarization allows you to determine the attribute of a summary route and whether to advertise more specific routes. • Route dampening BGP route dampening solves the issue of route instability such as route flaps—a route comes up and disappears in the routing table frequently.
IBGP peers must be fully meshed to maintain connectivity. If n routers exist in an AS, the number of IBGP connections is n(n-1)/2. If a large number of IBGP peers exist, large amounts of network and CPU resources are consumed to maintain sessions. Using route reflectors can solve this issue. In an AS, a router acts as a route reflector, and other routers act as clients connecting to the route reflector. The route reflector forwards the routing information received from a client to other clients.
• Confederation Confederation is another method to manage growing IBGP connections in an AS. It splits an AS into multiple sub-ASs. In each sub-AS, IBGP peers are fully meshed. As shown in Figure 31, intra-confederation EBGP connections are established between sub-Ass in AS 200. 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.
• MP_REACH_NLRI—Multiprotocol Reachable NLRI, for carrying prefixes of feasible routes and next hops for multiple network layer protocols. Such routes can then be advertised. • MP_UNREACH_NLRI—Multiprotocol Unreachable NLRI, for carrying prefixes of unfeasible routes for multiple network layer protocols. Such routes can then be withdrawn. MP-BGP uses these attributes to advertise feasible and unfeasible routes of different network layer protocols.
Protocols and standards • RFC 1700, ASSIGNED NUMBERS • RFC 1771, A Border Gateway Protocol 4 (BGP-4) • 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 At
IPv6 static routing The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. Static routes are manually configured. If a network's topology is simple, you only need to configure static routes for the network to work correctly. 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 firewall modules. 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 firewall modules. 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 firewall modules. 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.
LSA delay timer Each LSA has an age in the local link state database (LSDB) (incremented by one per second), but an LSA does not age on transmission. You must add an LSA delay time into the age time before transmission, which is important for low-speed networks. SPF timer Whenever the LSDB changes, an SPF calculation happens. If recalculations become frequent, a large amount of resources are occupied.
IPv6 IS-IS The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. 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).
IPv6 BGP The term "router" in this document refers to both routers and routing-capable firewalls and firewall modules. 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) enable 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 assigns the Class D address space (224.0.0.0 to 239.255.255.
• Address Description 224.0.0.11 Mobile agents. 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 (IGMP, PIM, IPv6 PIM, and MSDP) supported by the firewalls. 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.
multicast packets from the multicast source in the RIP domain. If you configure a static multicast route on 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.
• Querier—The router that sends multicast traceroute requests is called the "querier." 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.
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. 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 As shown in Figure 48, 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. 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 include 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.
Figure 52 SPT building Host A Source Receiver Host B Server Receiver SPT Prune message 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 53 Assert mechanism As shown in Figure 53, the assert mechanism is as follows: 1. After Router A and Router B receive an (S, G) packet from the upstream node, both routers 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 packet forwarded by the other. 2.
router in the PIM domain as the common node, or RP, through which the multicast data travels along the RPT and reaches the receivers. • When a receiver is interested in the multicast data addressed to a specific multicast group, the router connected to this receiver sends a join message to the RP associated with that multicast group. The path along which the message goes hop-by-hop to the RP forms a branch of the RPT.
Figure 54 DR election As shown in Figure 54, 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. In the case of a tie in the router priority, or if any router in the network does not support carrying the DR-election priority in hello messages, the router with the highest IP address will win the DR election. 3.
and RPs. The BSR then encapsulates the RP-set in the BSMs that it periodically originates and floods the bootstrap messages to the entire PIM-SM domain. Figure 55 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.
RPT building Figure 56 RPT building in a PIM-SM domain Host A Source RP DR Server Receiver Host B DR Receiver RPT Join message Multicast packets Host C As shown in Figure 56, the process of building an RPT is as follows: 1. When a receiver joins the multicast group G, it uses an IGMP message to inform the directly connected DR. 2. After getting the receiver information, the DR sends a join message, which is forwarded hop-by-hop to the RP that corresponds to the multicast group. 3.
Figure 57 Multicast source registration As shown in Figure 57, the multicast source registers with the RP as follows: 1. The multicast source S sends the first multicast packet to multicast group G. 2. After receiving the multicast packet, the DR that directly connects to the multicast source encapsulates the packet in a PIM register message, and then sends the message to the corresponding RP by unicast. 3. When the RP receives the register message, it does the following: a.
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. The whole process involves the following issues: • The source-side DR and the RP need to implement complicated encapsulation and de-encapsulation of multicast packets. • Multicast packets are delivered along a path that might not be the shortest one.
Admin-scoped zones are divided specific to multicast groups. Zone border routers (ZBRs) form the boundary of the admin-scoped zone. Each admin-scoped zone maintains one BSR, which serves multicast groups within a specific range. Multicast protocol packets, such as assert messages and bootstrap messages, for a specific group range cannot cross the admin-scoped zone boundary. Multicast group ranges that different admin-scoped zones serve can be overlapped.
Figure 59 Relationship in view of multicast group address ranges Admin-scope 1 Admin-scope 3 G1 address G3 address Admin-scope 2 Global-scope G2 address G−G1−G2 address As shown in Figure 59, the admin-scoped zones 1 and 2 have no intersection, but the admin-scoped zone 3 is a subset of the admin-scoped zone 1. The global-scoped zone serves all the multicast groups that are not covered by the admin-scoped zones 1 and 2, that is, G−G1−G2 in this case.
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 is in 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.
Protocols and standards • RFC 3973, Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification(Revised) • RFC 4601, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised) • 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) 91
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.
4. When RP 6 receives the SA messages from RP 4 and RP 5 (suppose RP 5 has a higher IP address): 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.
Figure 64 Intra-domain Anycast RP through MSDP The working process of Anycast RP is as follows: 1. 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. 2. 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. 3.
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 prefix 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. As shown in Figure 65, 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. 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 to 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 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. It 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 forwarded by the other. 2.
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 All routers in the network calculate the location of the corresponding RPs based on the information in the RP-sets and 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. The C-RP with the largest hash value wins.
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 has only 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.
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-scoped 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-scoped zones are forwarded in the entire IPv6 PIM-SM domain.
Value Meaning Remarks 8 Organization-local scope IPv6 admin-scoped zone. E Global scope IPv6 global-scoped 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. It maintains the relationship between hosts and routers through MLDv2.
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, Host B and Host 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) 116
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 As shown in Figure 76, assume that Host B and Host C want to receive IPv6 multicast data addressed to IPv6 multicast group G1, and Host A want to receive IPv6 multicast data addressed to G2.
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 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 • RFC 4605, Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") 125
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 security product, such as a firewall, a UTM, or a load-balancing or security card that is installed in a device.
Index ABCDHILMNOPRST A IS-IS PDUs,24 Administrative scoping overview,87 L B Load sharing,3 LSA types,12 BGP configuration views,43 LSA types,51 BGP load balancing,38 BGP message types,33 M BGP path attributes,34 MLD message types,120 BGP route advertisement rules,38 MLD proxying,124 BGP route selection,37 MLD SSM mapping,123 BGP speaker and BGP peer,33 MLD versions,117 C MP-BGP,42 Multicast architecture,59 Contacting HP,126 Multicast forwarding across unicast subnets,69 Conventions,127
RIPng packet processing procedure,49 P RIPng working mechanism,47 Packets,50 Route backup,3 PIM-DM overview,78 Route calculation,16 PIM-SM overview,81 Route preference,2 PIM-SSM overview,89 Route recursion,3 Protocols and standards,115 Route redistribution,3 Protocols and standards,77 Route types,15 Protocols and standards,124 Router types,15 Protocols and standards,97 Routing table,1 Protocols and standards,91 RPF check implementation in IPv6 multicast,99 Protocols and standards,52 RP
