Few questions

Hi all,

Do layer models / architectures enable faster data transmission?
Switch fills the CAM table based on destination MAC addresses, right?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Forsaken_GA

NewTecher wrote: »

Hi all,

Do layer models / architectures enable faster data transmission?

Yes and No. They're just frameworks to design by. A properly designed network will generally function better than a badly designed one. The trick is that a properly designed network is dependent on the specification of the needs of the business implementing it. For example, I could have the exact same layout for two different networks. If one of them is only needing to move bulk traffic around, it'll perform fine.

If I took that same layout and all of a sudden I needed to support voice and video in addition to bulk transfer, it would perform badly without some tweaking.

network design best practices are kind of like the pirate code - they're guidelines. There are no hard and fast rules, and what you implement depends entirely on your needs.

And then there's the fact that I could follow every best practice in the book in the design. But if I use crappy or old hardware, it's not going to go faster. Making the network go faster involves a metric fragton of variables.

Switch fills the CAM table based on destination MAC addresses, right?

Nope, source. When you transmit a frame, you have a source MAC address, and a destination MAC address.

When you transmit a frame to the switch, it looks at the source MAC, and notes that 'this source MAC can be found on this port".

Then it looks at the destination MAC. If it finds a match in the CAM table, it sends it out that port. If it doesn't, then it broadcasts the frame out all ports except the one that it was received on.

When the real destination responds, the switch notes that (again, it sees the source mac on the incoming frame, notes which port it came from), and from then on (or until the entry ages out), the two nodes can communicate directly without the need for further broadcasts.

It's impossible to populate based on destination. In order to populate by destination, you'd have to know where they are ahead of time, and if you already know that, it's already populated. It's a chicken and egg problem. So instead, it applies the shotgun method and just yells at everyone, and then makes a note about who responds.

NewTecher

Forsaken_GA wrote: »

Yes and No. They're just frameworks to design by. A properly designed network will generally function better than a badly designed one. The trick is that a properly designed network is dependent on the specification of the needs of the business implementing it. For example, I could have the exact same layout for two different networks. If one of them is only needing to move bulk traffic around, it'll perform fine.

If I took that same layout and all of a sudden I needed to support voice and video in addition to bulk transfer, it would perform badly without some tweaking.

network design best practices are kind of like the pirate code - they're guidelines. There are no hard and fast rules, and what you implement depends entirely on your needs.

And then there's the fact that I could follow every best practice in the book in the design. But if I use crappy or old hardware, it's not going to go faster. Making the network go faster involves a metric fragton of variables.

Nope, source. When you transmit a frame, you have a source MAC address, and a destination MAC address.

When you transmit a frame to the switch, it looks at the source MAC, and notes that 'this source MAC can be found on this port".

Then it looks at the destination MAC. If it finds a match in the CAM table, it sends it out that port. If it doesn't, then it broadcasts the frame out all ports except the one that it was received on.

When the real destination responds, the switch notes that (again, it sees the source mac on the incoming frame, notes which port it came from), and from then on (or until the entry ages out), the two nodes can communicate directly without the need for further broadcasts.

It's impossible to populate based on destination. In order to populate by destination, you'd have to know where they are ahead of time, and if you already know that, it's already populated. It's a chicken and egg problem. So instead, it applies the shotgun method and just yells at everyone, and then makes a note about who responds.

Yes, I thought something like that.
Great explanation, thank you very much friend

Now I know who to bother when I have some more questions :P

p.s
another quick one to confirm it, can frame switch between different network implementations..without any bigger/important changes?

Forsaken_GA

NewTecher wrote: »

another quick one to confirm it, can frame switch between different network implementations..without any bigger/important changes?

It depends on what you mean by different network implementations. Could you be a little more specific?

If you mean bridging two different types of layer 2 (ie, ethernet to token ring), it'll need a media converter at the bare minimum, which isn't usually a big change, but does introduce another point of failure. Or it can be done at layer 3 with a router, which is a bigger change, but is more reliable in my experience (I hate media converters). However, if you're going from say copper ethernet to fiber ethernet, that's easier, it's all ethernet, so the frame type doesn't change, you just need the proper interfaces on the switch (or, again, a media converter!)

Like most things in the network world, the answer is 'it depends'.