• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

CRC calculations inquiry

ive mentioned before that my teacher is crazy. he constantly mixes things up or confuses something. this week we're doing layer 2.

how often are CRC checks done? just at each destination point when the frame is checked?

he gave us a test question, and what he says is the answer (despite having access to the tests, he has given wrong answers before)

PC < ~ethernet > router1 < ~serial(PPP) > router2 < ~serial(PPP) > router3 < ~ethernet > laptop

and said there would be 8 crc calculations: one at each interface that handles the frame.

but when i read in our book...it seems like it should be 4: one for each destination node that *receives* the frame. it doesnt make sense to me that, for instance, router1 would open the frame, check it....then check it again before it packs it up and sends it to router2

i tried looking online, and get 2 and 8. i guess 2 would make sense if a serial PPP connection doesnt deal with CRCs, but I dont know if that is the case or not.

help?
 
CRCs are checked whenever a frame enters a layer2 device or higher. I'm pretty sure the layer2 protocol PPP also contains a checksum but it may not be a CRC so it's a little bit of a trick question. I'm counting in your diagram, "assuming" the ethernet links are a bridge (switch).

Now a NEW CRC is generated when it egresses a layer3 or higher device because the packet itself is actually reframed so he may be counting that.

-edit-
The confusion from the teacher may be the difference from a true CRC and the different WAN checksums. But AFAIK all layer2 protocols have some kind of checksum, whether that checksum is a CRC or another algorithm is up for further research of each protocol.
 
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

I think he's doing a trick question. The best way to word the question would be "how many times is the CRC calculated when a packet is sent in this diagram?" Then it's easy to see it's 8. CRC is always calculated on the ingress and egress ports. It's checked/compared against the received frame's CRC on the ingress, or it's inserted in the frame on the egress port.
 
Originally posted by: mcmilljb
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

CRC is always calculated on the ingress and egress ports.

if thats the case then i misunderstood what I was reading in the book(not for the first, or the last, time)

i guess it makes more sense when i consider that the frame is being taken apart, and then another frame created, in the router, so it *would* have to be calculated twice at each router: once when its received, and once when its prepared for a new frame.
 
Originally posted by: xSauronx
Originally posted by: mcmilljb
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

CRC is always calculated on the ingress and egress ports.

if thats the case then i misunderstood what I was reading in the book(not for the first, or the last, time)

i guess it makes more sense when i consider that the frame is being taken apart, and then another frame created, in the router, so it *would* have to be calculated twice at each router: once when its received, and once when its prepared for a new frame.

You're close, and this is why the OSI model is pounded so hard. Learn it, live it, love it. The frame just delivers on L2, the frame isn't taken apart at all...it did it's job, it delivered it at L2 and now L3 does it's job. Layer2 is only significant at layer2, the other layers don't care.

The frame (L2) is just picked up by a device because it was addressed to it at L2, whatever L2 protocol that may be or L1 protocol that may be. I still call it a trick question that could answered many different ways.
 
Originally posted by: xSauronx
Originally posted by: mcmilljb
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

CRC is always calculated on the ingress and egress ports.

if thats the case then i misunderstood what I was reading in the book(not for the first, or the last, time)

i guess it makes more sense when i consider that the frame is being taken apart, and then another frame created, in the router, so it *would* have to be calculated twice at each router: once when its received, and once when its prepared for a new frame.

I think you're catching on. When the frame is received, the router can't just look at the checksum value and say "looks good to me." It has to calculate the checksum itself so it can confirm the frame was received without errors by comparing the calculated checksum to the received frame's checksum. When the router determines where to send the packet, it has to add its layer 2 information to create the new frame. Since the frame contains new information, the previous checksum value is now invalid, and the router will create a checksum value running the same process on the new frame that it used to check the original frame. On a switch, it does the same process of comparing the received frame's checksum to the calculated checksum. It doesn't add/change any information therefore it doesn't have to calculate a new checksum value.

Class dismissed. lol

edited for typo and more completeness
 
Originally posted by: mcmilljb
Originally posted by: xSauronx
Originally posted by: mcmilljb
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

CRC is always calculated on the ingress and egress ports.

if thats the case then i misunderstood what I was reading in the book(not for the first, or the last, time)

