Multicasting in Intra and Inter Domain...

i

Technical Report, IDE1106, February 2011

Multicasting in Intra and Inter Domain

Networks Master’s Thesis in Computer Network Engineering

Shahzad Hayat Khan and Jehan Badshah

School of Information Science, Computer and Electrical Engineering Halmstad University

ii

Multicasting in Intra and Inter Domain Networks

Master’s Thesis in Computer Network Engineering

School of Information Science, Computer and Electrical Engineering Halmstad University

Box 823, S-301 18 Halmstad, Sweden

iii

Multicasting in intra and inter Domain networks

Preface

We really thank our supervisor Professor Tony Larsson for his support, encouragement

guidance and suggestions. We would also like to thank the staff at the Department of

Computer and Electrical Engineering, University of Halmstad for their assistance and

positive attitude.

Finally, we want to express our thanks to our family and friends who have supported and

encouraged us during our study period.

Shahzad Hayat Khan & Jehan Badshah

Halmstad University, February 2011.

v

Introduction

Abstract Multicasting in a network improves the efficiency to deliver an IP packet to multiple clients at the same time. Small to medium sized organizations implement this technology to enhance their network capability, which is otherwise not possible just with normal routing. However, to use this technology, it requires proper network design with tidy resource implementation. Network administrators prefer automatic deployment of multicast technology because it reduces the potential risk of prolonged down time during network troubleshooting. On the other hand, choosing an auto deployment technology could cause malfunctioning in the network. To avoid such malfunctioning, we used two technologies: Auto-RP (Auto- Rendezvous Point) [1] and Bootstrap [2] in our network. A problem that occurs here is that if different domains with similar or different technologies want to share their resources with each other, then regular multicasting cannot connect them for successful communication. Also, if an administrator wishes to provide short and redundant paths within a domain, then these two technologies do not possess the ability to do so. The thesis presents issues in intra-domain and inter-domain multicast networks; it also focuses on Auto-RP (Auto Rendezvous Point) and BSR (Bootstrap Router) which are technologies related to multicasting. This project highlights the importance of multicasting security and will brief the problems associated with these two technologies. It will offer a better solution with a properly implemented design guide. The study uses MSDP (Multicast Source Discovery Protocol) [3] which connects two domains with multicasting capabilities for exchanging the source and providing redundancy in intra-domain. The work implements MBGP (Multicast Border Gateway Protocol) [4] to avoid a situation in which there is no multicast support on one of the service provider(s) end. Keywords: Auto-RP (Auto-Rendezvous Point), BSR (Bootstrap Router), MSDP (Multicast Source Discovery Protocol), MBGP (Multicast Border Gateway Protocol)

vi

Multicasting in intra and inter Domain networks

vii

Introduction 1 INTRODUCTION ................................................................................................................................. 1

1.1 PROBLEM ...................................................................................................................................... 2 1.2 MOTIVATION .................................................................................................................................. 2 1.3 APPROACH .................................................................................................................................... 2 1.4 OBJECTIVES .................................................................................................................................. 2

2 BACKGROUND WORK ..................................................................................................................... 3

2.1 THE EVOLUTION OF MULTICAST ................................................................................................... 3 2.2 DESIGN OF SCALABLE INTER-DOMAIN IP MULTICAST ARCHITECTURE ........................................ 3 2.3 INTER-DOMAIN MULTICAST ROUTING WITH IPV6 ......................................................................... 4 2.4 MULTICAST ROUTING PROTOCOLS IN A MULTIPLE DOMAIN NETWORK ..................................... 4 2.5 INTRA DOMAIN MULTICAST ROUTING PROTOCOLS ..................................................................... 4 2.6 INTER DOMAIN MULTICAST ROUTING PROTOCOLS ..................................................................... 5

3 MULTICASTING TECHNOLOGY EXPLANATION ...................................................................... 7

3.1 MULTICASTING OVERVIEW ........................................................................................................... 7 3.2 PIM ............................................................................................................................................... 8 3.3 AUTOMATIC DEPLOYMENT OF RPS .............................................................................................. 8 3.3.1 Auto-RP ................................................................................................................................. 8 3.3.2 Bootstrap .............................................................................................................................. 8

3.4 MSDP ........................................................................................................................................... 9 3.5 MBGP .......................................................................................................................................... 9

4 MULTICAST OPERATION: INTRA-DOMAIN ............................................................................. 11

4.1 NETWORK SETUP ........................................................................................................................ 11 4.2 BASIC NETWORK CONNECTIVITY AND SETUP ............................................................................ 12 4.3 RPF CHECKS AND TROUBLESHOOTING .................................................................................... 12 4.4 BOOTSTRAP IMPLEMENTATION IN DOMAIN B ............................................................................. 15 4.5 IMPLEMENTING ANY-CAST OPERATION ..................................................................................... 16 4.6 SIMULATION RESULTS ................................................................................................................ 21

5 MULTICAST OPERATION: INTER-DOMAIN .............................................................................. 23

5.1 RP CONFLICT ............................................................................................................................. 24 5.2 DOMAIN SECURITY AND FILTERING ................................................................................................. 25 5.3 CONNECTING DOMAINS .............................................................................................................. 26 5.4 SOURCE SECURITY AND RATE LIMIT .......................................................................................... 28 5.5 MBGP EXTENSION TO MULTICASTING ...................................................................................... 29 5.6 SIMULATION RESULTS ................................................................................................................ 31

6 CONCLUSION AND FUTURE WORK .......................................................................................... 33

7 ABBREVIATIONS ............................................................................................................................ 35

8 REFERENCES ................................................................................................................................... 37

9 APPENDIX ......................................................................................................................................... 39

APPENDIX A .............................................................................................................................................. 39 APPENDIX B ............................................................................................................................................... 44 APPENDIX C ............................................................................................................................................... 45

viii

APPENDIX D .............................................................................................................................................. 45 APPENDIX E ............................................................................................................................................... 46 APPENDIX F ............................................................................................................................................... 47 APPENDIX G .............................................................................................................................................. 47 APPENDIX H .............................................................................................................................................. 47 APPENDIX I ................................................................................................................................................ 47 APPENDIX J ................................................................................................................................................ 47 APPENDIX K .............................................................................................................................................. 48 APPENDIX L ............................................................................................................................................... 48 APPENDIX M .............................................................................................................................................. 48

ix

Introduction

x

