5

I know the difference between a router and a switch, but there are a few fuzzy spots in my understanding.

  1. When you uplink one switch into another, do they share mac address tables? Or is this a vendor specific function? If they don't share, how do they handle packets addressed to macs they don't directly control?

  2. What is the largest IP address space that can be effectively handled using only a switched network, and at what point should you consider breaking the network into multiple segments joined by a router?

  3. Which is more architecturally sound: one core router joining many subnets to the Internet or a hierarchy of routers (one per department uplinking to the core)? Or, is it best to give each department a router and then mesh them together into a mini-internet?

1

5 Answers 5

12

Regarding uplinking one switch into another: No, they don't share MAC address tables. Each switch maintains its own bridging table, which is built by listening to the traffic each switch receives on a give port. Consider the following example (apologies for the terrible ASCII art):

________     1________2      2________1     ________
|Host A|-----|Switch 1|------|Switch 2|-----|Host B|
--------     ----------      ----------     --------

Host A is connected to Switch 1, Port 1. Host B is connected to Switch 2, Port 1. The two switches are interconnected via Port 2 on both.

Assume at the start the the bridging tables of both switches are empty. Host A wants to send frame to Host B. (To simplify things, we'll assuming that host A and host B have static ARP entries for each other, so there is no need to ARP for MAC addresses).

  1. Host A send a frame to Host B. The source MAC of the frame is AA:AA:AA:AA:AA:AA, the destination MAC is BB:BB:BB:BB:BB:BB.
  2. Switch 1 currently has an empty bridging table. On receipt of the frame it does two things:
    1. It creates a new entry in its bridging table that AA:AA:AA:AA:AA:AA exists on Port 1.
    2. As it doesn't know where BB:BB:BB:BB:BB:BB is, it floods the frame to every port except the one it was originally heard from (Port 1).
  3. Switch 2 receives the flooded frame on its Port 2. Again, as its bridging table is initially empty, it follows the same process:
    1. New entry: AA:AA:AA:AA:AA:AA exists on Port 2 (recall this is on Switch 2, which has an independent bridging table from Switch 1)
    2. The frame is flooded out of all ports except the one it was received on.

At this point, Host B receives the frame. When Host B sends a response, the following happens.

  1. Host B send a frame to Host A. The source MAC of the frame is BB:BB:BB:BB:BB:BB, the destination MAC is AA:AA:AA:AA:AA:AA.
  2. Switch 2 currently has one entry in its bridging table (AA:AA:AA:AA:AA:AA -> Port 2). On receipt of the frame it does two things:
    1. It creates an entry in its bridging table that BB:BB:BB:BB:BB:BB exists out of port 1.
    2. As it has a specific bridging table entry for the destination MAC (AA:AA:AA:AA:AA:AA), it forwards the frame out of port 2 only, rather than flooding as it did before.
  3. Switch 1 receives the forwarded frame on its port 2. Again, it follows the same process:
    1. New entry: BB:BB:BB:BB:BB:BB exists out of port 2
    2. There is a specific bridging table entry (AA:AA:AA:AA:AA:AA -> port 1), so the frame is forwarded out of that port only.

In terms of learning MAC addresses, this same process is followed regardless of the number of switches and the number of devices connected to them. As you add more complexity to your switched network (VLANs, Spanning Tree), more subtleties come in to play, but the base algorithm remains the same.

Regarding your second and third questions:

2) My personal bias is to minimise switching wherever possible. Spanning tree is the bane of many professional lives; add to that the fact that Ethernet has no loop protection; a minor misconfiguration could lead to broadcast storms that require you to manually intervene and down links in order for them to subside. Even if your network is small, have at least one router off which all your layer 2 subnets hang; it's just easier in my opinion.

3) It depends very much on the scale of your network, and how much intranet vs. internet traffic you expect to see. If there will be a lot of communication between departments, it may make sense to have a hierarchy of routers so that pure internal traffic does not impact internet access for everyone else. If on the other hand, you expect everyone to access only a common set of services (AD, email) and the internet, then a single core router (or a pair, for redundancy) may be sufficient.

In terms of giving each department a router and meshing them, how is this network to be administered? If there is going to be one administrative IT authority, then just build a hierarchical network; having users served by shared routers won't be a problem. If each department is going to maintain their own IT staff, then a router per department and internal peering may be required, but it will most likely complicate your network design.

1

I'm going to try to answer all of your questions as clearly as possible.

  1. There is no sharing of Mac address tables that I know of because there is no need really. The switch will look out for network activity coming from the other switch and write down entries in it's Mac address table. It will also look out for ARP requests. It will only take very little time for it's mac address table to fill up.

