CCDE Study Group October 2019
Date: June 13, 2019. Rev 0.
Note that this exercise continues the practical exercise demo3: Practical exercise: demo3
Re: 3_Service stability
Thank you for your advice toward service consolidation in our network. You have been recently hired, but you performed very well in the last few weeks, so you’re going to be promoted very soon. In the meanwhile, we need some additional help and we hope you can help us improve the network so we can give better service to our customers.
This week, we detected that must be some kind of problem with the design or something we implemented to deliver the video stream from out main DC located in LA to any of the other locations where video feeds are requested and delivered.
The helicopters do not fly every day, they have shifts and not all the roads are being monitored every week day. Sometimes, they fly over the week and if there is some special event, they are operating at full capacity on the weekends.
The problem we detected is related to the time needed to receive the feed in the remote location after the application request it. We measured up to 3 min delays in this process and this is becoming a problem. This problem is more severe on the weekends, and we suspect it’s because we’re doing additional asynchronous replication works between out 2 DCs.
Do you need additional information to spot the problem and provide a solution? (Select 1):
In case you selected Yes in the previous question. What additional information do you need? (Select 2):
- Multicast distribution model
- Type of multicast tree
- Authentication mechanism
- Number of receivers
- RP placement
Re: 4_Service stability >> additional information
Here is the information you requested:
The source discovery device is located at the edge of every POP, in the device that connects the local branches with the PE. For economical reasons, the edge WAN device was configured to act as a meeting point and receives the flows from the video sources and the requests from the remote stations.
Regards the addressing, we’re actually using addresses in the limited scope multicast range. We have configured filters to prevent multicast traffic from this address range from flowing outside our autonomous system and other company defined domains who don’t need neither use this kind of flows. Nowadays, the range in use goes from 188.8.131.52 to 184.108.40.206. We’re using one multicast group per source.
I can’t tell you too much about the multicast distribution model. Our implementation engineer is on holidays, so… we need to wait for him to come back. I send you one interesting picture he left on his desk.
- Use the attached picture to select the point
What could be the root cause of the problem? (Select 1):
- RP redundancy mechanism
- RP location
- RP placement
- Resource exhaustion
What solution would you recommend to fix the problem in a short time? (Select 2):
- Set STP threshold = 0
- Ghost RP
- Anycast RP
- Dedicated DCI
- Remove the RP from the data plane
- PIM-SSM migration
If we would want to receive the video feeds via the most optimal paths, what would you recommend? (Select 1):
- No changes, it’s optimal
- Migrate to PIM-SSM
- Use only one Group (G) for all sources
- Use PIM-BiDir
- Use Ghost RP optimization
Re: 5_Multicast service improvements
We are still thinking about what you said earlier over the phone. Every time we have some kind of problem, our team is struggling to find and solve it. We have strict SLAs in our contract and we don’t want to keep lowering our availability. What is your advice? How could we increase availability? (Select 1):
- Change multicast addressing
- Migrate to SSM
- Migrate to BiDir
- Implement RP redundancy
- Implement MoFRR
Select from the list the implications that would have a migration to PIM-SSM (Drag & Drop):
Yes, should be considered
FRR / MoFRR
Optimal traffic flow
Number of Mcast Groups