List of Figures Figure 1 : Unicast based network .................................................................................................................... 7 Figure 2: Multicast Network Diagram…........................................................................................................11 Figure 3 : RPF Failure ....................................................................................................................... ............13 Figure 4 : MSDP(Any-cast Operation ........................................................................................................... 17 Figure 5: MBGP (Example)................…........................................................................................................23

1


1 Introduction Most organizations use multicasting for audio announcements, video conferencing or news feed etc. from distant locations. It is important to bear in mind that subscribing to the same server from multiple clients can create problems related to performance and availability of the multicast network. It is possible that many clients could face performance issues because they have to travel through a longest path for getting announcements and joining the server. The problem that arises in the routing world is that if multiple clients are interested to get the same data from a server then individual data packet must be generated for each client at the source. In other words, each client is served individually at the server end. This approach of data delivery to multiple clients is not efficient and puts burden over the network resources. Multicasting provides the capability to send a single IP packet down the path from a source towards multiple destinations. At a transit point, an individual copy for each client is generated and delivered to all interested clients. Thus, the traffic burden is minimized at the source. This way of data delivery is more efficient, scalable and enhances the network performance significantly. The major problem area in multicasting is that redundancy and inter-domain connectivity are not direct features of multicast configuration. Each time when a client joins a server to receive multicast traffic, it has to consult the Rendezvous Point (RP). If there are multiple clients and they wish to join or leave the server, they have to ask this RP for their multicast operation. There is a possibility that the RP could fail due to the heavy multicast load. If RP failure occurs, multicast will cease to function. To avoid such failure, it is important to provide redundancy and load balancing inside the domain. An interesting fact about multicasting is that two separate domains cannot share their sources information directly. For enforcing security, multicast boundary must be created between different domains. If two domains do not deploy boundaries, then these domains with similar or different RP operations will start overlapping. The reason for this fluctuation is that whichever RP that learns the source information first will flood it to the rest of the network. If there is no source subscriber associated with the RP, it will prune the information. Whereas in another request, it may be possible that another RP floods the data. This could cause source information leakage and may inject false information in the network. In order to avoid such a situation, multicast boundaries are essential to prevent the network from malfunctioning. However, creating multicast boundaries will stop sources from announcing information between each other and will cause isolation of two domains. Another issue which influences multicasting is Service Level Agreement (SLA). In some cases the ISP does not provide the facility of multicasting and MBGP is used to eradicate this problem and provide alternate backup link.

2

1.1 Problem If too many clients ask the same RP for information then the possibility may exist that this RP becomes unavailable or becomes unresponsive. In such circumstances, there is a potential risk that the multicast network will collapse. It is feasible to implement two RPs in the network, but such design will require a larger amount of administrative input in order to control different RPs for different announcements. This however, is not a recommended approach. If two different domains have an agreement to connect with each other, there are possible loop holes of technologies overlapping or a multicasting disagreement with the service provider.

1.2 Motivation The study provides complete end to end solution for an administrator to setup a successful multicasting network. Performance of the network will be improved by providing single packet transmission to multiple hosts. Various applications for example Citrix, Terminal Servers Clusters, and Microsoft Media Servers etc can be easily operated on this network. This project is a good motivation for a domain to enterprise based administrator. It is not only restricted to just one domain or one technology but can also be used as a guideline for deploying and troubleshooting multicasting between the ISP.

1.3 Approach In this project the aim is to provide a design and solution guide for intra and inter-domain multicast routing. The focus is on the problems associated with in domains. This report and implementation is important for design consideration for configuring automatic deployment of intra and inter-domain multicasting. This project tests the network’s functionality through IGMP. In real world networks IGMP can be replaced with end servers. This network is ready to carry the unicast as well as multicast based traffic.

1.4 Objectives The main objectives of this thesis are: • To tell what multicasting is and ways for how to implement it. • To achieve load balancing and path redundancy in Intra- domain networks. • To prevent information leakage between domains and achieve Inter-domain connectivity. • To implement multicast security and to address the SLA problem.

The structure of this thesis is as follows: Chapter 2: Related Work, Chapter 3: Multicasting technology explained, Chapter 4: Multicast Operation: Intra-domain Chapter 5: Multicast Operation: Inter-domain and Chapter 6: Conclusion and future work.

3


2 Background work Although multicasting is a broad subject area, there is very little practical work relating to its configuration in the network. Several of the articles pay greater attention to the architecture and technologies used for multicasting whereas the work in this thesis is more concerned with the practical implementation of these technologies.

2.1 The evolution of multicast In this study [5], a brief description about the standard IP multicast model, its requirements and the way clients send/ receive multicast packets is presented. The model motivated the use of multicast on the internet and created the Multicast Backbone (MBone). Distance Vector Multicast Routing Protocol (DVMRP) was the original protocol used for multicast routing on the MBone. In order to fulfil the requirements for inter-domain routing and hierarchical infrastructure, the available protocols at that time were sorted out as intra-domain protocols. Work started on inter-domain solution’s standardization. Multicast Extension to Open Shortest Path First (MOSPF), Protocol Independent Multicast-Dense Mode (PIM-DM), Protocol Independent Multicast- Sparse Mode (PIM-SM) and Core Based Trees (CBT) are the protocols developed and used for multicast. MBone has grown over time and problems such as scalability and manageability have increased alongside it. In order to provide internet-wide, hierarchical and scalable multicast, inter-domain multicast has been evolved. The required protocols and their desired functionality for this purpose has been developed and considered by the Internet Engineering Task Force (IETF) but they are still in the early stages of development. There is a lack of scalability and elegance which as a result requires long-term solutions from a future perspective. Multicast Source Discovery Protocol (MSDP), PIM-SM and Multicast Border Gateway Protocol (MBGP) protocols are considered as near-term solutions for multicast whilst Border Gateway Protocol (BGMP), Multicast Address-set Claim (MASC) and GLOP are the long-term proposals for inter-domain multicasting and work is underway on the development of these protocols. In order to avoid the complexity of MBGP, MSDP, PIM-SM and BGMP and other multicast issues (billing, security and management) several fundamental changes are offered in the multicast model. Route Address Multicast Architecture (RAMA) is one of the proposals stating that multicast applications must be a single source or primary source with easy identification. Express multicast and Simple multicast are the two styles that RAMA provides for multicasting.

2.2 Design of scalable inter-domain IP multicast architecture The author in [6] has proposed scalable architecture for IP multicasting by reducing the routing information of multicast traffic. This is to address the problem of large routing information which makes IP multicasting less scalable on the internet.

4

Two types of multicast addresses have been implemented in this architecture: Virtual Multicast Address (VMA) which specifies multicast group within a certain domain (intra-domain) and Multicast Address for Routing (MAR) which forwards multicast traffic between different domains (inter-domain). With these address types, the multicast address allocation becomes more flexible and also reduces the routing information by address aggregation.

2.3 Inter-domain multicast routing with IPV6 PIM-SM is a commonly used multicast routing protocol both in IPv4 and IPv6 [7]. It builds a unidirectional distribution tree between hosts and Rendezvous Point (RP) for multicast packet forwarding. To deploy PIM-SM, source and destination must use the same RP. This is a suitable solution in intra-domain but not as much in inter-domain due to policy reasons. IPv4 inter-domain multicast uses MSDP that enables RPs to exchange their source information which alternatively provides different networks to implement their own global RPs. In comparison, IPv6 doesn’t provide such protocols because this mechanism leads to another prune and unstable broadcast protocol. Embedded-RP with IPv6 addressing capabilities is an alternate solution in which the RP address is embedded into the group address. This makes it easier for the router to know immediately the group address. By using embedded-RP, a common RP is required for a certain group because RPs have no way to exchange information. In addition to this, embedded-RP enables small organizations to use their own RPs for sessions which they are hosting.

2.4 Multicast Routing Protocols in a Multiple Domain Network In this paper [8], the authors discussed different protocols needed for routing between multiple domains. PIM-SM is a suitable protocol used for Multicast routing within a single domain (intra-domain multicast). In order to enable multiple PIM-SM domains for multicasting, another protocol Multicast Source Discovery Protocol MSDP is implemented. This protocol is used to establish and maintain different routing policies for multicast and Unicast traffic. Even though standards for multicasting are not yet finalized, IP multicast technology is still being adopted by major networks. Source Specific Multicast (SSM) is another suitable solution for intra-domain multicasting, mostly for IP multimedia services whereas MSDP along with MBGP are solutions for inter-domain multicasting. Apart from these solutions, research on QoS in the IP multicast is still needed.

2.5 Intra Domain Multicast Routing Protocols Multicast protocols should use minimal network overhead, must be scalable, consume less memory resources and must be able to operate with other multicast routing protocols in the network and most importantly, be easy to implement. The technique used for managing the

5

participants, for example, joining and leaving a multicast group is an important factor when designing a multicast protocol. Other factors that need to be focused on during the design of multicast protocols depend on the participants that distribute over the routing domain, their role in the group, the number of groups and maximum participant in each group [9]. Distance Vector Multicast Routing Protocol (DVMRP), DVMRPv3, Multicast Open Shortest Path First (MOSPF), Core Base Tree (CBT), PIM-DM, PIM-SM and Multicast Internet Protocol (MIP) are classified as intra-domain multicast protocols by IETF.

2.6 Inter Domain Multicast Routing Protocols Inter-domain multicast routing protocols are required for successful communication across multiple domains between clients and server. Many things have to be considered while designing these protocols. Most importantly such protocols must be scalable with low overhead and work well with other protocols [9]. Yet-Another Multicast (YAM), Quality of Service-Sensitive Multicast Routing Protocol (QoSMIC), Policy Tree Multicast Routing (PTMR), Multicast Source Discovery Protocol (MSDP), MASC/BGMP, Distance Vector Multicast Routing Protocol (HDVMRP), Hierarchical Protocol Independent Mode (HPIM), OCBT, Hierarchical Multicast Routing (HIP), Centralized Multicast, Static Multicast and Distributed Core Multicast (DCM) are being used for Inter- domain Multicast routing.

6

Background work

7


3 Multicasting Technology Explanation This section explores multicasting technology and the necessary components for creating a stable multicast network.

3.1 Multicasting Overview A router by default does not allow broadcasting and multicasting. However, it is still possible to configure a router to allow broadcasting over PPP or Frame relay network. Unlike Ethernet, this broadcast over WAN technology is from a specific source to a specific destination. If multiple destinations have to transit a router to reach a certain server then in return the router has to replicate the same packet multiple times for each individual host. The diagram below illustrates a unicast based network data flow.

Figure 1 : Unicast based network Nine clients want to collect data from the server. In response, the server has to replicate nine different packets for each destination client. Let us suppose that this is a video streaming server and the total speed of the link is 1.554 Mbps. Here, a total of 4.6 Mbps bandwidth is required to deliver this video streaming to all the clients simultaneously. In this case, since we have only 1.554 Mbps link, unicast routing cannot serve the simultaneous transmission of streaming to all these nine clients. On the other hand, if multicasting is implemented in the above network then only 512 Kbps of bandwidth will be sufficient to deliver successfully the video streaming to all the clients at the same time.

8

Multicasting requires a fully functional network before serving the clients in the network. There are three ways to implement multicasting in the network: MOSPF, DVMVPN or PIM [4]. OSPF and DVMVPN are out of the scope of this thesis and Cisco routers do not support them.

3.2 PIM Protocol Independent Multicast (PIM) is known as the routing protocol of multicasting and it builds its own routing table to keep states of multicast sources. It is a requirement of PIM that it should be enabled on all links from source to destination. It can be implemented in two ways: PIM Dense mode and PIM Sparse mode [10]. PIM dense mode is an obsolete technology because it consumes most of the bandwidth due to its nature of operation. Sparse mode is better in the sense that it does not flood the network with unnecessary traffic but in fact, it forwards packets when required. As discussed earlier, when a client wants to request data from a server, it cannot do it directly. The reason behind this is if a large number of clients request server at the same time, sever may experience a bottleneck situation. In order to solve this problem, one router in the network is chosen as a master for flooding multicast traffic. This router is called RP and is usually a middle router in the network. In a large enterprise, some clients are further apart from this RP whilst others are closer to it. This may cause longer response time by RP and longer connection time to the server. Similarly, another issue might be that if this RP fails to deliver its operation properly, then the whole multicast network will suffer. We will configure redundant RPs in our multicast network with the consideration of possible switch failovers. It will provide pre-emption of original RP to the clients with shortest path.

3.3 Automatic deployment of RPs There are two ways to implement automatic deployment:

3.3.1 Auto-RP Auto-RP [1] is a standalone Cisco propriety protocol and works on Cisco routers. It has the capability of automatic distribution of group-to-RP mappings in a PIM [10]. Auto-RP makes it easier to have multiple RPs within a domain and serves a range of different groups. It provides load balancing among many RPs and redundancy and tedious manual configuration. Auto-RP allows us to create multiple RPs as backups for each other.

.

3.3.2 Bootstrap The Bootstrap Router (BSR) [2] was first introduced in PIM version 2. BSR is IETF standard track protocol while Auto –RP is Cisco proprietary. This means that BSR will work with routers from multiple vendors, including Cisco routers. In a PIM domain one has to configure multiple Candidate BSRs in order to avoid a single point of failure. Candidate BSR will automatically elect a BSR by sending bootstrap messages. The router with the highest priority is elected as BSR. After selection, BSR will announce itself to all domains and will be responsible for queries related to multicasting. All Candidate BSRs will report to the BSR.

9

3.4 MSDP Multicast Source Discovery Protocol (MSDP) [3] explains how to connect two independent domains using PIM-SIM protocols. With MSDP, it is possible for both domains to use their own RP and they do not have to rely on each other’s RP whilst in their domains. In PIM-SIM model it is necessary for source and receiver to be registered with the local RP. However, a point to consider here is that the local RP only has information about sources and receivers within a local domain. The issue faced is that RP does not have information about sources and receivers from other domains. MSDP allows us to solve this issue by maintaining an independent RP in each domain which enables RPs to forward traffic between different domains. The other benefit of MSDP is that the end receivers obtain data locally within the domain without globally advertising their group membership.

3.5 MBGP Multicast Protocol Gateway Protocol (MBGP) is based on RFC 2283[11] and 2858[4], these are Multiprotocol Extensions for BGP-4. It provides scalable, policy-based Inter-domain routing which can be used to support non-congruent unicast and multicast forwarding. It offers a way to differentiate which prefixes will be used for performing multicast reverse path forwarding (RPF) checks. The RPF check is essential in creating multicast forwarding trees and moving multicast content successfully from source to receiver(s). Two path attributes are introduced to BGP+ as described in Internet Draft draft-ieft-idr-bgp4-mutiprotocol-01.txt are MP_REACH_NLRI and MP_UNREACH_NLRI. For carrying two set of routes MBGP is an efficient technique. One set is used for unicast routing and one for multicast routing. The route links to multicast routing are used by multicast routing protocols to build data distribution trees.

10


11


4 Multicast Operation: Intra-domain The first part of this project focuses on the issues and implementation of multi-casting inside a domain. A domain is a set of network and server components under single administrative control. Therefore, an administrator has the authority to control the entire multicast and unicast based capabilities in accordance to his preferences. As discussed earlier, automatic rendezvous point is the best choice for automatic deployment of multicast announcements. Auto-RP and BSR are two technologies that exist for such a purpose and the thesis implements both in each domain.

4.1 Network setup The diagram below is a visual representation of the network:

Figure 2: Multicast Network Diagram In the diagram, two multicast domains are represented. Domain A has two servers with multicast address of 224.10.10.10 and 224.10.10.11 respectively. Similarly, Domain B has two servers with multicast address of 224.20.20.10 and 224.20.20.11. Domain A is capable of running Auto-RP, whereas Domain B is running BSR. The verification of redundancy in each domain will be checked by running multiple RP and connecting them via MSDP. The clients generate multicast traffic in their domain and the response time is checked in comparison with SPT (Shortest Path Tree). This section focuses on multicast functionality inside the domain only. The inter-domain connectivity and features will be discussed in detail in chapter five.

12

4.2 Basic Network Connectivity and setup As discussed earlier, multicasting requires a functional network to work properly. Different types of protocols can be run in the network for multicast routing. It does not matter whether a static or dynamic route has been chosen; the key point is that every network interface should be reachable. Before configuring a multicasting network, the following criteria should be met: • Enable PIM on all the interfaces from servers to clients. • Use static mcast to solve problems with links that are not multicast enabled. • If OSPF and EIGRP are on two ends and they are both redistributing then OSPF stub network

may cause connectivity issues. • CR and CA should be kept separate. • Implement all security features before implementing multicasting on the network. • Check that the network is functioning properly. Ping all devices and addresses used within the

network.

Configure the basic network setup on both sides [Appendix A]. Do not run any routing protocol between the domains yet. The interconnection between the two sites will be discussed in the next chapter. The basic network setup has been performed, it is important to check that each and every link is up and functional. There are various ways to check the reachability; tcl script [Appendix B] is used on each router to send ping requests to all interfaces. If at any stage, tcl script reports an unreachable destination then troubleshooting is required.

4.3 RPF Checks and Troubleshooting When building a multicast based network, it is necessary to setup all the links with PIM. As discussed in chapter 3, there are three ways to enable multicasting. However, two of these options-MOSPF and DMVPN are deprecated and are no longer supported by Cisco. This means that PIM is the only suitable option and works perfectly well. An explanation of RPF [12] (Reverse Path Forwarding) is illustrated in the diagram below.

13

Figure 3: RPF Failure In the figure the shortest path from client to server is via N2 → N3. When the client wants to send the request it will be a unicast request. The server will reply via multicast. The reply will always follow the shortest path defined by the routing protocol. In the exhibit above, PIM is not enabled between link N2 → N3; as a result the client will never get the data back from the server. This problem is called reverse path forwarding failure. There are four ways to tackle this problem: • Enable PIM between N2 → N3. • Configure a static mroute from N2 to N4, so that multicast traffic can be redirected. • Use the GRE tunnel to provide another multicast enabled link. • Use MBGP. MBGP implementation is explained in detail in the next chapter. RPF checks and verification is a sensitive piece of information and it can break the whole network. To demonstrate RPF check and its recovery, enable PIM on all the interfaces [Appendix C] but do not enable PIM on the link between R1 and R2. Ping the multicast address from Client 1 to the server and check the output. ping 224.10.10.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: ..........

14

According to the above output the ping failure is caused by RPF failure. This can be verified on R2. R2#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) failed, no route exists R2# RPF information shows that there is no route to the server. Confirm that RPF information is accurate on other routers. R3#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: FastEthernet0/1 RPF neighbor: ? (192.168.13.1) RPF route/mask: 10.1.1.0/24 RPF type: unicast (eigrp 1) RPF recursion count: 0 Doing distance-preferred lookups across tables R3# Since R3 has PIM enabled across all links, RPF information exists on R3. To correct RPF failure on R1 and R2, static mroute is used. R1 is configured for static mroute [Appendix D]. Ping the sever again. ping 224.10.10.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 192.168.13.1, 32 ms Reply to request 0 from 192.168.13.1, 32 ms Reply to request 1 from 192.168.13.1, 12 ms Reply to request 1 from 192.168.13.1, 52 ms

15

Reply to request 2 from 192.168.13.1, 4 ms Reply to request 2 from 192.168.13.1, 20 ms The reply from server to R2 is successful according to the output. However, the RPF check on R2 will still be unsuccessful because this path is not the shortest path according to the routing protocol. Confirm the reachability between both servers from both clients.

4.4 Bootstrap implementation in Domain B Bootstrap implementation is similar to Auto-RP but the difference is that Bootstrap only works in sparse mode. According to Appendix C, all the links have been configured in spare-dense mode. Auto-RP cannot work without this because the information from server to RP is always in dense mode, whereas the real traffic flows in sparse mode. Two groups will always be created in this way on all routers for dense mode operation.

R2#show ip mroute (*, 224.0.1.39), 00:34:09/00:02:13, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback1, Forward/Sparse-Dense, 00:34:09/00:00:00 FastEthernet0/1, Forward/Sparse-Dense, 00:34:09/00:00:00 (*, 224.0.1.40), 00:36:32/00:02:14, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:33:01/00:00:00 Loopback1, Forward/Sparse-Dense, 00:34:09/00:00:00 R2# The above output shows two groups 224.0.1.39 and 224.0.1.40 which are used by Auto-RP operation. The bootstrap operation works in a different way in the sense that the information is

16

learned on a hop by hop basis. In Auto-RP the information is directly passed from server to RP. Consequently, the server needs dense mode to push its information to RP. As bootstrap passes information on a hop by hop basis dense mode operation is not required. Configure Domain B with BSR operation [Appendix E]. Verify the connectivity and troubleshoot RPF checks, if necessary.

4.5 Implementing Any-cast Operation Any-cast operation helps a domain in providing multiple paths in the network. In a larger network, clients are normally connected far away from the RP. It is difficult for clients to choose a nearest RP for multicast flow. To give an example, ping Server 1 from Client 1 and check the response time. ping 224.10.10.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 192.168.13.1, 32 ms Reply to request 0 from 192.168.13.1, 32 ms Reply to request 1 from 192.168.13.1, 12 ms Reply to request 1 from 192.168.13.1, 52 ms Reply to request 2 from 192.168.13.1, 4 ms Reply to request 2 from 192.168.13.1, 20 ms The output shows different response times because currently Client 1 is learning source information from two places. There are two RPs at the moment in each domain and they both have information about the sources. When Client 1 initiates the joint request, both sources flood information to the client. In the above results, the longest delay is the information fed by the second RP, whereas the shortest delay is the information fed by the current RP. On a busy network, this can be a major issue for delay sensitive traffic like VoIP. At the moment, there is no other traffic flowing through the network and the delay transition is smoother. If more and more clients join the network however, it could cause problems for some traffic. In the case of one server stopping operation, Any-cast will provide multiple and redundant paths. The illustration of Any-cast operation is given in the figure below:

17

Figure 4: MSDP (Any-cast operation) In the figure, two RPs exist in the current domain. In order to provide redundant paths, a similar configuration is required on both Auto-RP routers. In this case, one extra loop back on each router is setup and advertised via IGP. Now, each router will reach this loop back according to its current IGP (Interior Gateway Protocol) metric and in the case of the nearest loopback failing, then another will take place. Appendix F carries out a similar configuration in the network advertised via IGP. Firstly, it is important to confirm whether or not the goal for creating the loopbacks has been achieved so far. Verify the routing table on R1 and check that both loopbacks exist in the routing table. R1#show ip route C 192.168.12.0/24 is directly connected, FastEthernet0/0 C 192.168.13.0/24 is directly connected, FastEthernet0/1 D 192.168.24.0/24 [90/307200] via 192.168.12.2, 00:02:06, FastEthernet0/0 10.0.0.0/24 is subnetted, 4 subnets D 10.4.4.0 [90/435200] via 192.168.13.3, 00:02:06, FastEthernet0/1 [90/435200] via 192.168.12.2, 00:02:06, FastEthernet0/0 D 10.3.3.0 [90/409600] via 192.168.13.3, 00:02:11, FastEthernet0/1

18

D 10.2.2.0 [90/409600] via 192.168.12.2, 00:02:19, FastEthernet0/0 C 10.1.1.0 is directly connected, Loopback1 192.168.255.0/32 is subnetted, 1 subnets D 192.168.255.255 [90/409600] via 192.168.13.3, 00:00:01, FastEthernet0/1 [90/409600] via 192.168.12.2, 00:00:01, FastEthernet0/0 D 192.168.34.0/24 [90/307200] via 192.168.13.3, 00:02:07, FastEthernet0/1 R1# R1 reports two paths to the same ip address. Telnet to 192.168.255.255 and check which path it prefers. R1#telnet 192.168.255.255 Trying 192.168.255.255 ... Open User Access Verification Password: R3> R1 telnet was redirected to R3 because R3 had the highest interface IP address. The router always preferred the path with highest IP address. To validate the configuration, shutdown the loopback on R3 and telnet again to the same address. R1#telnet 192.168.255.255 Trying 192.168.255.255 ... Open User Access Verification

19

Password: R2> R2> The telnet from R1 was directed to R2 because R3’s loop back address was in shutdown state. The following points should be considered before implementing Any-cast operation:

• If the IGP protocol is OSPF, make sure that this loop back interface is not the router-id for OSPF. • Also maintain the same practice for BGP. • If OSPF or BGP has chosen this loop-back as the router-id, make sure to hard code the router's ID

for OSPF and BGP. • When building MPLS LDP protocol via loop back interface, make sure that the connected source

is not this loop back interface.

Configure R2 and R3 [Appendix G], so that the sources for multicast operation become the loop back interfaces. Verify that current RP candidate is the new loop back interface. R4#show ip mroute IP Multicast Routing Table (*, 224.10.10.10), 00:05:25/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:05:25/00:00:00 FastEthernet0/0, Forward/Sparse-Dense, 00:05:25/00:00:00 (192.168.255.255, 224.10.10.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 192.168.34.3 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00

20

The output from R4 reveals that RP for 224.10.10.10 is 192.168.255.255 and the information is fed by R3 (192.168.34.3). Since R4 has the same equal path to R3 and R2, the tie breaker in deciding the best possible path is the highest interface IP address and in this case it is the IP address of R3. The purpose of configuring Any-cast was to overcome the problem caused in the previous section. When Client 1 initiated the request to join the multicast group 224.10.10.10 it caused a flood of information from multiple RPs. With Any-cast configuration, the client will get the information from its nearest RP due to the MSDP configuration. Ping 224.10.10.10 again and check the response time. ping 224.10.10.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 192.168.13.1, 32 ms Reply to request 0 from 192.168.13.1, 32 ms Reply to request 1 from 192.168.13.1, 30 ms Reply to request 1 from 192.168.13.1, 32 ms Reply to request 2 from 192.168.13.1, 31 ms Reply to request 2 from 192.168.13.1, 32 ms The output above indicates the constant RTT (Round Trip Time) from the nearest RP. At the moment, IGP reports the nearest RP through R2 and therefore the smallest SPT (Shortest Path Tree) is built through R2. The last part of this chapter is to confirm the reachability of the current RP in case it becomes unavailable. Shutdown the loop back interfaces on R2 and ping the source again from Client 1. R2#ping 224.10.10.10 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 192.168.12.1, 44 ms R2# The output displays the RTT of 44ms and that is because R3 is the RP for current communication. This outcome can be validated with the configuration below: #show ip mroute

21

IP Multicast Routing Table (*, 224.10.10.10), 00:05:25/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:05:25/00:00:00 FastEthernet0/0, Forward/Sparse-Dense, 00:05:25/00:00:00 (192.168.255.255, 224.10.10.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 192.168.13.3 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00 The output reveals that R3 is the current RP (192.168.13.3) and that is the IP address of R3 interface.

4.6 Simulation Results Multicasting requires a fully functional network. Implementation of Bootstrap is similar to Auto-RP but difference is in their way of working. In Auto-RP information from server to RP is in dense mode, whereas the real traffic is in sparse mode. On the other hand, Bootstrap works in sparse mode. It passes information hop by hop basis and thus does not require dense mode operation. In a larger network, it could be a problem for clients to communicate with the server with multiple RPs. As the information is fed by two sources there is a potential risk of network instability with its deployment. Any-cast operation ties two or more RPs with the same set of instructions, the client chooses the one reported by shortest IGP metric. In the configuration above, the response time on Client 1 from Server 1 was fluctuating. With Any-cast operation, the RTT became stable due to the SPT built by one RP. If the current RP goes down, clients can still reach the network through another RP. Any-cast operation is designed to work best in a larger network because it not only keeps the RP information uniform, but also provides fail over recovery and redundant paths.

23


5 Multicast Operation: Inter-domain The last section of this thesis addresses multicast operation between domains. In our network, there are two domains. It is totally up to the administrator whether he runs static RP assignments, Auto-RP or BSR in each domain or Auto-RP or BSR operation in both. The main purpose of Inter-domain multicasting is as follows:

• Creating multicast boundaries for stopping information leakage. • Dynamic multicast routing through MBGP, if the shortest path is not in SLA agreement • Multicast security

When two domains agree to link and share multicast information, certain challenges arrive. The main problem is the Service Level Agreement. If two domains are located far away and are connected through a service provider, it is possible that ISP has no SLA for multicast routing. In this case, MBGP is the solution to provide an alternate multicast enabled path for multicast packet flow. The illustration of MBGP is explained in the figure below:

Figure 5: MBGP Example N1 and N2 have no SLA to route multicast data. In such cases, these two domains can never route multicast traffic. The reason is that N1 and N2 will follow the shortest path defined by IGP and the same rule will be followed by PIM. In order to override such a problem, MBGP is the desired solution. MBGP will catch the multicast traffic and will route it through N3 and N4. MBGP scenario along with its configuration will be explained in detail later in this section.

24

5.1 RP Conflict Domain A and Domain B were configured in the previous chapter for Auto-RP and BSR operation. Configure the links between domain A and domain B [Appendix H]. As soon as the links are enabled for multicasting, both domains will start flooding multicast sources to each other. The problem that arises when implementing multicasting between the domains is the conflict between Auto-RP and BSR. The reason for this is that any RP, either Auto or BSR will try to inject its information when clients wish to join the multicast session. In this process, whoever reaches the client first will deliver its information first. To demonstrate this, ping the multicast server 224.10.10.10 from client 1 and check the RP on the client. #show ip mroute (192.168.255.255, 224.10.10.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00

In the output above, router 2 has been chosen as an RP because it was the first one to inject the RP information. In order to check the fluctuating RP, shut down the loop back interface on R2, so that it never becomes an RP candidate. Clear the current mroute table on R2 and confirm that R2 has no source information. Router2#clear ip mroute *

25

Generate ping from client 1 to server 1 and check the mroute table entry again. #show ip mroute (10.5.5.5, 224.10.10.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 192.168.13.3 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00

In the output 10.5.5.5 is chosen as current RP for Server 1. The problem is that both domains are now suffering from information leakage and RP conflict. Two problems can be faced in such a design. Firstly, RPF failure due to SLA terms and secondly multicast security. For example, the network configured has two servers each, if the information from one server needed to be stopped then it might not possible. This could be achieved by mapping agent filtering through local RP but this will stop agent from advertising it to local as well as remote domain. TTL security can also help in restricting source advertisement to certain hops but this solution is not scalable for future deployment.

5.2 Domain Security and Filtering The previous section highlighted the conflict between two domains. This part discusses filtering two domains at certain boundaries, and provides some level of security in order to stop advertising certain servers. Before implementing these features, confirm that Client 1 can reach a server in Domain B. Ping 224.20.20.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 192.168.36.3, 32 ms Reply to request 0 from 192.168.13.1, 32 ms Reply to request 1 from 192.168.13.1, 12 ms Reply to request 1 from 192.168.13.1, 52 ms Reply to request 2 from 192.168.13.1, 4 ms

26

The above output indicates that two domains are sharing information without any central agreement. This is potentially a major threat to security because there is no way to stop advertising them. The configuration of Appendix I show multicast boundaries between Domain A and Domain B. The main purpose of implementing multicast boundaries is to isolate two domains completely. As a result they cannot share any information about each other. To verify, ping server in Domain B again and check the response. Ping 224.20.20.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: …....... Now the ping is unsuccessful because the two domains stopped advertising their source(s) information about each other. Bear in mind that these boundaries will only affect multicast traffic. This configuration has no effect on unicast routing. Also verify that Client 3 cannot reach Server A in Domain A. Ping 224.10.10.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: …....... The above output indicates that Client 3 cannot reach any server in Domain A. It is now clear from these results that both domains are completely isolated from each other.

5.3 Connecting Domains The previous section created multicast boundaries in order to isolate domains. This section

discusses how to connect two domains and share multicast source information. The reason for filtering and isolation was to combat the conflict problem due to multiple RPs from different technologies. The filtering helps in learning source information from their current domain only. In order to learn source information from another domain MSDP is required to do so successfully.

27

MSDP works regardless of MBGP configuration. In most documentation, there is confusion with regards to whether or not MBGP is needed for proper MSDP operation. MSDP can work independently but if sources are subject to RPF failure, then MBGP is required to divert source information to another path in conjunction with MSDP. MSDP for inter-domain multicasting can also work between indirectly connected neighbours. The arguments require remote site interface IP, thus it could be a physical or loop back interface. The important thing to note here is that it must be reachable through underlying routing protocol. Configure Domain A and Domain B according to Appendix J. Ping the Sever in Domain B. Ping 224.20.20.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 10.5.5.5, 32 ms Reply to request 0 from 10.5.5.5, 32 ms Reply to request 1 from 10.5.5.5, 12 ms Reply to request 1 from 10.5.5.5, 52 ms Reply to request 2 from 10.5.5.5, 4 ms Now Client 1 is able to reach server in Domain B through MSDP. Check the current RP information on Client 1. #show ip mroute (10.5.5.5, 224.20.20.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 192.168.13.3 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00 The above output indicates that the current RP is R3. Also ping server in Domain A from Domain B and check the RP information. #show ip mroute (10.1.1.1, 224.10.10.10), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 10.5.5.5

28

Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00 The output shows that the RP for current multicast source is R 5 (10.5.5.5 is the IP of R5 in Domain B).

5.4 Source Security and rate limit After creating boundaries to isolate domains, it is also possible to filter certain sources to reach another domain. MSDP was configured to connect two sites and by doing so all the source(s) information was advertised to each other. There are two ways to accomplish this task. It can either be blocking the source information completely or limiting it to certain bandwidth. For example, Server B from Domain A can be blocked from advertisement to domain B or it can be restricted to certain bandwidth. Configure both domains [Appendix K] to stop advertising Server B to Domain B and Server D to Domain A. Generate ping from client 1 to Server D. Ping 224.20.20.11 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: …....... Check the access-list counters on R 3. R3# show access-list deny 224.10.10.11 (54 matches) permit any (114 matches) Also confirm that Client 3 cannot ping Server B in Domain A. Ping 224.10.10.11 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: …....... The output demonstrates the reachability failure to servers located in another domain. Also interface-counter about the access-list confirms the number of hits. This is one solution. It is also possible to rate-limit certain servers. Configure Domain A [Appendix L] to limit domain at maximum of 128 Kbps for Server B.

29

In the configuration above, any time clients from Domain B trying to join a server in Domain A would be given a total of 128 Kbps of bandwidth. It is also possible to restrict certain clients for rate-limiting, whereas allowing others to use unlimited bandwidth. For such a configuration, modify Appendix L access-list to extended access-list. Generate join request from Client 3 to Server B and check the show ip mroute for verification. Show ip mroute ip mutlicast routing table (10.4.4.4, 224.10.10.11), 00:02:28/00:00:32, flags: Incoming interface: FastEthernet0/0, RPF nbr 10.5.5.5 Outgoing interface list: FastEthernet0/1, Forward/Sparse-Dense, 00:02:28/00:00:00, limit 128Kbps In the output, multicast server 224.10.10.11 has been rate-limited to 128 Kbps total. It is a good design strategy for the server connected to slower links.

5.5 MBGP extension to Multicasting The last section of this chapter focuses on the discussion of MBGP extension to multicasting. From the previous chapter it is clear that RPF failure will occur if the return path of a multicast packet is not the shortest path. One method of solving this problem was configuring a static mroute to route multicast packets to another link. The function of static mroute is similar to the static route used in unicast routing. If RPF failure is occurring at different locations, the mroute will need to be configured at multiple places. The main reason of using MBGP for dynamic routing is the problem caused by Service Level Agreement. Multicasting will always prefer the shortest path if there are multiple routes to reach a destination from the source. If the shortest path is not supported by ISP for multicasting, then two domains can never share multicast information. To illustrate this, consider the primary link in the network. Both links have already been configured for multicasting and are connected via MSDP. The entire traffic passing between the domains is utilizing the primary link according to the shortest path rule. To verify this, generate mtrace from Client 1 to Server C in Domain B.

30

Mtrace 192.168.111.10 224.20.20.10 Type escape sequence to abort. Mtrace from 192.168.111.10 to 224.20.20.10 From source (?) to destination (?) Querying full reverse path... 0 155.1.111.3 -1 192.168.12.1 PIM Reached RP/Core [192.168.255.255/32] -2 192.168.13.3 PIM [192.168.255.255/32] -3 192.168.36.6 PIM Reached RP/Core [192.168.255.255/32] -4 192.168.56.5 PIM [192.168.255.255/32] -5 10.5.5.5 PIM [192.168.255.255/32] In the output above, Client 1 is using the primary link because it is the shortest path reported by IGP. To demonstrate the MBGP functionality, disable PIM on the primary link and verify the reachability from Client 1 to Server C. Ping 224.20.20.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: …....... As the backup link is also multicast capable it is connecting two domains via MSDP. The data cannot be routed due to RPF failure. This can be verified on R3. R3(config)#interface Serial 0/0

31

R3(config-if)#no ip mroute-cache R3#debug ip mpacket IP multicast packets debugging is on R3# IP(0): s=192.168.111.10 (Serial0/0) d=224.20.20.10 id=300, ttl=253, prot=1, len=104(100), not RPF interface Since serial 0/0 interface is not multicast capable, RPF failure occurs. This is where MBGP comes in. MBGP configuration will route traffic through the backup link but dynamically as opposed to static mroute. Appendix M provides MBGP configuration. Ping Server C in Domain B from Client 1 to confirm the reachability. Ping 224.20.20.10 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds: Reply to request 0 from 10.5.5.5, 29 ms Reply to request 0 from 10.5.5.5, 41 ms Reply to request 1 from 10.5.5.5, 10 ms Reply to request 1 from 10.5.5.5, 9 ms Reply to request 2 from 10.5.5.5, 21 ms

5.6 Simulation Results Inter-domain multicasting is quite challenging as compared to intra-domain. The problem arises when two domains are using different technologies without proper filtering. In such cases, RP overlapping can occur for client reachability. It is not only important to define multicast boundaries but also to secure certain servers from advertisement or bandwidth limitations. For connecting two domains we used MSDP and shared multicast source information. MSDP can work independently but in case of RPF failure MBGP is used to divert source information to another path along with MSDP. Furthermore MSDP can also work between indirectly connected neighbours. Sometime, ISP has no SLA to provide multicasting capability on the link. MBGP is the alternate method to dynamically route multicast traffic through different links.

33


6 Conclusion and future work Multicast based networks helped in improving network performance as compared to unicast based routing. In a multicast network, a single packet travels downstream and can serve multiple clients. This made traffic more efficient, increased performance and minimised load on servers. Multicasting is quite challenging and requires proper design consideration inside, as well as between organizations. With a good design it is easy to perform new enhancements in the network and troubleshoot problems. Auto deployment of RP is used to achieve load balancing and avoid tedious manual configuration. It also helps in preventing failure of RP due to heavy multicast load by implementing multiple RPs within a domain. In larger networks, automatic source announcement is one of the key requirements as it can reduce administrative overhead and has long term benefits. Any-cast assists in providing redundant and shortest paths for clients to reach the server. In the first part of this project, two domains were configured with Any-cast routing for shortest and redundant paths. It provides a degree of flexibility in case of one path being down and another taking charge as a backup. In the second part of the thesis, inter-domain multicast routing was configured. For good design, it is good practice to isolate domain for avoiding information leakage. Multicast security boundaries were implemented to solve the problem of information leakage and to enhance security of the multicast network. Worst-case scenario in inter-domain routing is the failure of RPF check or Service Level Agreement failure. If RPF failure occurs, it can be statically configured to re-route traffic. Static deployment can be helpful for smaller networks; in larger networks MBGP is desirable. This is because MBGP achieves the same goal as static multicast routing but dynamically. Multicast technology is not implemented on the internet yet. The draft for such technology exists and is known as MBone. MBone on the internet utilizes the concept of tunnelling traffic through interfaces but still lacks the feature of PIM based multicasting. Future work in this area can be extended to provide support for internet based multicasting. Moreover the study can further be used in application layer to identify the characteristics of real time traffic over this network.

35

Conclusion and suggestion for future works

7 Abbreviations BGMP: Border Gateway Multicast Protocol BGP: Border Gateway Protocol BSR: Bootstrap router CBT: Core Based Trees DCM: Distributed Core Multicast DVMRP; Distance Vector Multicast Routing Protocol DVMRPv3: Distance Vector Multicast Routing Protocol Version 3 DVMVPN: Dynamic Virtual Point Private Network HDVMRP: Hierarchical Distance Vector Multicast Routing Protocol HIP: Hierarchical Multicast Routing HPIM: Hierarchical Protocol Independent Multicast IETF: Internet Engineering Task Force IGP: Interior Gateway Protocol ISP: Internet Service Provider MAR: Multicast Address for Routing MASC: Multicast Address-Set Claim MBone: Multicast Backbone MIP: Multicast Internet Protocol MOSPF: Multicast Open Path Shortest First MPBGP: Multiprotocol Border Gateway Protocol MPLS LDP: Multiprotocol Label Switching Label Distribution Protocol MROUTE: Multicast Route MSDP: Multicast Source Discovery Protocol OCBT: Ordered Core Based Tree PIM: Protocol Independent Multicast PIM-DM: Protocol Independent Multicast-Dense Mode PIM-SM: Protocol Independent Multicast-Sparse Mode PPP: Point- to-Point Protocol PTMR: Policy Tree Multicast Routing QoS: Quality of Service QoSMIC: Quality of Service-Sensitive Multicast Routing Protocol RAMA: Route Address Multicast Architecture RP: Rendezvous Point RPF: Reverse Path Forwarding RTT: Round Trip Time SLA: Service Level Agreement

SPT: Shortest Path Tree SSM: Source Specific Multicast TTL: Time To Live VMA: Virtual Multicast Address WAN: Wide Area Network YAM: Yet-Another Multicast

37

Conclusion and suggestion for future works

8 References [1] D. Kim, D. Meyer, H. Kilmer, D. Farinacc, “Anycast Rendevous Point (RP) mechanism using Protocol”, RFC3446,January 2003. [2] N. Bhaskar, A .Gall, J. Lingard, S. Venaas, “Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)”,RFC 5059,January 2008. [3] B. Fenner, D. Meyer, “Multicast Source Discovery Protocol (MSDP)”, RFC 3618, October 2003. [4] T.Bates, Y.Rekhter, R.Chandra, D.Katz, “Multiprotocol Extensions for BGP-4”, RFC2858, June 2000. [5] Kevin C. Almeroth, “The Evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment”, University of California, February 200. [6] M. Ohmorit, K. Okamuraz, K. Arakitt, “Design of Scalable Interdomain IP Multicast Architecture”, Beppu City, Oita, August 2001. [7] S. Venaas, “Inter-domain Multicast Routing with IPv6”, University of Southampton, United Kingdom. 2005. [8] T. Bates, Y. Rekhter, R. Chandra, D. Katz, “Multiprotocol Extensions for BGP-4”, RFC2858, June 2000. [9] M. Ramalho “Intra- and Inter-domain Multicast routing protocols” Alcatel Corp. Res. Centre, Belgium, Vol. 2, no. 1, 2000. [10] B.Fenner, M.Handley, H.Holbrook, I.Kouvelas “Protocol Independent Multicast –Sparse Mode (PIM-SM): Protocol Specification (Revised)”, RFC4601, August 2006. [11] T.Bates, R.Chandra, D.Katz, Y.Rekhter “Multiprotocol Extensions for BGP-4”, RFC 2283, February 1998. [12] Antonio F. Gómez-Skarmeta, Angel L. Mateo Martínez, Pedro M. Ruiz Martínez, (2000) “GMPv3-based method for avoiding DoS attacks in Multicast-enabled networks-technical report.

39

9 Appendix

Appendix A hostname R1 boot-start-marker boot-end-marker no aaa new-model memory-size iomem 5 ip cef interface Loopback1 ip address 10.1.1.1 255.255.255.0 interface FastEthernet0/0 ip address 192.168.12.1 255.255.255.0 duplex auto speed auto interface FastEthernet0/1 ip address 192.168.13.1 255.255.255.0 duplex auto speed auto interface FastEthernet1/0 no ip address shutdown duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 ! end

40

hostname R2 interface Loopback1 ip address 10.2.2.2 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.12.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.24.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet1/0 no ip address shutdown duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 login ! end hostname R3 ! interface Loopback1 ip address 10.3.3.3 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.34.3 255.255.255.0 duplex auto speed auto !

41

interface FastEthernet0/1 ip address 192.168.13.3 255.255.255.0 duplex auto speed auto ! interface FastEthernet1/0 no ip address shutdown duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 login ! end hostname R4 ! interface Loopback1 ip address 10.4.4.4 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.34.4 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.24.4 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary

42

! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 login ! end hostname R5 ! interface Loopback1 ip address 10.5.5.5 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.56.5 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.57.5 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 ! end hostname R6 ! interface Loopback1 ip address 10.6.6.6 255.255.255.0 !

43

interface FastEthernet0/0 ip address 192.168.56.6 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.68.6 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 ! end hostname R7 ! interface Loopback1 ip address 10.7.7.7 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.78.7 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.57.7 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0

44

exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 ! End hostname R8 ! interface Loopback1 ip address 10.8.8.8 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.78.8 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.68.8 255.255.255.0 duplex auto speed auto ! router eigrp 1 network 10.0.0.0 network 192.168.0.0 0.0.255.255 no auto-summary ! line con 0 exec-timeout 0 0 logging synchronous line aux 0 line vty 0 4 ! end

Appendix B tclsh foreach address{ ip addresses to ping }{ping $address}

45

Appendix C Router 1, 2, 3, 4, 5, 6, 7, 8 config> ip multi-cast routing Router 1 config> interface loopback 1 config-if> ip pim spare-dense-mode config-if>ip igmp join-group 224.10.10.10 config>interface fastethernet0/1 config-if>ip pim spare-dense-mode Router 2 config> interface loopback 1 config-if> ip pim spare-dense-mode config>interface fastethernet0/1 config-if>ip pim spare-dense-mode config> ip pim send-rp-discovery Loopback1 scope 3 config> ip pim rp-candidate Loopback1 Router 3 config> interface loopback 1 config-if> ip pim spare-dense-mode config-if>ip igmp join-group 224.10.10.11 config>interface fastethernet0/1 config-if>ip pim spare-dense-mode config-if>interface fastethernet0/1 config-if>ip pim spare-dense-mode Router 4 config> interface loopback 1 config-if> ip pim spare-dense-mode config-if>interface fastethernet0/1 config-if>ip pim spare-dense-mode config-if>interface fastethernet0/0 config-if>ip pim spare-dense-mode config> ip pim send-rp-discovery Loopback1 scope 3 config> ip pim rp-candidate Loopback1

Appendix D Router 1 config> ip mroute 0.0.0.0 0.0.0.0 192.168.13.2

46

Appendix E Router 5 config> interface loopback 1 config-if> ip pim spare-mode config-if> ip igmp join-group 224.20.20.10 config-if>interface fastethernet0/1 config-if>ip pim spare-mode config-if>interface fastethernet0/0 config-if>ip pim spare-mode Router 6 config> interface loopback 1 config-if> ip pim spare-mode config-if>interface fastethernet0/1 config-if>ip pim spare-mode config-if>interface fastethernet0/0 config-if>ip pim spare-mode config>ip pim bsr-candidate Loopback1 0 config>ip pim rp-candidate Loopback1 Router 7 config> interface loopback 1 config-if> ip pim spare-mode config-if>interface fastethernet0/1 config-if>ip pim spare-mode config-if>interface fastethernet0/0 config-if>ip pim spare-mode config>ip pim bsr-candidate Loopback1 0 config>ip pim rp-candidate Loopback1 Router 8 config> interface loopback 1 config-if> ip pim spare-mode config-if> ip igmp join-group 224.20.20.11 config-if>interface fastethernet0/1 config-if>ip pim spare-mode config-if>interface fastethernet0/0 config-if>ip pim spare-mode

47

Appendix F Router 2 and 3 config> interface loopback 25 config-if> ip address 192.168.255.255 255.255.255.255

Appendix G Router 2 and 3 config> interface loopback 25 config-if> ip pim sparse-dense mode config> ip pim send-rp-discovery loopback 25 scope 10 config> ip pim rp-candidate loopback 25

Appendix H Router 5, 4, 6, 8 config> interface serial 0/0 config-if> ip pim spare-mode

Appendix I Router 3, 4 config>access-list 1 deny 224.0.1.39 config>access-list 1 deny 224.0.1.40 config>access-list 1 permit any config>interface serial 0/0 config-if>ip multicast boundry 1 Router 6, 8 config>interface serial 0/0 config-if>ip pim bsr-boundry

Appendix J Router 3 ip msdp peer 10.5.5.5 connect-source loopback 1 Router 4 ip msdp peer 10.8.8.8 connect-source loopback 1 Router 5 ip msdp peer 10.3.3.3 connect-source loopback 1

48

Router 8 ip msdp peer 10.4.4.4 connect-source loopback 1

Appendix K Router 3, 4, 6, 8 config>access-list 2 deny 224.10.10.11 config>access-list 2 permit any config>interface serial 0/0 config-if>ip access-group 2 out

Appendix L Router 3, 4 access-list 10 permit 224.10.10.11 interface serial 0/0 ip multicast rate-limit out group-list 10 128

Appendix M Router 1 router bgp 123 address-family ipv4 unicast neighbor 10.2.2.2 remote-as 123 neighbor 10.2.2.2 update-source loopback 1 neighbor 10.3.3.3 remote-as 123 neighbor 10.3.3.3 update-source loopback 1 no neighbor 10.2.2.2 activate no neighbor 10.3.3.3 activate address-family ipv4 multicast network 10.1.1.1 mask 255.255.255.0 neighbor 10.2.2.2 activate neighbor 10.2.2.2 next-hop-self neighbor 10.3.3.3 activate neighbor 10.3.3.3 next-hop-self Router 2 router bgp 123 address-family ipv4 unicast neighbor 10.1.1.1 remote-as 123 neighbor 10.1.1.1 update-source loopback 1 neighbor 10.4.4.4 remote-as 4 neighbor 10.4.4.4 update-source loopback 1 neighbor 10.4.4.4 ebgp-multihop

49

no neighbor 10.1.1.1 activate no neighbor 10.4.4.4 activate address-family ipv4 multicast neighbor 10.1.1.1 activate neighbor 10.1.1.1 next-hop-self neighbor 10.4.4.4 activate neighbor 10.4.4.4 next-hop-self Router 3 router bgp 123 address-family ipv4 unicast neighbor 10.1.1.1 remote-as 123 neighbor 10.1.1.1 update-source loopback 1 neighbor 10.4.4.4 remote-as 4 neighbor 10.4.4.4 update-source loopback 1 neighbor 10.4.4.4 ebgp-multihop no neighbor 10.1.1.1 activate no neighbor 10.4.4.4 activate address-family ipv4 multicast neighbor 10.1.1.1 activate neighbor 10.1.1.1 next-hop-self neighbor 10.4.4.4 activate neighbor 10.4.4.4 next-hop-self Router 4 router bgp 4 address-family ipv4 unicast neighbor 10.3.3.3 remote-as 123 neighbor 10.3.3.3 update-source loopback 1 neighbor 10.3.3.3 ebgp-multihop neighbor 10.2.2.2 remote-as 4 neighbor 10.2.2.2 update-source loopback 1 neighbor 10.2.2.2 ebgp-multihop neighbor 10.8.8.8 remote-as 8 neighbor 10.8.8.8 update-source loopback 1 neighbor 10.8.8.8 ebgp-multihop no neighbor 10.1.1.1 activate no neighbor 10.4.4.4 activate no neighbor 10.8.8.8 activate address-family ipv4 multicast network 10.4.4.0 mask 255.255.255.0 neighbor 10.1.1.1 activate neighbor 10.1.1.1 next-hop-self

50

neighbor 10.4.4.4 activate neighbor 10.4.4.4 next-hop-self neighbor 10.8.8.8 activate neighbor 10.8.8.8 next-hop-self Router 8 router bgp 8 address-family ipv4 unicast neighbor 10.4.4.4 remote-as 4 neighbor 10.4.4.4 update-source loopback 1 neighbor 10.4.4.4 ebgp-multihop neighbor 10.6.6.6 remote-as 567 neighbor 10.6.6.6 update-source loopback 1 neighbor 10.6.6.6 ebgp-multihop neighbor 10.7.7.7 remote-as 567 neighbor 10.7.7.7 update-source loopback 1 neighbor 10.7.7.7 ebgp-multihop no neighbor 10.6.6.6 activate no neighbor 10.4.4.4 activate no neighbor 10.7.7.7 activate address-family ipv4 multicast network 10.8.8.0 mask 255.255.255.0 neighbor 10.4.4.4 activate neighbor 10.4.4.4 next-hop-self neighbor 10.6.6.6 activate neighbor 10.6.6.6 next-hop-self neighbor 10.7.7.7 activate neighbor 10.7.7.7 next-hop-self Router 5 router bgp 567 address-family ipv4 unicast neighbor 10.6.6.6 remote-as 567 neighbor 10.6.6.6 update-source loopback 1 neighbor 10.6.6.6 remote-as 567 neighbor 10.7.7.7 update-source loopback 1 no neighbor 10.7.7.7 activate no neighbor 10.7.7.7 activate address-family ipv4 multicast network 10.5.5.0 mask 255.255.255.0 neighbor 10.5.5.5 activate neighbor 10.5.5.5 next-hop-self neighbor 10.6.6.6 activate neighbor 10.6.6.6 next-hop-self

51

Router 6 router bgp 567 address-family ipv4 unicast neighbor 10.5.5.5 remote-as 567 neighbor 10.5.5.5 update-source loopback 1 neighbor 10.8.8.8 remote-as 8 neighbor 10.8.8.8 update-source loopback 1 neighbor 10.8.8.8 ebgp-multihop no neighbor 10.5.5.5 activate no neighbor 10.8.8.8 activate address-family ipv4 multicast neighbor 10.5.5.5 activate neighbor 10.5.5.5 next-hop-self neighbor 10.8.8.8 activate neighbor 10.8.8.8 next-hop-self Router 7 router bgp 567 address-family ipv4 unicast neighbor 10.5.5.5 remote-as 567 neighbor 10.5.5.5 update-source loopback 1 neighbor 10.8.8.8 remote-as 8 neighbor 10.8.8.8 update-source loopback 1 neighbor 10.8.8.8 ebgp-multihop no neighbor 10.5.5.5 activate no neighbor 10.8.8.8 activate address-family ipv4 multicast neighbor 10.5.5.5 activate neighbor 10.5.5.5 next-hop-self neighbor 10.8.8.8 activate neighbor 10.8.8.8 next-hop-self

Multicasting in Intra and Inter Domain...

Documents

Transcript of Multicasting in Intra and Inter Domain...