For you question concerning macs that they don't directly control I think you mean macs of PCs that aren't directly connected to their ports. Well let's take for example PC A on my switch and PC B on your switch. Both switches are connected via a standard uplink. Your PCs and your switch are all alone in the networking world when I come along and connect my switch. The PC on my switch is going to need your PC's MAC address and to do just that it will need to emit a broadcast ARP message (Level2 Broadcast but Level3 unicast since it has your PC's IP address). My switch will broadcast it on every one of it's ports. Then it arrives on your switch who will do the same. Then your PC will answer to my PC and they will both know each other's mac address. In the process, both switch will write down the mac addresses they didn't know.

  1. Remember, switch-only networks operate on level 2 so they are (theoreticaly) independent from level 3. Let's just say going beyond a /8 (255.0.0.0) is not very reasonnable and will make you go out of private IP space.

  2. I would definently say a hierarchy of routers because it allows you to have clearer configuration and enforce policies on a per-department basis. Cisco agrees with me in the CCNA :-)

3
  • Cisco would say that, they want to sell more routers ;-)
    – Alnitak
    May 25, 2009 at 8:03
  • Well a hierarchy of routers implies buying a router per departement plus a core router instead of just a core router, so that's consistent but they found just a way to make it less flashy :P May 25, 2009 at 8:20
  • Cisco has a notion that they call stacking, which effectively does share MAC tables. In fact, depending on your model of switch (such as the lower level 3750) the switching backplane is shared amongst the entire stack. Meaning your packet goes out to the stack even on the local switch. As opposed to the pricier equipment where your packet only hits the stack when moving from one switch to another. en.wikipedia.org/wiki/Stackable_switch
    – Scott Pack
    May 25, 2009 at 11:04
1

Your question is long, I am going to address this part.

Which is more architecturally sound: one core router joining many subnets to the Internet or a hierarchy of routers (one per department uplinking to the core)? Or, is it best to give each department a router and then mesh them together into a mini-internet?

Most routers can implement some kind of firewalling. Since switches are layer 2 devices you usually don't do any kind of filtering there. If you need to separate departments for some kind of security, or if you need to implement a different firewall policy for that department it will be easier to enforce this if they are on a separate subnet.

What is the largest IP address space that can be effectively handled using only a switched network, and at what point should you consider breaking the network into multiple segments joined by a router?

In a hubbed network you are limited to 1024 devices in your collision domain. Even though this no longer technically applies in a switched network I generally try to stick to that as top limit of how many devices I put on a single subnet.

You also may want break up your networks with routers if you are using a protocol that does lots of broadcasting. Broadcasts are normally not passed by a router.


Citation for 1024 device limitation.

Ethernet: The Definitive Guide 3.6 Collision Domain (google books link)

On a given Ethernet composed of multiple segments connected with repeaters, all of the stations are involved in the same collision domain. The collision algorithm is limited to 1024 distinct backoff times. Therefore, the maximum number of stations allowed in the standard for a multi-segment LAN linked with repeaters is 1024. However, that doesn't limit your site to 1024 stations, because Ethernets can be connected together with packet switching devices such as switching hubs or routers.

2
  • 2
    "In a hubbed network you are limited to 1024 devices in your collision domain." - [Citation Needed] May 25, 2009 at 10:36
  • HPC environments usually (atleast in Rocks) have all nodes on the same segment. I've had 1800 servers on the same subnet - no problem at all. May 25, 2009 at 11:20
0

For your second question, see When/why to start subnetting a network?

0

When you uplink one switch into another, do they share mac address tables? Or is this a vendor specific function? If they don't share, how do they handle packets addressed to macs they don't directly control?

Generally stacks share a table between the members (eg, Juniper's "Virtual Chassis"), as they often have redundent paths, and a standard table can't work.

Otherwise each switch needs their own table, although through protocols like CDP and LLDP they can get more information from their neighbour.

What is the largest IP address space that can be effectively handled using only a switched network, and at what point should you consider breaking the network into multiple segments joined by a router?

If security's not an issue, then it simply comes down to broadcasts. Desktops (and laptops) tend to be chatty, so there's noticable broadcast traffic at only a few hundred machines. Well managed servers (eg, arp expiry extended into hours) add almost no broadcast load, so limits on your edge router throughput might be the limiting factor. For low traffic servers (or an exceptional network) many thousands of servers could easily be on the same broadcast domain.

Which is more architecturally sound: one core router joining many subnets to the Internet or a hierarchy of routers (one per department uplinking to the core)? Or, is it best to give each department a router and then mesh them together into a mini-internet?

Both are valid views, however in these days of Layer-3 switches that run OSPF I tend towards the second.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .