Case Study of mVPN Operation in SuperCom
Now that the various components and procedures of mVPN have been covered, it is useful to consolidate this information into a case study of mVPN operation in the SuperCom network. Figure 7-16 shows the SuperCom network topology to be used for the case study.
)
Figure
7-16 SuperCom mVPN Network
SuperCom is supporting two mVPN customers: EuroBank and FastFoods. Each of these customers is participating in a separate multicast domain via the PE routers at San Jose, Washington, and Paris.
EuroBank has three sites located at San Francisco, Washington, and Paris. One active source is connected to the Paris CE router that provides a multicast stream to an interested receiver at the Washington CE router. Even though the San Francisco CE router does not have receivers, the mVRF in the San Jose PE router still connects to the EuroBank multicast domain (in the event that a receiver does become active at the CE router). The EuroBank network has been configured with PIM SM mode, and the RP is located at the Paris CE router, denoted in Figure 7-16 by RPE. RP information is statically distributed. The SuperCom network has been configured so that the Default-MDT EuroBank uses between all PE routers is 239.192.10.2 (shown previously in Figure 7-7), and the EuroBank Data-MDTs are created by using addresses from the range 239.192.20.32–239.192.20.47. FastFoods has two sites located at San Francisco and Lyon. One active source is connected to the San Francisco CE router and provides a multicast stream to an interested receiver at the Lyon CE router. The FastFoods network has been configured to operate in SSM mode; therefore, the Lyon CE router has issued a source-specific C-join to the server at FastFoods San Francisco. The SuperCom network has been configured so that the Default-MDT FastFoods uses between all PE routers is 239.192.10.1 (shown previously in Figure 7-7). The Data-MDTs are created by using addresses from the range 239.192.20.16–239.192.20.31.
){kind=link}
NOTE
Both FastFoods and EuroBank are using the multicast range 239.255.0.0/16 for multicast services within their VPNs. This follows the convention laid out in RFC 2365 for the use of site local addressing. Because FastFoods and EuroBank are in different multicast domains, there is no conflict of the 239.255.0.0/16 range.
SuperCom is using AS 10 and has deployed PIM Bi-Dir. This means that although the routing in the core is not the most optimal, the amount of state information is kept to a minimum. The Paris PE router acts as the RP (denoted in the figure by RPS) and serves as the root of all MDT shared trees in the SuperCom global space. The SuperCom RP to group mapping information is distributed via Auto-RP. Later in the chapter, you will learn about the operation of PIM SSM in the SuperCom network as an alternative to PIM SM.
The San Jose, Washington, and Paris PE routers join the EuroBank multicast domain (239.192.10.2) because they have a EuroBank mVRF configured (regardless of whether receivers are active). Only the San Jose and Paris PE routers join the FastFoods multicast domain (239.192.10.1). The Washington PE router does not join the FastFoods domain because it does not have a FastFoods VRF configured. Figure 7-7 shows the logical view of the Default-MDTs in the SuperCom network.
Table 7-2 provides a summary of the topology information in the SuperCom network to assist in understanding the examples in the following sections.
Table 7-2 SuperCom Topology Information
|
Company |
Site/Category |
Item |
Value |
|
SuperCom Backbone |
Paris (PE Router) |
Lo0: |
194.22.15.1/32 |
|
|
San Jose (PE Router) |
Lo0: |
194.22.15.2/32 |
|
|
Washington (PE Router) |
Lo0: |
194.22.15.3/32 |
|
|
Circuit Addresses |
PE<->CE |
192.168.2.0/24 |
|
|
PIM |
Mode |
Bidirectional |
|
|
PIM |
Rendezvous Point (Auto-RP) |
195.22.15.1 (SuperCom Paris) |
|
FastFoods |
San Jose (CE Router) |
Subnet |
195.12.2.0/24 |
|
|
San Jose (CE Router) |
Source Group |
(195.12.2.6, 239.255.0.30) |
|
|
Lyon |
Subnet |
10.2.1.0/24 |
|
|
PIM |
Mode |
SSM |
|
|
MDT |
Default |
239.192.10.1 |
|
|
MDT |
Data |
239.192.20.16/28 |
|
EuroBank |
Paris (CE Router) |
Subnet |
196.7.25.0/24 |
|
|
Paris (CE Router) |
Source Group |
(196.7.25.12, 239.255.0.20) |
|
|
Washington (CE Router) |
Subnet |
196.7.26.0/24 |
|
|
San Jose (CE Router) |
Subnet |
10.2.1.0/24 |
|
|
PIM |
Mode |
Sparse |
|
|
PIM |
Rendezvous Point (Static) |
196.7.25.1 (EuroBank Paris) |
|
|
MDT |
Default |
239.192.10.2 |
|
|
MDT |
Data |
239.192.20.32/28 |
PIM SM in the SuperCom Network
As highlighted throughout this chapter, the only requirement on the core network is that native multicast be enabled. Because we are using Auto-RP, each applicable P-network interface in SuperCom is configured with the command ip pim sparse-dense-mode. To keep the multicast routing state to a minimum, PIM Bi-Dir mode is also enabled on each SuperCom router with the global command ip pim bidir-enable. (In addition, Bi-Dir must be enabled for individual groups.)
Auto-RP is used to distribute the Default-MDT (239.192.10.0/24) and Data-MDT (239.192.20.0/24) ranges of group addresses to all other P routers and PE routers. This is accomplished by configuring the Paris PE router (the RP for SuperCom), as shown in Example 7-9.
Example 7-9 Auto-RP Configuration for SuperCom
ip access-list standard MDT-Range permit 239.192.10.0 0.0.0.255 permit 239.192.20.0 0.0.0.255 ! ip pim send-rp-announce Loopback0 scope 64 group-list MDT-Range bidir ip pim send-rp-discovery Loopback0 scope 64
You can verify distribution of RP information by examining the group-to-rendezvous point mapping cache on another PE router, as shown in Example 7-10.
Example 7-10 Confirming Auto-RP Information
SuperCom_Washington#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 239.192.10.0/24
RP 194.22.15.1 (SuperCom_Paris), v2v1, bidir
Info source: 194.22.15.1 (SuperCom_Paris), elected via Auto-RP
Uptime: 3d15h, expires: 00:02:52
Group(s) 239.192.20.0/24
RP 194.22.15.1 (SuperCom_Paris), v2v1, bidir
Info source: 194.22.15.1 (SuperCom_Paris), elected via Auto-RP
Uptime: 3d15h, expires: 00:02:55
The output confirms that the Default-MDT and the Data-MDT will operate in Bi-Dir mode and that the root of the shared trees created from these groups will be the Paris PE router. This means that all traffic for Default- and Data-MDTs will flow via the Paris PE router. If Bi-Dir mode were not enabled, then a shortest path tree would eventually be created for each Default- or Data-MDT by using an (S, G) pair instead of (*, G). That would create more state information in the network, but it might provide a more optimal route.
NOTE
Bi-Dir mode has only been enabled for the MDT group ranges in the SuperCom network. This does not preclude the use of other available modes such as PIM SM or SSM for other multicast groups.
PIM must also be enabled on the interface that Multiprotocol BGP uses for its peering address. This is important because the address on that interface is used as the root of the MDT and is carried in PIM hello messages via the MTI. All the SuperCom routers use loopback0 as their BGP interface and have multicast enabled, as shown in Example 7-11 for the Paris PE router.
Example 7-11 Enabling Multicast on the BGP Peering Interface
router bgp 10 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 194.22.15.2 remote-as 10 neighbor 194.22.15.2 update-source Loopback0 neighbor 194.22.15.3 remote-as 10 neighbor 194.22.15.3 update-source Loopback0 no auto-summary ! [snip] interface Loopback0 ip address 194.22.15.1 255.255.255.255 ip pim sparse-dense-mode !
Enabling Multicast in VRFs
After basic multicast has been enabled in the core of the SuperCom network, you can enable multicast on each of the FastFoods and EuroBank VRFs. The configurations vary slightly depending on whether a Data-MDT is required (that is, multicast sources originate from this VRF) and which multicast mode the customer is using.
Example 7-12 shows the configuration for the FastFoods VRF. Every FastFoods VRF uses the same Default-MDT of 239.192.10.1. The Data-MDT range of 239.192.20.16/28 is used for any multicast stream on the Default-MDT that exceeds 1 Kbps. Note that the mdt data command only needs to be applied to the PE router at San Jose because this PE router has a FastFoods source connected. However, if FastFoods VPN sources existed at other PE routers, then the same mdt data commands could be applied. Multicast routing is enabled on the VRF by using the ip multicast-routing vrf command. Each interface that is associated with the FastFoods VRF requires PIM to be enabled. Because FastFoods has chosen to use SSM, you must make the VRF aware of this fact so that it can create the correct multicast routing entries in the FastFoods mVRF. You can accomplish this with the ip pim vrf FastFoods ssm range command.
Example 7-12 FastFoods mVRF Configuration
ip vrf FastFoods rd 10:26 route-target export 10:26 route-target import 10:26 mdt default 239.192.10.1 mdt data 239.192.20.16 0.0.0.15 threshold 1 fl San Jose PE only ! ip multicast-routing vrf FastFoods ! interface Serial4/0 ip vrf forwarding FastFoods ip address 192.168.2.18 255.255.255.252 ip pim sparse-mode ! ip pim vrf FastFoods ssm range FastFoods_Site_Local_Scope ! ip access-list standard FastFoods_Site_Local_Scope permit 239.255.0.0 0.0.255.255
The EuroBank configuration shown in Example 7-13 is similar to FastFoods. (The MDT ranges differ, of course!) EuroBank is using a static RP configuration; therefore, you must configure each EuroBank VRF with a static group to RP mapping by using the command ip pim vrf EuroBank rp-address. The Data-MDT configuration is only required at the Paris PE router because the only source EuroBank has is in its Paris site.
Example 7-13 EuroBank mVRF Configuration
ip vrf EuroBank rd 10:27 route-target export 10:27 route-target import 10:27 mdt default 239.192.10.2 mdt data 239.192.20.32 0.0.0.15 threshold 1 fl Paris PE only ! ip multicast-routing vrf EuroBank ! interface Serial0/0 ip vrf forwarding EuroBank ip address 192.168.2.26 255.255.255.252 ip pim sparse-mode ! ip pim vrf EuroBank rp-address 196.7.25.1 EuroBank_Site_Local_Scope ! ip access-list standard EuroBank_Site_Local_Scope permit 239.255.0.0 0.0.255.255
Multicast Tunnel Interfaces
When the Default-MDT is configured, the SuperCom PE router immediately creates a tunnel interface by using the IP characteristics from the loopback0 interface. A Multiprotocol BGP update message is then sent to all the other PE routers that are BGP peers to signal the existence of the new Default-MDT. The PE router issues a P-join to the SuperCom RP for the Default-MDT group.
Example 7-14 shows some interesting information when a Default-MDT is configured, in this case on the EuroBank VRF at the SuperCom Paris PE router. Tunnel0 is used as the MTI for the EuroBank mVRF. The interface characteristics show that traffic entering Tunnel0 is encapsulated by using GRE with a destination address of 239.192.10.2 (Default-MDT) and a source address of 194.22.15.1 (learned from loopback0).
Inside the EuroBank VRF, you can see two PIM-enabled interfaces. Serial0/0 is the connection to the EuroBank CE router in Paris, and Tunnel0 is the MTI that provides access to and from the Default-MDT. The MTI is treated as a multiaccess interface; therefore, a designated router (DR) with the IP address 194.22.15.3 has been selected by using normal PIM designated router election rules. The PIM adjacencies that are formed over the MTI are discussed in a following section. Note that the tunnel operates in SD mode and the neighbor count is 2, which corresponds to the other PE routers.
Example 7-14 EuroBank Multicast Tunnel Interface
02:05:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to up
SuperCom_Paris#show interface tunnel0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of Loopback0 (194.22.15.1)
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 194.22.15.1 (Loopback0), destination 239.192.10.2, fastswitch
TTL 255
Tunnel protocol/transport GRE/IP Multicast, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
[snip]
SuperCom_Paris#show ip pim vrf EuroBank interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.2.26 Serial0/0 v2/S 1 30 1 0.0.0.0
194.22.15.1 Tunnel0 v2/SD 2 30 1 194.22.15.3
Example 7-15 shows debug output from the San Jose PE router of the BGP update message that was received from the Paris PE router when the EuroBank Default-MDT was created. The MDT extended community attribute shows that the MDT group is 239.192.10.2 and that the root of this group is 194.22.15.1, as shown in the mVPN-IPV4 address 2:10:27:194.22.15.1/32.
Example 7-15 EuroBank MDT BGP update
BGP(2): 194.22.15.1 rcvd UPDATE w/ attr: nexthop 194.22.15.1, origin ?, localpref 100, extended community RT:10:27 MDT:10:239.192.10.2 BGP(2): 194.22.15.1 rcvd 2:10:27:194.22.15.1/32
Example 7-16 shows the contents of the BGP VPNv4 table on the San Jose PE router for the MDT updates it has received from its peers. Two route distinguisher entries correspond to the FastFoods (2:10:26) and EuroBank (2:10:27) multicast domains. Each PE router that has advertised a Default-MDT for these domains is listed under the route distinguisher entry. As you can see, if you exclude the local San Jose PE router entry, there is one peer for FastFoods (Paris PE router 194.22.15.1), and there are two peers for EuroBank (Paris PE router and Washington PE router 194.22.15.3), as per the SuperCom topology.
Example 7-16 Default-MDT Summary BGP VPNv4 Table
SuperCom_SanJose#show ip bgp vpnv4 all | begin 2:10:26 Route Distinguisher: 2:10:26 *>i194.22.15.1/32 194.22.15.1 100 0 ? *> 194.22.15.2/32 0.0.0.0 0 ? Route Distinguisher: 2:10:27 *>i194.22.15.1/32 194.22.15.1 100 0 ? *> 194.22.15.2/32 0.0.0.0 0 ? *>i194.22.15.3/32 194.22.15.3 100 0 ?
Example 7-17 shows the details of the EuroBank and FastFoods MDT entries received via Multiprotocol BGP from the Paris PE router.
Example 7-17 Detail MDT BGP Entry
SuperCom_SanJose#show ip bgp vpnv4 all 194.22.15.1 BGP routing table entry for 2:10:26:194.22.15.1/32, version 38 Paths: (1 available, best #1, no table, not advertised to EBGP peer) Not advertised to any peer Local 194.22.15.1 (metric 66) from 194.22.15.1 (194.22.15.1) Origin incomplete, localpref 100, valid, internal, mdt, no-import, best Extended Community: RT:10:26 MDT:10:239.192.10.1 BGP routing table entry for 2:10:27:194.22.15.1/32, version 37 Paths: (1 available, best #1, no table, not advertised to EBGP peer) Not advertised to any peer Local 194.22.15.1 (metric 66) from 194.22.15.1 (194.22.15.1) Origin incomplete, localpref 100, valid, internal, mdt, no-import, best Extended Community: RT:10:27 MDT:10:239.192.10.2
NOTE
As discussed previously, this BGP information is currently accessed only by SSM procedures. All routers cache this information regardless of whether they are configured to use SSM. Other uses for this information are currently being investigated.
Even though the BGP update contains route target extended community, it is not imported into a VRF because of the presence of the MDT extended community attribute.
Now that the mVRFs and the MTIs have been created, it is a good time to examine the MDTs that have been created in the core of the SuperCom network.
Multicast Distribution Trees
The SuperCom network creates a separate, bidirectional tree for each of the FastFoods and EuroBank multicast domains by using standard PIM procedures. Example 7-18 shows the global multicast routing table for the Paris PE router. The other PE routers that are within the SuperCom network have similar (*, G) entries.
The multicast domains are represented by a bidirectional entry, denoted with the B flag. The Z flag signifies that this entry is a multicast tunnel and that a mVRF is connected to it, indicated by the C flag. The associated VRF appears in the olist of the entry. The olist entry also shows Serial0/2, which is a global interface that connects to the other SuperCom routers. Because the Paris PE router is the RP, the Bidir-upstream field is null. If this router were not the RP, this field would contain the local interface in the direction of the RP.
Example 7-18 Paris PE Global Multicast Routing Table
SuperCom_Paris#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.192.10.1), 06:00:44/00:03:12, RP 194.22.15.1, flags: BCZ
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
MVRF FastFoods, Forward/Sparse-Dense, 06:00:44/00:00:00
Serial0/2, Forward/Sparse-Dense, 06:00:44/00:02:57
(*, 239.192.10.2), 06:00:44/00:03:22, RP 194.22.15.1, flags: BCZ
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
MVRF EuroBank, Forward/Sparse-Dense, 06:00:44/00:00:00
Serial0/2, Forward/Sparse-Dense, 06:00:45/00:02:31
An MDT multicast entry does not necessarily have the Z flag set on all routers. For example, the Washington PE router has a connection only to the EuroBank CE router; therefore, it has no need to originate (be the root) or terminate (be the leaf) the FastFoods MDT (239.192.10.1). The Washington PE multicast table is shown in Example 7-19. The FastFoods MDT entry has only the B flag set, which means that Washington just passes traffic straight through.
Example 7-19 Washington PE Global Multicast Routing Table
SuperCom_Washington#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.192.10.1), 3d23h/00:03:27, RP 194.22.15.1, flags: B
Bidir-Upstream: Serial4/0, RPF nbr 194.22.15.22
Outgoing interface list:
POS3/0, Forward/Sparse-Dense, 07:54:24/00:03:09
Serial4/0, Bidir-Upstream/Sparse-Dense, 07:54:24/00:00:00
(*, 239.192.10.2), 3d23h/00:03:30, RP 194.22.15.1, flags: BCZ
Bidir-Upstream: Serial4/0, RPF nbr 194.22.15.22
Outgoing interface list:
POS3/0, Forward/Sparse-Dense, 07:54:24/00:03:30
Serial4/0, Bidir-Upstream/Sparse-Dense, 07:54:26/00:00:00
MVRF EuroBank, Forward/Sparse-Dense, 07:54:27/00:00:00
mVRF PIM Adjacencies
In each mVRF, PIM adjacencies are formed with the associated FastFoods or EuroBank CE routers, and also over the MTI to the other PE routers in the multicast domain. Example 7-20 shows the adjacencies that are formed at the Paris PE router for EuroBank and FastFoods. The example shows that the Paris PE router has created two tunnel interfaces: Tunnel0 for EuroBank and Tunnel1 for FastFoods.
For EuroBank, two PIM adjacencies have been formed over Tunnel0—one to the San Jose PE router (194.22.15.2) and the other to the Washington PE router (194.22.15.3)—because both of these PE routers have a EuroBank VRF that is multicast enabled. Because the tunnel behaves as a multiaccess medium, the designated router elected is the PE router with the highest IP address or the highest nominated priority. (In our example, all the priorities are set to a default of 1.)
Tunnel1 in the FastFoods VRF has formed a single PIM adjacency to the San Jose PE router, with that PE router also being elected the DR. The PIM adjacencies to CE routers in both VRFs are formed in the normal manner. Note that the neighbor addresses on the tunnels are also those used for BGP peering.
Example 7-20 VRF PIM Adjacencies
SuperCom_Paris#show ip pim vrf EuroBank neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 192.168.2.25 Serial0/0 02:47:14/00:01:32 v2 1 / B S 194.22.15.2 Tunnel0 02:46:38/00:01:37 v2 1 / B S 194.22.15.3 Tunnel0 02:46:38/00:01:38 v2 1 / DR B S SuperCom_Paris#show ip pim vrf FastFoods neighbor PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 192.168.2.21 FastEthernet0/1 08:35:18/00:01:38 v2 1 / B S 194.22.15.2 Tunnel1 08:34:38/00:01:40 v2 1 / DR B S
mVRF Routing Entries
Now that the MDTs are set up and the PE router PIM adjacencies have been formed, you can look at the multicast routing tables that have been created in each of the mVRFs. Example 7-21 shows the routing tables for the EuroBank VRF at the Paris and Washington PE routers. The San Jose PE router does not have active receivers or sources connected to the EuroBank San Francisco mVRF; therefore, its EuroBank multicast routing table is empty. For purposes of clarity, the output has been clipped to show relevant information only.
Example 7-21 Multicast Routing Table for EuroBank VPN
SuperCom_Paris#show ip mroute vrf EuroBank [snip] (*, 239.255.0.20), 09:15:02/00:03:02, RP 196.7.25.1, flags: S Incoming interface: Serial0/0, RPF nbr 192.168.2.25 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 09:15:02/00:03:02 SuperCom_Washington#show ip mroute vrf EuroBank [snip] (*, 239.255.0.20), 4d01h/00:03:27, RP 196.7.25.1, flags: S Incoming interface: Tunnel0, RPF nbr 194.22.15.1 Outgoing interface list: Ethernet5/0, Forward/Sparse, 4d01h/00:03:27
Looking at the Paris PE router (*, 239.255.0.20) routing entry, you can see that the incoming interface is Serial0/0, which connects to the EuroBank Paris CE router where the source resides. The olist contains Tunnel0, which means that any multicast traffic that is destined to this interface is encapsulated and transmitted via the Default-MDT.
There is a receiver for (*, 239.255.0.20) at the Washington PE router, which you can see in the Washington mVRF routing table. The incoming interface is Tunnel0, and the olist contains Ethernet5/0, which points to the FastFoods Washington CE router. The EuroBank Washington CE router has issued a C-join toward the EuroBank RP (196.7.25.1) over Tunnel0.
The multicast packets received from the EuroBank Paris source are de-encapsulated and forwarded to the EuroBank mVRF, not because the incoming interface is Tunnel0, but because of the global entry for the EuroBank MDT (*, 239.192.10.2) having the Z flag set. This can be confirmed by referring back to Example 7-19, which shows the Washington PE router's global multicast routing table.
The incoming Tunnel0 interface is used to verify the RPF check for the EuroBank source (196.7.25.12), as shown in Example 7-22. Notice that the RPF neighbor is the BGP peer address of the Paris PE router where 196.7.25.12 originated.
Example 7-22 RPF Information for EuroBank Source
SuperCom_Washington#show ip rpf vrf EuroBank 196.7.25.12 RPF information for Eurobank_Paris_Source (196.7.25.12) RPF interface: Tunnel0 RPF neighbor: SuperCom_Paris (194.22.15.1) RPF route/mask: 196.7.25.0/24 RPF type: unicast (bgp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables
The EuroBank routing tables shown here are in the PIM SM steady state; that is, the routing entries are connected to the shared tree. No source data is flowing (or the spt-threshold has not been met) from EuroBank Paris; therefore, no shortest path tree has been built back to the Paris source. If there were, you would see an (S, G) entry instead of just (*, G). If an (S, G) entry existed, then it would switch over to a Data-MDT (assuming the threshold was exceeded). You will learn the operation of the Data-MDT in a further section.
Now is a good time to look at the multicast routing entries for FastFoods, shown in Example 7-23. Once again, unnecessary information has been clipped. FastFoods is operating in SSM mode; therefore, the routing entries are denoted by the s flag stating that this entry is part of an SSM group. SSM does not use a RP, and it always uses a source tree (S, G) instead of a shared tree (*, G). As you can see, Tunnel1 appears in the olist at the San Jose PE router and is the incoming interface at the Paris PE router, signifying that the source is at San Jose. Initially, the traffic stream flows over the Default-MDT; when the MDT threshold is exceeded, the traffic stream switches over to the Data-MDT.
Example 7-23 Multicast Routing Table for FastFoods VPN
SuperCom_SanJose#show ip mroute vrf FastFoods [snip] (195.12.2.6, 239.255.0.30), 04:15:49/00:02:35, flags: sT Incoming interface: Serial4/0, RPF nbr 192.168.2.17 Outgoing interface list: Tunnel1, Forward/Sparse-Dense, 04:15:49/00:02:35 SuperCom_Paris#show ip mroute vrf FastFoods [snip] (195.12.2.6, 239.255.0.30), 14:25:19/00:02:50, flags: s Incoming interface: Tunnel1, RPF nbr 194.22.15.2 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 14:25:19/00:02:50
The important thing to remember about these examples is that the SuperCom network is oblivious to the multicast mode of operation in the FastFoods or EuroBank networks. The MTI intrinsically supports PIM SD mode; therefore, the customer's choice of multicast mode, RP placement, or RP-to-group distribution method is of little relevance to the SuperCom network.
Data-MDT Operation
As mentioned previously, due to the absence of receivers or sources, the San Francisco EuroBank mVRF at the San Jose PE router does not have routing entries, as shown in Example 7-24. You can see that although the EuroBank mVRF is empty, the San Jose PE router is still joined to the EuroBank Default-MDT shared tree (*, 239.192.10.2), regardless of whether EuroBank San Francisco has receivers (or sources).
Example 7-24 San Jose PE EuroBank mVRF and Global MDT Entry
SuperCom_SanJose#show ip mroute vrf EuroBank
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
SuperCom_SanJose#show ip mroute 239.192.10.2
[snip]
(*, 239.192.10.2), 03:50:40/00:02:41, RP 194.22.15.1, flags: BCZ
Bidir-Upstream: POS3/0, RPF nbr 194.22.15.18
Outgoing interface list:
POS3/0, Bidir-Upstream/Sparse-Dense, 03:49:35/00:00:00
MVRF EuroBank, Forward/Sparse-Dense, 03:50:40/00:00:00
This means that any traffic that the source in EuroBank Paris sends is not only received by the Washington PE router (which has an interested receiver in its path), but the P-packet also is replicated along the Default-MDT toward the San Jose PE router. At San Jose, the P-packet is decapsulated, and as there is no forwarding entry for this C-packet in the EuroBank mVRF, it is dropped. This process is illustrated in Figure 7-17.
)
Figure
7-17 Unnecessary Replication of Packets in MDT
To overcome this problem, you can use a Data-MDT to send packets only to the PE routers that are interested in the traffic. In the SuperCom network, assume that the two active sources at FastFoods San Jose and EuroBank Paris have started to transmit multicast traffic. After these streams exceed the MDT threshold (set at 1 Kbps), they switch over to a separate Data-MDT. The Data-MDT group is taken from the pool of addresses configured on the respective VRF at the source PE routers (that is, San Jose PE router for FastFoods and Paris PE router for EuroBank).
The Paris PE router joins the Data-MDT (*, 239.192.20.16) for FastFoods, and the Washington PE router joins the Data-MDT (*, 239.192.20.32) for EuroBank. The Data-MDTs that are created are illustrated in Figure 7-18. Notice that the San Jose PE router does not join the EuroBank Data-MDT; therefore, it does not receive unwanted multicast traffic.
)
Figure
7-18 Active Data-MDTs for EuroBank and FastFoods
Using the EuroBank multicast stream as an example, you will see the process of creating the Data-MDT. Because EuroBank is operating in PIM SM, the initial traffic from the EuroBank Paris source is sent over the shared tree to the EuroBank Washington CE router. A source tree (196.7.25.12, 239.255.0.20) is built back to EuroBank Paris from EuroBank Washington within the mVRF context following standard PIM SM rules. This is an important step; if the source traffic were to remain on the (*, G) shared tree, then it would be ineligible to be switched to a Data-MDT.
On the other hand, the FastFoods network does not need to switch from a shared tree because it uses SSM. Therefore, all of FastFoods' traffic is always on a source tree and eligible to be switched to a Data-MDT.
Example 7-25 shows the multicast routing entries for the EuroBank mVRF at the Paris PE router. You can see that there are two entries: the shared tree entry (*, 239.255.0.20) and the newly created source tree entry (196.7.25.12, 239.255.0.20). The interesting thing about the source tree entry is that the "y" flag is set. This means that the source tree entry has switched from the Default-MDT (because the threshold was exceeded) and is now sending its traffic by using the Data-MDT via Tunnel0.
Example 7-25 EuroBank mVRF Routing Entries at SuperCom Paris
SuperCom_Paris#show ip mroute vrf EuroBank
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.20), 2d02h/stopped, RP 196.7.25.1, flags: S
Incoming interface: Serial0/0, RPF nbr 192.168.2.25
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 2d02h/00:03:10
(196.7.25.12, 239.255.0.20), 00:11:06/00:03:23, flags: Ty
Incoming interface: Serial0/0, RPF nbr 192.168.2.25
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:11:12/00:03:10
When the threshold for (196.7.25.12, 239.255.0.20) was exceeded, the Paris PE router sent a Data-MDT TLV join message over the Default-MDT to the Washington and San Jose PE routers. Because the Washington PE router has an interested receiver, it immediately joined the new Data-MDT, whereas the San Jose PE router just cached the message. Example 7-26 shows the PIM debug messages that the Washington PE router output. Note that the messages shown here are from two PIM instances. PIM(1) is the instance running in the mVRF, and PIM(0) is the global instance. The Data-MDT join message indicates that EuroBank traffic for (196.7.25.12, 239.255.0.20) will be switched over to the Data-MDT group 239.192.20.32. This prompts the Washington PE router to issue a P-join for (*, 239.192.20.32) so that it can continue to receive the traffic.
Example 7-26 EuroBank Data-MDT TLV Join Message
PIM(1): MDT join TLV received for (196.7.25.12,239.255.0.20) MDT-data: 239.192.20.32 PIM(1): MDT-data group (*,239.192.20.32) added on interface: Loopback0 PIM(0): Check RP 194.22.15.1 into the (*, 239.192.20.32) entry PIM(0): Building triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.192.20.32
If you look at the routing entries for the EuroBank mVRF in the Washington PE router, as shown in Example 7-27, you see that the source tree entry has the "Y" flag set, indicating that receive traffic for (196.7.25.12,239.255.0.20) has been switched to Data-MDT.
Example 7-27 EuroBank mVRF Routing Entries at the Washington PE
SuperCom_Washington#show ip mroute vrf EuroBank
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.0.20), 5d19h/stopped, RP 196.7.25.1, flags: S
Incoming interface: Tunnel0, RPF nbr 194.22.15.1
Outgoing interface list:
Ethernet5/0, Forward/Sparse, 5d19h/00:03:24
(196.7.25.12, 239.255.0.20), 00:45:48/00:03:28, flags: TY
Incoming interface: Tunnel0, RPF nbr 194.22.15.1
Outgoing interface list:
Ethernet5/0, Forward/Sparse, 00:45:48/00:03:24
NOTE
The procedure for creating the FastFoods Data-MDT is the same as EuroBank except that a different pool of address is used. It would be superfluous to cover the scenario again for FastFoods.
Now that the Data-MDTs have been created, the last thing to examine is the entries in the SuperCom global multicast table. Example 7-28 shows the multicast routing entries at the Paris PE router. Unnecessary information, such as Auto-RP entries, has been pruned (pardon the pun) from the output to improve readability of the example. You can see that two additional shared tree routing entries correspond to the two Data-MDTs (239.192.20.16 and 239.192.20.32). Because the Paris PE router has a receiver in the FastFoods mVRF, it has joined the FastFoods Data-MDT and is forwarding traffic from (*, 239.192.10.16) to the FastFoods mVRF. The Z flag indicates this is a multicast tunnel, and the C flag indicates that an mVRF is connected. The Paris PE router is a leaf of the (*, 239.192.10.16) entry.
Example 7-28 Paris PE Data-MDT Routing Entries
SuperCom_Paris#show ip mroute [snip] (*, 239.192.10.1), 2d03h/00:03:28, RP 194.22.15.1, flags: BCZ Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial0/2, Forward/Sparse-Dense, 1d17h/00:03:16 MVRF FastFoods, Forward/Sparse-Dense, 2d03h/00:00:00 (*, 239.192.10.2), 2d03h/00:03:18, RP 194.22.15.1, flags: BCZ Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: MVRF EuroBank, Forward/Sparse-Dense, 2d03h/00:00:00 Serial0/2, Forward/Sparse-Dense, 2d03h/00:02:38 (*, 239.192.20.16), 00:50:15/00:03:26, RP 194.22.15.1, flags: BCZ Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial0/2, Forward/Sparse-Dense, 00:50:12/00:03:20 MVRF FastFoods, Forward/Sparse-Dense, 00:50:15/00:00:00 (*, 239.192.20.32), 19:08:21/00:03:27, RP 194.22.15.1, flags: BZ Bidir-Upstream: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial0/2, Forward/Sparse-Dense, 01:12:54/00:03:19 [snip]
There is something interesting about the last entry (*, 239.192.10.32), which is the Data-MDT for EuroBank. No C flag is present, which indicates that no mVRF is connected. This is because the Paris PE router is sending traffic to this tunnel from its connected source; the PE router is not receiving traffic from the tunnel. The Paris PE router is the root of the (*, 239.192.10.32) entry only.
To see how the EuroBank or FastFoods (S, G) entries are mapped to a particular Data-MDT, you use the show ip pim mdt command. Example 7-29 shows the (S, G, Data-MDT) details for both active multicast streams at the Paris PE router. The receive command shows that the Paris PE router has joined the Data-MDT 239.192.20.16 for the FastFoods source tree (195.12.2.6, 239.255.0.30). The send command shows that the Paris PE router is encapsulating traffic from the EuroBank source (196.7.25.12, 239.255.0.20) and is sending it to the Data-MDT 239.192.20.32.
Example 7-29 FastFoods and EuroBank Data-MDT Mappings
SuperCom_Paris#show ip pim vrf FastFoods receive detail Joined MDT-data groups for VRF: FastFoods group: 239.192.20.16 source: 0.0.0.0 ref_count: 1 (195.12.2.6, 239.255.0.30), 2d04h/00:03:23/00:03:00, OIF count: 1, flags: sTY SuperCom_Paris#show ip pim vrf EuroBank mdt send MDT-data send list for VRF: EuroBank (source, group) MDT-data group ref_count (196.7.25.12, 239.255.0.20) 239.192.20.32 1
The example also shows a ref_count value. If the Data-MDTs in a pool for a given mVRF have been exhausted due to many active high-bandwidth sources, then Data-MDTs are reused based on the entry that has the lowest ref_count.
SSM in the SuperCom Core
You can deploy the SuperCom core with SSM instead of PIM SM. Doing so obviates the need for a RP, which in turn eliminates a single point of failure. The configuration to enable SSM for MDT groups is simple (see Example 7-30). This configuration is applied to all SuperCom routers in place of RP to MDT-group mappings. The MDT-Range access-list contains the address ranges that the SuperCom network uses for both Default-MDT and Data-MDT. This access-list is associated with SSM by using the ip pim ssm range global command; therefore, any multicast traffic that contains these destination group addresses uses SSM control procedures. Note that both the Default-MDT and Data-MDT ranges are part of the SSM range.
Example 7-30 Enabling SSM
ip pim ssm range MDT-Range ! ip access-list standard MDT-Range permit 239.192.10.0 0.0.0.255 permit 239.192.20.0 0.0.0.255
When a SuperCom PE router creates a new Default-MDT through user configuration, it is signaled by a Multiprotocol BGP update to all its peers, as discussed previously. When a local PE router receives the update, a source tree join is issued back to the originator of the BGP message if the following conditions are met:
The Default-MDT group address matches the local SSM range.
A local mVRF is configured with the same Default-MDT group.
Example 7-31 shows the debug output for the BGP update and the corresponding PIM join from one of the SuperCom routers. This router has received a BGP update from 194.22.15.2 (which happens to be the San Jose PE router) stating that it has created a new Default-MDT 239.192.10.2 (EuroBank VPN). Because this router meets the conditions stated previously, it immediately issues a source join to (194.22.15.2, 239.192.10.2) for the Default-MDT.
Example 7-31 Joining the Default-MDT Using SSM
BGP(2): 194.22.15.2 rcvd UPDATE w/ attr: nexthop 194.22.15.2, origin ?, localpref 100, extended community RT:10:27 MDT:10:239.192.10.2 BGP(2): 194.22.15.2 rcvd 2:10:27:194.22.15.2/32 PIM(0): Send v2 Join on Serial0/2 to 194.22.15.2 for (194.22.15.2/32, 239.192.10.2), S-bit
How does the multicast routing table differ when you are using SSM? Compare the Paris PE router routing table in Example 7-32 using SSM with the same table using PIM Bi-Dir shown previously in Example 7-18. With PIM Bi-Dir, there were only two (*, G) shared tree entries: one for each of the EuroBank and FastFoods multicast domains. As you can see in Example 7-32, with SSM, you have five entries represented by the s flag. Because these are all source trees, you have more optimal routing because traffic does not have to traverse the RP.
Three of the entries in Example 7-32 are source trees that are rooted at remote PE routers. The Paris PE router has joined these source trees (by using SSM) based on Default-MDT information received in the Multiprotocol BGP update; therefore, the I flag has been set for these entries. The Paris PE router forwards traffic received from these entries to the corresponding mVRF in the olist. Of these three I entries, two are for the EuroBank Default-MDT (239.192.10.2) connecting to the San Jose and Washington PE routers, and the third is for the FastFoods Default-MDT (239.192.10.1) connecting to the San Jose PE router.
The other two routing entries in Example 7-32 do not have the I flag set. These entries represent the source trees for the two Default-MDTs rooted at the Paris PE router. Note the S of the (S, G) is 194.22.15.1, which is the loopback0 interface address of the Paris PE router. The remote PE routers issue a corresponding SSM join back to the Paris PE router. The outgoing interfaces point to the SuperCom core network.
Example 7-32 Paris PE Global Multicast Routing Table Using SSM
SuperCom_Paris#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(194.22.15.1, 239.192.10.1), 00:04:22/00:03:27, flags: sTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/2, Forward/Sparse-Dense, 00:02:45/00:03:25
(194.22.15.2, 239.192.10.1), 00:03:02/00:02:57, flags: sTIZ
Incoming interface: Serial0/2, RPF nbr 194.22.15.2
Outgoing interface list:
MVRF FastFoods, Forward/Sparse-Dense, 00:03:02/00:00:00
(194.22.15.1, 239.192.10.2), 00:04:23/00:03:25, flags: sTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/2, Forward/Sparse-Dense, 00:02:47/00:03:24
(194.22.15.2, 239.192.10.2), 00:03:04/00:02:45, flags: sTIZ
Incoming interface: Serial0/2, RPF nbr 194.22.15.2
Outgoing interface list:
MVRF EuroBank, Forward/Sparse-Dense, 00:03:04/00:00:00
(194.22.15.3, 239.192.10.2), 00:03:10/00:02:45, flags: sTIZ
Incoming interface: Serial0/2, RPF nbr 194.22.15.2
Outgoing interface list:
MVRF EuroBank, Forward/Sparse-Dense, 00:03:10/00:00:00
SSM also uses the Data-MDT join message to trigger a join and switch over to the Data-MDT. The way it does this differs slightly from PIM SM. The Data-MDT join message only contains the (S, G, Data-MDT) mapping. PIM SM only requires the value of Data-MDT, so a (*, Data-MDT) P-join can be issued toward the rendezvous point by the receiving PE router. However, SSM requires the source address of the originating PE router, so that a (S-PE, Data-MDT) P-join can be issued. The value of S-PE is derived from the RPF neighbor of S in the (S, G, Data-MDT) mapping. This is verified in the debug and RPF output in Example 7-33.
Example 7-33 Joining the Data-MDT Using SSM
PIM(1): MDT join TLV received for (196.7.25.12,239.255.0.20) MDT-data: 239.192.20.32 PIM(1): MDT-data group (194.22.15.1,239.192.20.32) added on interface: Loopback0 PIM(0): Send v2 Join on Serial4/0 to 194.22.15.22 for (194.22.15.1/3 2, 239.192.20.32), S-bit PIM(0): Building Join/Prune message for 239.192.20.32 SuperCom_Washington#show ip rpf vrf EuroBank 196.7.25.12 RPF information for Eurobank_Paris_Source (196.7.25.12) RPF interface: Tunnel0 RPF neighbor: SuperCom_Paris (194.22.15.1) RPF route/mask: 196.7.25.0/24 RPF type: unicast (bgp 100) RPF recursion count: 0 Doing distance-preferred lookups across tables