Allied Telesis AT-8900 Series manual Following up theories

show ip count

show pim route

show pim count

show pim neighbour

and other commands relevant to the hardware forwarding of multicast in the particular models of switch you are working with.

Once this initial survey is complete, you can start following up your theories about what is going on.

Following up theories

Starting from the symptoms of problem, you can work back through the steps in the networking process to think of various points where something could have gone wrong, and follow up on each of those in turn.

For example, if the symptom is that a certain client never receives multicast streams, then the problem could be:

zthe client is failing to send the IGMP report; or

zthe client is sending the report, but it is being dropped by a switch between the client and the device running PIM; or

zthe IGMP report is reaching the PIM router, but a multicast route is not being created; or….

So, the approach is to follow each of these possibilities—capturing counters, enable debug outputs, ethereal traces, etc to confirm or deny each one. When a particular possibility looks fruitful, then dig deeper into it to try and narrow down more accurately what is not happening correctly. For example, if you see that the IGMP report is not being seen by a particular switch in the chain, you might be able to find that an error counter in the show switch port count output increments every time you try sending the IGMP report, indicating that the reports are being corrupted.

Concrete piece of advice #3: Type your thoughts and actions.

It is important to always keep in mind that it is quite likely that your debug capture will be analysed by someone else later on (or, in fact, you might need to go back through it later yourself). Therefore, it is necessary to record your thinking and actions as you were going along, to give context to all the debugging that was captured.

This achieves two main aims:

zit makes it clear why you were looking at particular counters etc

zit makes it clear how the captures relate to external events. So often it is vital to know whether a particular state change or counter change seen in the debug capture happened before or after a particular external event. For example, 'did that switch port on blade 6 go into STP blocking state before or after port 24 on blade 5 was unplugged..'.

3