1. The Cisco architecture maintains separate tables for each protocol which contributes its best router for a given prefix to the routing table 2.

Transcription

1 1

2 2

3 3

4 4

5 1. The Cisco architecture maintains separate tables for each protocol which contributes its best router for a given prefix to the routing table 2. If multiple protocols have learned a particular prefix, the routing table uses the concept of Administrative Distance to select the winning protocol for that prefix 3. The Administrative Distance associated with any given prefix can be changed. For instance, a backup Static prefix routed over a Dialer interface would have a maximum value of 255 assigned as the Administrative Distance to prevent unnecessary call charges. 4. Routes may be redistributed between protocols which is an entirely separate action from the routing table 5. Redistribution should not be used carelessly and it presents a challenge on how to represent one metric (e.g. hop count from RIP) as another (e.g. EIGRP path cost) 6. Note that the diagram does not show redistribution into the Static protocol for obvious reasons! 7. An IGP such as RIP maintains only the best route to a destination. If that path becomes unavailable, then RIP must wait for the next periodic update containing an alternative path. 8. BGP is a quiet protocol; a prefix is announced only once unless there is a change. If the best path is lost, how can BGP discover the second-best one? The BGP table maintains all possible routes to every destination with the best one installed into the routing table. 5

6 1. In the Juniper model, every (Unicast IPv4) prefix is copied to the inet.0 table. There are separate tables for IPv6 and multicast routing 2. Each prefix has the full set of properties, although some may not have an associated value because the originating protocol does not support that particular property. 3. A BGP learned prefix would have values for the Metric 1, Metric 2, Next Hop, AS-Path and Community properties 4. An OSPF learned prefix would have the Metric 1 property. If that prefix is distributed into BGP then the Metric 1 property (in BGP parlance this would be the Multi Exit Discriminator or MED) would remain. 5. Routes that are transferred between routing protocols do not therefore lose information as happens with in the Cisco model 6. The Juniper routers are traditionally favoured by the Service Provider community in part because of the power and flexibility this model provides. 6

7 1. Use the diagram in Slide 9 to illustrate the contrasting behavior between route lookups on destinations IP addresses learned from an IGP and those learned from BGP 2. From Router D, taking account of Metrics associated with the circuits, the Next-Hop IP address to B.0 will be A.4 3. From Router D, the Next-Hop IP address to any prefix advertised by the external peer (Router K) will be B.0 4. A second route lookup on the BGP Next-Hop of B.0 is then required. This yields the required egress interface identifier. 7

8 8

9 1. Description of Cisco Procedure 1. The prefix /12 is advertised to the Cisco router and is parsed by the inbound routing policy. 2. Providing the prefix is accepted then it is passed to the BGP Table 3. All similar prefixes are grouped and then operated upon by the BGP path selection process 4. The best prefix is transferred to the Routing table and is also advertised to all peers except the originator. 5. Advertised prefixes such as the illustrated /16 are first parsed by the outbound routing policy associated with each peer. 2. Description of Juniper Procedure 1. The advertised prefix /24 is first parsed by the inbound routing policy 2. Assuming the prefix is accepted, it is transferred to the inet.0 routing table 3. The BGP path selection process acts on each BGP-learned route that resides in inet.0 4. The best prefix is advertised to all peers except the originator 5. The advertised prefixes must first be parsed though the outbound routing policy 9

10 10

11 1. Routing loops are avoided by using AS numbers 2. Path selection process uses AS path length 3. Routing policy can match against contents of AS path often using regular expressions for added power. 11

