Allied Telesis AT-8900 Series Manuale Utente
3
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.
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.
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.
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:
problem could be:
z
the client is failing to send the IGMP report; or
z
the client is sending the report, but it is being dropped by a switch between the client and
the device running PIM; or
the device running PIM; or
z
the IGMP report is reaching the PIM router, but a multicast route is not being created;
or….
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.
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.
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.
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:
z
it makes it clear why you were looking at particular counters etc
z
it 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..'.
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..'.
Concrete piece of advice #3: Type your thoughts and actions.