The counter is increasing because your frames are being corrupted.
CRC is a polynomial function on the frame which returns a 4B number in Ethernet. It will catch all single bit errors and a good percentage of double bit errors. It is thus meant to ensure that the frame was not corrupted in transit. If your CRC error counter is increasing it means that when your hardware ran the polynomial function on the frame, the result was a 4B number which differed from the 4B number found on the frame itself.
Ethernet frame CRC (FCS) is usually understood to be on OSI layer 2, many people claim it is layer 1 on Ethernet, but that is incorrect (only preamble, SFD and IFG are layer 1 on Ethernet).
I recommend a book called Computer Networks - A systems approach on this and many other subjects. It discusses CRC in-depth around page 92 through 102.
As Daniel pointed out, frames can get corrupted due to several reasons such as: duplex mismatch, faulty cabling and broken hardware. However, some level of CRC errors should be expected and the standard allows up-to 10-12 bit-error-rate on Ethernet (1 bit out of 1012 can flip) and it's acceptable according to the standard.
In copper the signal travels by transferring state between electrons (electrons themselves are not traveling very much) and in fiber the signal travels by the photons reflecting off the walls of the fiber. There is a non-zero chance that the photon will simply change due to heat on the walls or the state of the electrons will flip itself. So even in perfect situations some errors will always happen. It should be known that a bit is not a single photon or single state change of an electron; today you need many photons or electron state changes to express a single bit, so a single incorrect 'state' will not yield an error as a bit is the average state of many of these.
Yes, this data is populated in the Firewall MIB
- .1.3.6.1.4.1.2636.3.5.2.1.5 contains your counters
- .1.3.6.1.4.1.2636.3.5.2.1.6 contains your filter names
- .1.3.6.1.4.1.2636.3.5.2.1.7 contains your counter names
show firewall filter RE-FILTER | match mgmt_ntp
mgmt_ntp 199728 2628
% snmpbulkwalk jnpr .1.3.6.1.4.1.2636.3.5.2.1.7|grep mgmt_ntp
.1.3.6.1.4.1.2636.3.5.2.1.7.9.82.69.45.70.73.76.84.69.82.8.109.103.109.116.95.110.116.112.2 = STRING: "mgmt_ntp"
% snmpbulkwalk jnpr .1.3.6.1.4.1.2636.3.5.2.1.5.9.82.69.45.70.73.76.84.69.82.8.109.103.109.116.95.110.116.112.2
.1.3.6.1.4.1.2636.3.5.2.1.5.9.82.69.45.70.73.76.84.69.82.8.109.103.109.116.95.110.116.112.2 = Counter64: 199728
More information on juniper.net
Best Answer
Did a quick test and it looks like the data is a type 'Timeticks' which is a 32 bit integer. From the RFC:
https://www.rfc-editor.org/rfc/rfc2578#section-7.1.8