i guess it makes more sense when i consider that the frame is being taken apart, and then another frame created, in the router, so it *would* have to be calculated twice at each router: once when its received, and once when its prepared for a new frame.

It has to calculate the checksum itself so it can confirm the frame was received without errors by comparing the calculated checksum to the received frame's checksum. When the router determines where to send the packet, it has to add its layer 2 information to create the new frame. Since the frame contains new information, the previous checksum value is now invalid, and the router will create a checksum value running the same process on the new frame that it used to check the original frame.

got it 🙂

Originally posted by: spidey07
Originally posted by: xSauronx
Originally posted by: mcmilljb
I did a check on PPP, and Spidey is correct. It uses FCS which is a CRC.

CRC is always calculated on the ingress and egress ports.

if thats the case then i misunderstood what I was reading in the book(not for the first, or the last, time)

i guess it makes more sense when i consider that the frame is being taken apart, and then another frame created, in the router, so it *would* have to be calculated twice at each router: once when its received, and once when its prepared for a new frame.

You're close, and this is why the OSI model is pounded so hard. Learn it, live it, love it.

one of these days. im doing well in class, but because of the schedule that has been arranged we're rushing through things, so i have to go back on my own time to get a better understanding of the specifics.

thanks everyone 🙂
 
OSI model!!!! wahoo!!!! You thought it wasn't important!!!?? Why do anything and everything having to do with networking...why do they keep preaching this crap? BECAUSE IT'S JUST THAT FUNDAMENTAL.

Learn it, live it, love it.
 
Originally posted by: xSauronx
one of these days. im doing well in class, but because of the schedule that has been arranged we're rushing through things, so i have to go back on my own time to get a better understanding of the specifics.

thanks everyone 🙂

Start looking at packet captures (wireshark). Do a simple FTP transfer and look at every single frame/packet/whatever...it will start to become clear.

Nothing will teach better than looking at that and examining the layers.
 
Originally posted by: spidey07
Originally posted by: xSauronx
one of these days. im doing well in class, but because of the schedule that has been arranged we're rushing through things, so i have to go back on my own time to get a better understanding of the specifics.

thanks everyone 🙂

Start looking at packet captures (wireshark). Do a simple FTP transfer and look at every single frame/packet/whatever...it will start to become clear.

Nothing will teach better than looking at that and examining the layers.

i know. and the thing i hate most is ....that kind of thing. :-/

i have packet tracer, fwiw, and have been using that whenever the book we have calls for it (2-3 instances per chapter, usually) but ill play around with wireshark a bit too.
 
Originally posted by: xSauronx
Originally posted by: spidey07
Originally posted by: xSauronx
one of these days. im doing well in class, but because of the schedule that has been arranged we're rushing through things, so i have to go back on my own time to get a better understanding of the specifics.

thanks everyone 🙂

Start looking at packet captures (wireshark). Do a simple FTP transfer and look at every single frame/packet/whatever...it will start to become clear.

Nothing will teach better than looking at that and examining the layers.

i know. and the thing i hate most is ....that kind of thing. :-/

i have packet tracer, fwiw, and have been using that whenever the book we have calls for it (2-3 instances per chapter, usually) but ill play around with wireshark a bit too.

It's not that bad bud. I had to use Wireshark(it was called Ethereal back then) for assignments back in college, and we had to do it on really old SPARC Solaris machines. You were lucky if you got to use one of the 100+ MHz ones too lol. Luckily, we started replacing them with some high-end Dell workstations with Linux(Slackware).
 
Showing my age...

Back then it was called Sniffer and it ran on DOS, and it cost about 30,000 dollars. And you had all these wonderful interface cards you could get to see the packets/frames on the wire, no matter what that wire was.
 
Originally posted by: spidey07
Showing my age...

Back then it was called Sniffer and it ran on DOS, and it cost about 30,000 dollars. And you had all these wonderful interface cards you could get to see the packets/frames on the wire, no matter what that wire was.

... and they had interfaces you could even see the preamble of the frame.

NICs just aren't as promiscuous as they used to be.

 
Yeah, you could actuall SEE where the collision occured. I forget what the pattern was but in an ethernet frame with a BAD CRC you could see the telltalle ADADACACFFFF of the preamble of the frame that collided with it.
 
Back
Top