12 1. The four provider (PE) routers are connected by means of four circuits (Sold lines labeled Circuit 1 through Circuit 4 ). There are two customer (CE) routers also shown. 2. An IS-IS adjacency (dotted lines) is established between each pair of neighbouring routers; these adjacencies are congruent with the physical circuits. 3. Each router is assigned a /32 loopback address that is not associated with any particular physical interface. The loopback addresses and the /30 link addresses are routed by IS-IS. 4. If a circuit fails then 1. The connected router interfaces will go down and the /30 link addresses will become unreachable. 2. The routers that are connected over the failed circuit will remain reachable via their loopback addresses and the IS-IS routing will rapidly establish an alternative path around the failed circuit. 5. A full mesh of ibgp peerings (represented as dashed lines) is established using the loopback addresses of the routers. 6. Suppose Circuit 4 fails: 1. IP addresses A.4 and D.4 become unreachable 2. Both routers A and D remain reachable from any other of the three routers 3. The ibgp peering between A and D remains Established 4. The prefixes received over the ebgp peering (shown as a dashed/dotted line) between routers B and E continue to be passed to routers A and D 5. Our customers experience no loss of service but of course the remaining three BB circuits may become congested. 7. In contrast, the ebgp peerings between [A and J] and [B and E] is best configured using the interface IP addresses on both routers. This is recommended so that a failure of the underlying circuit causes the routers to immediately declare the peering down. Using loopback addresses would result in the routers waiting until three BGP keepalive messages had expired before declaring the peering down. During this time (90 seconds by default) traffic is being black-holed. 8. Two external peers (rather than just one) are purposely depicted to demonstrate why BGP is preferable to using a static route on a single PE router which is then redistributed into the IGP. Changes made by CE Router E (by adding or withdrawing prefixes) are automatically 12

13 13

14 1. Because IGP s have no flow control mechanisms, it is vital that they are used to transport just the minimal amount of internal infrastructure prefixes. 2. Under suitably quiescent network conditions, an IGP may appear to operate effectively even after large numbers of customer prefixes have been redistributed into the protocol. However at times of network stress, such as a flapping backbone circuit, when persistent route re-computation is occurring, an IGP that is carrying excessive amounts of routing information will start to churn and the effects of the localized flapping circuit will be amplified across the entire network. 3. BGP benefits from the flow control inherent in TCP. A BGP speaker that is being overwhelmed with large Update messages from a peer is able to stem the flow by delaying sending TCP Ack s. 4. The peer router suppresses any further routing updates until the receiver has processed those that have already been sent. 14

15 15

16 16

17 17

18 18

19 19

20 20

21 21

22 1. The BGP Common Header specifies just the Message Length (2 Bytes) and the Type (1 Bytes) using the codes in this table. 2. The Open message is used by a pair of peer routers to negotiate a set of capabilities that both peers can support. 3. The Update message carries a set of withdrawn prefixes (if there are any) along with an NLRI which represents a group of advertised prefixes that share a set of common attributes. 4. The Notification message is sent when: 1. A router experiences an error that warrants termination of the peering session, 2. There is a problematic piece of information contained within an Open message during the establishment phase of a BGP peering. This could include the far-end router requesting an unsupported capability. 5. The Route Refresh message is sent to a BGP peer to request the peer readvertises the full NLRI for the address family specified in the Route Refresh message 6. The Keepalive message consists solely of the BGP Common Header (19 bytes long) and is used to prevent expiration of the BGP Hold timer. 22

23 1. For purposes of efficiency, the BGP update message groups together all prefixes that share a common set of attributes. That set of prefixes is known as Network Layer Reachability Information or NLRI 2. Each NLRI requires a separate BGP Update message. 3. The BGP header consists of a 16-byte sequence number, a 2-byte Length field and a 1-byte Type field which specifies the BGP Message (Open, Notification etc.) that follows. 23

24 24

25 1. Well-known mandatory attributes must be supported by all BGP implementations and must be included in all updates 2. Well-known discretionary attributes must be supported by all BGP implementations but need not be included in all updates 3. Optional transitive attributes should be accepted and passed onto downstream peers but need not be supported by all BGP implementations 4. Optional non-transitive attributes that are not understood should be ignored and not passed onto downstream peers 25

26 1. Does this imply BGP operates like RIP where we select the best route based on an AS (aka hop) count? 2. No; there are many more contributing variables to the path selection outcome because the best path can mean many different things (not just AS count) depending on the context. 26

27 1. The AS_PATH length does not necessarily reflect the shortest path 2. There may be many reasons, technical, financial and political why AS100 would prefer a particular route to AS400 over another one 3. BGP gives network engineers the freedom to tweak routing to achieve almost any desired outcome. 27

28 1. The AS64513 router is configured to advertise just the aggregate prefix using: aggregate-address as-set summary-only 2. Note how AS64512 and AS64513 only advertise their home /23 prefix to AS64515 because they detect their own AS in the AS_SET associated with the aggregate that was advertised back to them by AS

29 1. The AS64513 router is configured to advertise just the aggregate prefix using: aggregate-address summary-only 2. Note how the omission of the AS_SET in the aggregate prefix causes the two originating routers to advertise their home prefixes along with the summary route which they received from the aggregator 29

