The Two port ATM2 PIC, similar to PE-2OC3-ATM2-MM, has only one SAR chip on the board and it handles the ATM cell from the ports. It provides specific counters for every port, as described in the technical document. But it has one exception; it is the
Input invalid VCs counter. For more information, refer to the following link:
http://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-interfaces-atm.html
This may cause some confusion with the troubleshooting.
Topology:
...---+Router1 (at-0/3/1.100) +----+ (at-1/3/1.100) Router2 (at-1/3/0) +---linkup but no far end.
Relevant configuration:
Router 1:
set interfaces at-0/3/1 atm-options pic-type atm2
set interfaces at-0/3/1 atm-options vpi 100
set interfaces at-0/3/1 unit 100 vci 100.100
set interfaces at-0/3/1 unit 100 family inet address 10.0.0.1/30
Router 2:
set interfaces at-1/3/1 atm-options pic-type atm2
set interfaces at-1/3/1 atm-options vpi 100
set interfaces at-1/3/1 unit 100 vci 100.101
set interfaces at-1/3/1 unit 100 family inet address 10.0.0.2/30
In the above setup, Router 1 has
at-0/3/1.100 with
vpi.vci = 100.100 and Router 2 has
at-1/3/1.100 with
vpi.vci = 100.101. VPI.VCI mismatches occur due to a configuration error.
Router1 sends the ATM cell with its vpi.vci (100.100); but
at-1/3/1.100 does not know vpi.vci (100.100). It is expected that
at-1/3/1 on Router 2 counts
Input invalid VCs in the ATM statistics; but the error is counted on
at-1/3/0 on Router 2.
From Router 1, ping to
10.0.0.2, which is the IP address of
at-1/3/1.100, on Router 2. Due to the VCI mismatch, the ping fails:
user@Router1> ping 10.0.0.2 interval 0.1 count 100
PING 10.0.0.2 (10.0.0.2): 56 data bytes
--- 10.0.0.2 ping statistics ---
100 packets transmitted, 0 packets received, 100% packet loss
When the ATM statistics on at-1/3/1 of Router2 are checked, it counts the receiving cells; but does not count the cells with the invalid VC to the interface:
user@Router2> show interfaces at-1/3/1 extensive | match "ATM Statistics|Input cell count|Input invalid VCs"
ATM Statistics:
Uncorrectable HCS errors: 0, Correctable HCS errors: 0, Tx cell FIFO overruns: 0, Rx cell FIFO overruns: 0,
Rx cell FIFO underruns: 0, Input cell count: 300,
Output cell count: 79150476, Output idle cell count: 0, Output VC queue drops: 0, Input no buffers: 0,
Input length errors: 0, Input timeouts: 0, Input invalid VCs: 0,
Strangely,
at-1/3/0 counts the
Input invalid VCs; but the
Input cell count stays at
0:
user@Router2> show interfaces at-1/3/0 extensive | match "ATM Statistics|Input cell count|Input invalid VCs"
ATM Statistics:
Uncorrectable HCS errors: 0, Correctable HCS errors: 0, Tx cell FIFO overruns: 0, Rx cell FIFO overruns: 0,
Rx cell FIFO underruns: 0, Input cell count: 0,
Input invalid VCs: 300, Input bad CRCs: 0, Input OAM cell no buffers: 0
For the purpose of comparison,
at-1/3/0 is swiched with
at-1/3/1:
Topology:
...---+Router1 (at-0/3/1.100) +----+ (at-1/3/0.100) Router2 (at-1/3/1) +---linkup but no far end.
Router 1:
set interfaces at-0/3/1 atm-options pic-type atm2
set interfaces at-0/3/1 atm-options vpi 100
set interfaces at-0/3/1 unit 100 vci 100.100
set interfaces at-0/3/1 unit 100 family inet address 10.0.0.1/30
Router 2:
set interfaces at-1/3/0 atm-options pic-type atm2
set interfaces at-1/3/0 atm-options vpi 100
set interfaces at-1/3/0 unit 100 vci 100.101
set interfaces at-1/3/0 unit 100 family inet address 10.0.0.2/30
This time,
at-1/3/0 counts both the Input cells and Input invalid VCs:
user@Router2> show interfaces at-1/3/0 extensive | match "ATM Statistics|Input cell count|Input invalid VCs"
ATM Statistics:
Uncorrectable HCS errors: 0, Correctable HCS errors: 0, Tx cell FIFO overruns: 0, Rx cell FIFO overruns: 0,
Rx cell FIFO underruns: 0, Input cell count: 300,
Input invalid VCs: 300, Input bad CRCs: 0, Input OAM cell no buffers: 0
As mentioned in the summary, SAR chip provides counters for each ATM port. But the SAR chip has only one counter for invalid VCs and it is associated with port 0. So, invalid VCs are counted on port 0, whenever cells with invalid VC are received. This is a hardware limitation of the SAR chip.
As this behavior is due to the hardware limitation, it cannot be changed. If you notice Input invalid VCs being counted, check if the vip.vci configuration matches at both ends. Also, if the configuration is correct, you may need to capture receiving cells on port 0 and 1 to check if wrong cells are being received.