MAC layer unicast flooding a switched networkconnecting a switch behind a MAC Address filtering routerMAC address flappingSwitch Floods Packets that should be UnicastShould the MAC Tables on a switch Stack be the same between sessions?Misunderstanding about packet travel over NLB-NetworkJuniper networks mac addresses of switches in a LANmultiple subnets on the same switch(es), how can I isolate it?HP ProCurve 2920, MAC filterLinux bonding (balance-tlb), KVM guests and L2 switches = unicast flooding?Layer 2 vs Layer 3 switches
Why isn't Tyrion mentioned in 'A song of Ice and Fire'?
Do copyright notices need to be placed at the beginning of a file?
shell script is not executed after adding it as a crontab job
One word for 'the thing that attracts me'?
Is there a simple example that empirical evidence is misleading?
Is it legal to have an abortion in another state or abroad?
Is "vegetable base" a common term in English?
Why do the i8080 I/O instructions take a byte-sized operand to determine the port?
Why does Bran want to find Drogon?
Why did it take so long for Germany to allow electric scooters / e-rollers on the roads?
Co-author wants to put their current funding source in the acknowledgements section because they edited the paper
Cardio work for Muay Thai fighters
Can you still travel to America on the ESTA waiver program if you have been to Iran in transit?
Burned out due to current job, Can I take a week of vacation between jobs?
Shorten or merge multiple lines of `&> /dev/null &`
How to let other coworkers know that I don't share my coworker's political views?
Expected maximum number of unpaired socks
How did the Unsullied find out that Jon did this?
If I arrive in the UK, and then head to mainland Europe, does my Schengen visa 90 day limit start when I arrived in the UK, or mainland Europe?
How to melt snow without fire or using body heat?
Why did Jon Snow do this immoral act if he is so honorable?
Gravitational Force Between Numbers
Why is this integration method not valid?
Interpreation ROC AUC score
MAC layer unicast flooding a switched network
connecting a switch behind a MAC Address filtering routerMAC address flappingSwitch Floods Packets that should be UnicastShould the MAC Tables on a switch Stack be the same between sessions?Misunderstanding about packet travel over NLB-NetworkJuniper networks mac addresses of switches in a LANmultiple subnets on the same switch(es), how can I isolate it?HP ProCurve 2920, MAC filterLinux bonding (balance-tlb), KVM guests and L2 switches = unicast flooding?Layer 2 vs Layer 3 switches
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
The network in question:
It is a fully switched network with no routing. There is no known RSPT problems.
There are 10 small switches. Each small switch has many small industrial devices talking to each other within that small switch.
There is 1 big switch that connects to all 10 small switches. The big switch also connect to computers that occasionally talk to a device or two in one of the small-switch network.
the entire network is one giant IP network with the same subnet, subnet mask, no default gateway.
The problem:
2 small switches, one has device A connected, the other has device B connected. unfortunately, A and B both has the same Mac address, a strange Mac address as well: 00:ba:d0:0b:ad:00 "bad bad"
Now, after wireshark a computer connected to the big switch, I can see the traffics of devices talking to A or devices talking to B, which should be confined within their small switches:
Ethernet II, Src: GeFanucA_02:9f:d0 (00:09:91:02:9f:d0), Dst: 00:ba:d0:0b:ad:00 (00:ba:d0:0b:ad:00)
It is also observed that, packet from "bad bad" to GeFanucA_02:9f:d0 (00:09:91:02:9f:d0) is a normal unicast and "bad bad" can recieve it. So in the two way communication, only one way's traffic is flooded, the other way is still unicast.
Question:
The reason for unicast flooding is due to small switch realizing the MAC address is "bad"? or it is due to duplicated mac address so that small switches are not quite sure where to send the frame, so it just broadcasted? Or is this flooding due to something else?
PS.
after Joeqwerty's answer below, confirming that, duplicated mac address has caused the flooding, I went back to all small switches and look at their "Mac Address Table". Apparently there are 3 devices sharing the same MAC address, A B and C. Apparently C's small switch happily accepted "BAD BAD" mac address and kept the traffic unicast. A and B's switches decided to flood.
What exact mechanism caused this? A and B's switches should NOT be aware of any "BAD BAD" on another switch.
switch flooding unicast
asked May 7 at 18:24
ugnugn
164
add a comment |
The network in question:
It is a fully switched network with no routing. There is no known RSPT problems.
There are 10 small switches. Each small switch has many small industrial devices talking to each other within that small switch.
There is 1 big switch that connects to all 10 small switches. The big switch also connect to computers that occasionally talk to a device or two in one of the small-switch network.
the entire network is one giant IP network with the same subnet, subnet mask, no default gateway.
The problem:
2 small switches, one has device A connected, the other has device B connected. unfortunately, A and B both has the same Mac address, a strange Mac address as well: 00:ba:d0:0b:ad:00 "bad bad"
Now, after wireshark a computer connected to the big switch, I can see the traffics of devices talking to A or devices talking to B, which should be confined within their small switches:
Ethernet II, Src: GeFanucA_02:9f:d0 (00:09:91:02:9f:d0), Dst: 00:ba:d0:0b:ad:00 (00:ba:d0:0b:ad:00)
It is also observed that, packet from "bad bad" to GeFanucA_02:9f:d0 (00:09:91:02:9f:d0) is a normal unicast and "bad bad" can recieve it. So in the two way communication, only one way's traffic is flooded, the other way is still unicast.
Question:
The reason for unicast flooding is due to small switch realizing the MAC address is "bad"? or it is due to duplicated mac address so that small switches are not quite sure where to send the frame, so it just broadcasted? Or is this flooding due to something else?
PS.
after Joeqwerty's answer below, confirming that, duplicated mac address has caused the flooding, I went back to all small switches and look at their "Mac Address Table". Apparently there are 3 devices sharing the same MAC address, A B and C. Apparently C's small switch happily accepted "BAD BAD" mac address and kept the traffic unicast. A and B's switches decided to flood.
What exact mechanism caused this? A and B's switches should NOT be aware of any "BAD BAD" on another switch.
switch flooding unicast
asked May 7 at 18:24
ugnugn
164
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16
add a comment |
The network in question:
It is a fully switched network with no routing. There is no known RSPT problems.
There are 10 small switches. Each small switch has many small industrial devices talking to each other within that small switch.
There is 1 big switch that connects to all 10 small switches. The big switch also connect to computers that occasionally talk to a device or two in one of the small-switch network.
the entire network is one giant IP network with the same subnet, subnet mask, no default gateway.
The problem:
2 small switches, one has device A connected, the other has device B connected. unfortunately, A and B both has the same Mac address, a strange Mac address as well: 00:ba:d0:0b:ad:00 "bad bad"
Now, after wireshark a computer connected to the big switch, I can see the traffics of devices talking to A or devices talking to B, which should be confined within their small switches:
Ethernet II, Src: GeFanucA_02:9f:d0 (00:09:91:02:9f:d0), Dst: 00:ba:d0:0b:ad:00 (00:ba:d0:0b:ad:00)
It is also observed that, packet from "bad bad" to GeFanucA_02:9f:d0 (00:09:91:02:9f:d0) is a normal unicast and "bad bad" can recieve it. So in the two way communication, only one way's traffic is flooded, the other way is still unicast.
Question:
The reason for unicast flooding is due to small switch realizing the MAC address is "bad"? or it is due to duplicated mac address so that small switches are not quite sure where to send the frame, so it just broadcasted? Or is this flooding due to something else?
PS.
after Joeqwerty's answer below, confirming that, duplicated mac address has caused the flooding, I went back to all small switches and look at their "Mac Address Table". Apparently there are 3 devices sharing the same MAC address, A B and C. Apparently C's small switch happily accepted "BAD BAD" mac address and kept the traffic unicast. A and B's switches decided to flood.
What exact mechanism caused this? A and B's switches should NOT be aware of any "BAD BAD" on another switch.
switch flooding unicast
asked May 7 at 18:24
ugnugn
164
The network in question:
It is a fully switched network with no routing. There is no known RSPT problems.
There are 10 small switches. Each small switch has many small industrial devices talking to each other within that small switch.
There is 1 big switch that connects to all 10 small switches. The big switch also connect to computers that occasionally talk to a device or two in one of the small-switch network.
the entire network is one giant IP network with the same subnet, subnet mask, no default gateway.
The problem:
2 small switches, one has device A connected, the other has device B connected. unfortunately, A and B both has the same Mac address, a strange Mac address as well: 00:ba:d0:0b:ad:00 "bad bad"
Now, after wireshark a computer connected to the big switch, I can see the traffics of devices talking to A or devices talking to B, which should be confined within their small switches:
Ethernet II, Src: GeFanucA_02:9f:d0 (00:09:91:02:9f:d0), Dst: 00:ba:d0:0b:ad:00 (00:ba:d0:0b:ad:00)
It is also observed that, packet from "bad bad" to GeFanucA_02:9f:d0 (00:09:91:02:9f:d0) is a normal unicast and "bad bad" can recieve it. So in the two way communication, only one way's traffic is flooded, the other way is still unicast.
Question:
The reason for unicast flooding is due to small switch realizing the MAC address is "bad"? or it is due to duplicated mac address so that small switches are not quite sure where to send the frame, so it just broadcasted? Or is this flooding due to something else?
PS.
after Joeqwerty's answer below, confirming that, duplicated mac address has caused the flooding, I went back to all small switches and look at their "Mac Address Table". Apparently there are 3 devices sharing the same MAC address, A B and C. Apparently C's small switch happily accepted "BAD BAD" mac address and kept the traffic unicast. A and B's switches decided to flood.
What exact mechanism caused this? A and B's switches should NOT be aware of any "BAD BAD" on another switch.
switch flooding unicast
switch flooding unicast
asked May 7 at 18:24
ugnugn
164
asked May 7 at 18:24
ugnugn
164
edited May 9 at 20:24
ugn
asked May 7 at 18:24
ugnugn
164
asked May 7 at 18:24
ugnugn
164
asked May 7 at 18:24
ugnugn
164
164
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16
add a comment |
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16
add a comment |
1 Answer
1
active
oldest
votes
As you correctly surmised, this is flooding, not broadcasting. If two devices have the same MAC address then I would expect to see this happening. You need to remove these two devices from the network and figure out why they have duplicate MAC addresses.
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
|
show 4 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f966240%2fmac-layer-unicast-flooding-a-switched-network%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As you correctly surmised, this is flooding, not broadcasting. If two devices have the same MAC address then I would expect to see this happening. You need to remove these two devices from the network and figure out why they have duplicate MAC addresses.
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
|
show 4 more comments
As you correctly surmised, this is flooding, not broadcasting. If two devices have the same MAC address then I would expect to see this happening. You need to remove these two devices from the network and figure out why they have duplicate MAC addresses.
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
|
show 4 more comments
As you correctly surmised, this is flooding, not broadcasting. If two devices have the same MAC address then I would expect to see this happening. You need to remove these two devices from the network and figure out why they have duplicate MAC addresses.
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
As you correctly surmised, this is flooding, not broadcasting. If two devices have the same MAC address then I would expect to see this happening. You need to remove these two devices from the network and figure out why they have duplicate MAC addresses.
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
answered May 7 at 18:29
joeqwertyjoeqwerty
97.3k465149
97.3k465149
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
|
show 4 more comments
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
Thank you, just to confirm, "bad: bad" mac address will NOT register in any switch as invalid or unknown. So, if only one of A or B is removed, the flooding should stop.
– ugn
May 7 at 18:35
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
It should, but you should investigate both devices to figure out why they are doing this.
– joeqwerty
May 7 at 18:46
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
Thanks, shamefully, we do know the reason, someone didn't configure them properly, the device manufacture had the precient to alert to users that the device not configured properly by giving "bad bad" mac address to those devices. I just did not know Mac duplication could cause flooding.
– ugn
May 7 at 19:07
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
just to follow up, what's the exact mechanism that caused A's switch and B's switch to NOT learn their local "bad bad" MAC? because C's switch learnt C's "bad bad" MAC. Does STP has anything to do with this?
– ugn
May 8 at 15:54
1
1
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
just a personal note that, it is not that your answer is not correct for what I have stated. it is more because I didn't state the whole thing.
– ugn
May 10 at 0:25
|
show 4 more comments
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f966240%2fmac-layer-unicast-flooding-a-switched-network%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
problem not fully resolved, please feel free to comment or answer.
– ugn
May 8 at 16:16