30 1. This example substitutes symbols for IP addresses to aid legibility 2. Each /30 IP address is written as <router name>.<circuit number> 3. The loopback addresses follow the same convention, substituting zero for the circuit number. 4. Note how the Next Hop address behaves as the prefix is passed across the ibgp peering between routers B and C 5. Router C receives the prefix /24 (which resides in AS100) with a third-party next hop address which may be unreachable. 6. The advantage of the Next Hop Self process is that we do not have to route alien link addresses using our IGRP 30

31 1. Most texts falsely state that ebgp always changes the NEXT_HOP attribute. 2. In the diagram, Router B will advertise Router A as the next-hop for the /24 prefix to Router C rather than itself 3. This happens because Router B detects that the NEXT_HOP is in the same subnet as the peering address for Router C 4. The consequence is that traffic between customers of A and C is switched over the LAN and is not routed via B 5. The depicted arrangement is exactly how a public peering switch operates with each connected ISP assigned an IP address from the exchange operator. The connected ISPs must therefore filter outbound prefixes so that only their own customers are advertised to their peers. 6. If outbound prefixes are not filtered then a mass, uncontrolled transiting arrangement will exist. 31

32 1. The third-party next hop phenomenon can cause unexpected failures when it is combined with an NBMA network. 2. As depicted, ISP B has purchased a pair of PVCs from some frame relay provider to sustain peerings with A and C 3. Note that the DLCI numbers on either side of a PVC do not have to (and likely are not) the same. 4. On each router, the near-end DLCI can be statically mapped to the far-end IP address of the connected router. If these mappings do not exist, the Inverse ARP can provide the resolution. 5. Prefixes advertised by A are then advertised in turn by B to C with an unmodified NEXT_HOP 6. Router C accepts the incoming prefix but is unable to forward any traffic as there is no DLCI connecting it to Router A 7. It is possible that some alternative but less favorable path exists between Routers A and C; this is now suppressed by the BGP route that has been installed in the routing table and so connectivity is broken. 32

33 1. Local preference is non-transitive (i.e., it is local to an AS) and should be passed onto ibgp peers only 2. The path with the highest LOCAL_PREF wins 3. Used to influence the path taken by outbound traffic. 33

34 1. The MED is used to convey the relative preference of multiple entry points; it determines the best path for inbound traffic 2. The MED attribute associated with two similar prefixes will usually only be considered if the prefixes have been received from the same AS 3. As MED implies a distance the path with the lowest value is preferred. 4. In the example network, Routers A and B advertise /24 to Router C. Traffic as indicated by the Green arrow flows from C towards B because of the lower metric associated with the prefix that C receives from B. 34

35 35

36 36

37 1. The Yellow boxes represent nine routers comprising one AS 2. The pink box represents a second AS with a single external peering to the Yellow AS 3. Note how the prefix received over the ebgp peering is distributed throughout the Yellow AS 4. This arrangement is required because prefixes cannot be passed from one ibgp peer to another 5. Route reflection is the single case where a BGP speaker is permitted to propagate prefixes learned from an internal peer. 37

38 38

39 1. Use this slide to figure how BGP does not change in response to backbone circuit failures while ISIS does reflect the state of the physical backbone connectivity. 2. Consider traffic flows from LEARN in Texas to UEN in Utah. 3. UEN advertises their prefixes to Internet2 at the core router in Salt Lake City 4. LEARN receives the UEN prefixes over their peering with Internet2 in Houston. 5. From the perspective of LEARN, the NEXT_HOP will be the IP address of the Internet2 router interface facing LEARN. 6. From the perspective of the Internet2 router in Houston, the NEXT_HOP for the UEN prefixes will be the loopback address of the core router in Salt Lake City. This routing information was learned from the ibgp peering between the two core routers. 7. The Houston router performs a recursive lookup of the BGP NEXT_HOP address and finds a next hop in the form of an interface that was installed in the routing table by ISIS. There is no physical connection between the routers in Salt Lake and Houston but ISIS figures the shortest path is via Kansas City. 8. Now imagine the circuit between Houston and Kansas city fails. This causes the ISIS adjacency between the two cities to fail but all ibgp peerings remain Established including the one between Houston and Salt Lake City. 9. All that changes is the route to the BGP NEXT_HOP. The Houston router no longer sends LEARN traffic for UEN via the interface facing KC but instead sends it via the interface facing Los Angeles. 39

40 40

41 1. This slide illustrates the default self-steering behaviour of BGP for a customer such as NYSERnet who are multihomed to a provider such as Internet2 and who do not send MEDs. 2. The NYSERnet routers based in Buffalo and New York City are shown in blue; a 10G circuit on the Internet2 optical platform connects Buffalo to the Internet2 router in Chicago 3. The two Internet2 routers (CHIC and NEWY) supporting the ebgp peerings with NYSERnet are shown with their ibgp peerings to each of the other Internet2 core routers. 4. The number attached to each router is the IS-IS metric between that router and the internal peer (either CHIC or NEWY) that is directly connected to NYSERNet. This metric is the sum of all the metrics associated with each IS-IS adjacency between the two routers. 5. A second Internet2 customer (e.g. LEARN) connected in Houston has traffic to be sent to NYSERnet. This traffic could go over the path represented by the ibgp peerings with CHIC (distance 1507) or NEWY (distance 2363). 6. Although these numbers are derived from the IGRP metric, they are copied into the Metric 2 property of the ibgp-learned prefix at Houston 7. Clearly, the ibgp-learned path to Chicago is shortest and is thus selected. 8. Now a recursive lookup is done on the NEXT_HOP address supplied by BGP. This is the loopback address of the Chicago router. 9. The IS-IS protocol at Houston dictates which interface to forward traffic from in order to start the journey to Chicago 10. This process is repeated until we reach the Internet2 router at Chicago and the traffic from LEARN is forwarded out the interface connected to the NYSERNet router in Buffalo. 41

42 1. NREN advertises prefixes to Internet2 over two separate external peerings that exist on the I2 routers in Seattle and Salt Lake. 2. Those two Internet2 routers each readvertise the prefixes via their internal peerings with every other Internet2 router, including the ibgp peering between themselves. 3. Consider traffic from Indiana University destined for Nasa Ames laboratory. The traffic from IU enters Internet2 at Chicago. The Chicago router prefers the ibgp peering with Salt Lake City over that with Seattle because the ISIS metric indicates that is the shorter path. 4. Once the traffic arrives at Salt Lake, the external peering is preferred over the internal one with Seattle. 5. This causes traffic to flow over a congested 1G circuit within the NGIX-W Layer-II cloud (see slide 35) 6. The PacWave Layer-II cloud is fully 10G connected and is the better path 7. If Internet2 applies a higher LOCAL_PREF to the NREN prefixes received in Seattle then the IU traffic will no longer prefer the external peering at Salt Lake and traffic will no longer be forced over the low-bandwidth Layer-II link. 42

43 43

44 1. This diagram expands the Layer-II connectivity between the NREN router in Nasa Ames and the Internet2 router in Salt Lake City. 2. Note the Gigabit circuit that connects the Internet2 optical node in Sunnyvale to ESnet who extend the VLAN from the Level3 building in Sunnyvale where Internet2 are located to Nasa Ames where the NGIX-W switch resides. 3. The Layer-III connectivity is unaware of this Layer-II architecture. All the routing sees is an external peering that is tied to a subinterface on the Salt Lake City router. 4. Forcing multiple Gigabits of traffic over this Layer-II link caused packet loss and poor TCP performance between the end stations in Indiana University and Nasa Ames. 44

45 45

46 1. Purdue University attach a high LOCAL_PREF to all prefixes received over the R&E peering with the Indiana Gigapop. 2. Consequently any R&E prefixes advertised over the commodity peering will not attract traffic unless the R&E peering goes down 3. The Gigapop advertises its entire address space over both peerings 4. The AKAM network is unreachable from Purdue! 46

47 1. This slide illustrates the default routing between two networks with multiple peering points. The example shows Internet2 peerings with ESnet in the Eastern USA. 2. The Green routers are ESnet and the blue ones belong to Internet2. The networks peer with one another in three Exchange Point locations; MANLAN, NGIX-E and Starlight as well as one peering over a direct router-to-router connection at 600 West Chicago Avenue 3. Consider traffic going from Fermi Lab (an ESnet customer) and University of Pennsylvania (an Internet2 connector). 4. The traffic first enters ESnet on their router located at Starlight. 5. The external peering with Internet2 at Starlight is then the preferred path causing traffic destined for the Internet2 connector to enter the Internet2 network at the earliest possible opportunity; a hot potato. 6. From their traffic is switched over the IBGP peering between the Internet2 routers in Chicago and New York City. 47

48 1. The return traffic from University of Pennsylvania to Fermi lab follows the opposite hot potato path. 2. This time, Internet2 hands the traffic off to ESnet at the earliest opportunity which is represented by the external peering at MANLAN 3. The traffic then remains on the ESnet backbone until it reaches their router at Starlight where it exits the interface facing Fermi lab. 48

49 1. Here is a side-by-side comparison of the two previous slides (39 and 40). 2. The default behaviour results in a routing asymmetry 3. This is just a function of the BGP path selection favouring external over internal peers on the entry-point router. 4. Nevertheless, assuming roughly equal amounts of traffic in both directions, this is a fair result as each carrier burns bandwidth on their backbone circuits. 49

50 1. Internet2 attaches a MED to each prefix advertised to ESNet 2. The MED is configured to be equal to the Internet2 IGP metric 3. The direct connection at Chicago 600 West is preferred over the peering via Starlight by incrementing the MED associated with each prefix advertised via Starlight 4. This causes traffic from an ESNet customer sent to an Internet2 customer to remain on the ESNet backbone for as long as possible 5. Traffic leaves ESnet at the peering point with Internet2 that is closest to Internet2 s own peering with their customer (e.g. MAGPI) 50

51 1. Indiana wants traffic inbound to /16 from Utah and Front Range to always come from Internet2 unless the circuit is down. 2. Sending MED to Internet2 and NLR won t work as they do not peer 3. Even if NLR and Internet2 did peer, Indiana could not use MED as the AS_PATH would be dissimilar on the prefix received directly from Indiana and from the other NREN meaning MED would not be compared 4. Perhaps Indiana could pad the AS_PATH on the announcement to NLR? 5. Note that Indiana Gigapop has to pad the AS_PATH on behalf of IU otherwise BGP path selection at the Gigapop would cause just the unpadded prefix to be announced to both Internet2 and NLR 51

52 1. Padding the AS_PATH can be defeated if FRGP associate a high LOCAL_PREF to all prefixes received from NLR 2. If Indiana selectively de-aggregates the /16 and leaks the longer prefixes to Internet2 then traffic can be forced via the Internet2 path 52

53 53

54 54

55 Conversion from old to new format is best done by first expressing in hexadecimal ( = 0x2D110104) and then splitting into the high (0x2D11) and low (0x104) bytes followed by conversion of each back to Base

56 1. This slide illustrates one possible use for the NO-EXPORT community in which AS100 is a customer of AS AS100 wishes to balance traffic entering their network across the two backbone circuits shown in magenta. 3. This is achieved by leaking alternative /24 prefixes across the backbone circuits along with the single aggregate 4. When both circuits are operating, traffic destined to stations on the /24 subnet takes the high road while traffic for stations on the /24 subnet takes the low. 5. Suppose the lower circuit fails. That does not mean the /24 subnet is cut off because we are still advertising the aggregate prefix over the remaining good circuit. But when both circuits are operating, the more specific prefix is preferred over the aggregate giving an approximation to load balancing across both. 6. However, AS200 does not want to leak hundreds of small prefixes to the Internet. That is bad practice as it needlessly fills routing tables with hundreds of entries when a single aggregate would have the same effect. 7. This is prevented by AS100 attached the NO-EXPORT community to the /24 prefixes but not to the aggregate. 8. The NO_EXPORT community is numerically represented as 65535:

57 1. The University of Memphis connects to Internet2 and they advertise their customers prefixes to Internet2 as well as their own which is /16 2. UMemphis wants all of their customers prefixes advertised into the Internet2 R&E routing table but not all customers should receive the Internet2 commodity service. 3. UMemphis could maintain a separate list of all the customer prefixes that should receive I2 commodity service and then filter announcements to Internet2 through that list. This solution is not the best because they would have to maintain two parallel prefix lists (one inbound on the peering with the customer and this new outbound list on the peering with Internet2. 4. The better alternative is to tag prefixes received from a customer entitled to the commodity service and then to use the tag on the outbound side of the peering with Internet2. 5. This example illustrates a general principle of tagging all prefixes received inbound on a specific peering so that they can be treated as a set during outbound advertisement. 6. Another example of using communities this way on Internet2 is to prevent transiting prefixes from one commodity peer to another. Outbound routing policy is attached to each peer limiting advertised prefixes to those tagged as Internet2 Connectors. Prefixes learned from other peers do not carry this tag and so are not passed onto other commodity peers. 57

58 1. A sophisticated use of communities allows a customer to automatically instruct their ISP to blackhole all traffic sent to an individual IP address or a range of addresses. This is especially useful if the customer s web servers are the victim of a DDOS attack. It might be better to block all traffic (legitimate and DOS) to a targeted server rather than the entire Internet connection suffering from severe congestion due to the DDOS attack on one IP address. 2. Routing traffic to Null is a better way to block traffic than Access Control Lists because routers are optimized for packet forwarding, not filtering. This is especially the case for a large ISP core router which should not be burdened with secondary tasks. 3. This recipe does not require any manual intervention from the ISP. 58

59 1. The ISP receives a prefix tagged with the black-hole me community. 2. Providing the prefix is longer than a /24 (this prevents customers black-holing their entire network) then any traffic will be discarded and not forwarded to the customer. 3. The customer only need to create a static route with the black-hole tag attached; the remaining policy can be configured ahead of time. 59

60 1. This example shows how to build the route-map required to act on the black hole community. Other clauses would likely be added to this route-map which would be applied inbound to each customer peering. 2. A Policy List contains only match clauses and acts like a macro in which all the match statements are evaluated. 3. The NO-EXPORT community is set on any black-hole prefix to prevent it from being passed onto peers. 60

61 1. The policy in the lower box would exist on the router at all times 2. Adding a static route as shown in the upper box is all that is required to tickle the ISP 3. At Indiana University we integrate this with the Snort intrusion detection system. The static routes (usually to a /32 host) are added to the border routers automatically using JunOS scripting. 61

62 62

63 63

64 64

65 1. Multiprotocol capabilities have been bolted onto BGP by defining two new attributes: 1. MP_REACH_NLRI 2. MP_UNREACH_NLRI 2. The Attribute Type field is set to 14 or 15 respectively for the above two new attributes. 3. The NLRI for any protocol other than IPv4 is carried within the Value portion of these attributes. The NLRI field within the BGP message only carries unicast IPv4 prefixes. This ensures full backwards compatibility for BGP speakers that do not support the Multiprotocol capability. 4. It is important to appreciate that the next-hop information for any protocol other than unicast IPv4 is carried within the MP_REACH_NLRI attribute. The NEXT_HOP path attribute is limited to an IPv4 address. 5. In principle, a pair of MBGP speakers could cease using the standard NLRI and Withdrawn Routes fields and instead pass unicast IPv4 information within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes with AFI = 1 and SAFI = 1 but in practice this is not done. 65

66 1. As depicted, the unicast and multicast paths cannot be congruent because AS300 is not a multicast-enabled domain. In other words, PIM-SM is not running on router interfaces within AS An AS might want to keep multicast flows away from particular circuits. 3. An AS might want to prevent hosts on certain prefixes from sending multicast traffic. This is readily done by not advertising the prefix within the IPv4 multicast address family. 66

67 1. This slide uses the simpler form of multicast known as Source Specific Multicast (SSM) in which both the group and source are known to the receiver. A full discussion of multicast would include Any Source Multicast (ASM) in which the receiver simply states a desire to receive all traffic sent to a given group. Building the tree for ASM involves considering the use of Rendezvous Points (RP) and is outside the scope of a BGP tutorial. 2. The multicast forwarding state is built (and torn down) using Protocol Independent Multicast-Sparse Mode (PIM-SM). 3. The Designated Router (DR) for the Receiver (Router E) receives an IGMP membership report. Router E adds that interface to its Outgoing Interface List (OIL) for the particular combination of Source and Group (S,G). 4. As the Source (S) is known, Router E performs a Reverse Path Forwarding (RPF) check on the IP address of the Source; this is just a regular IP address, not a Class- D one. 5. The RPF check tells router E which of its interfaces is closest to the Source. Router E then sends a PIM-SM (S,G) Join message out of that interface. 6. Router C adds the interface on which the (S,G) Join is received to its OIL for the (S,G) combination. Then Router C performs an RPF check on the Source IP address and sends a new PIM-SM (S,G) Join out of that interface. 7. Router D adds the interface on which the (S,G) Join was received to its OIL for the (S,G) and then traffic simply flows naturally from the Source to our Receiver 8. The process is significantly more complex for ASM in which (*,G) Joins are dispatched. 9. Note that multicast routing is concerned with the traffic source, unlike unicast routing which is concerned with the destination. 67

68 68