Thanks for your video explanation on the CCENT level and nice touch to bring in real world examples with this. Just curious how did he create a loop by plugging in a switch to the conference room port to cause the problem. So no STP configured?
STP is configured/enabled by default. When you connect a cable from the wall port to the switch, you are good to go, but when you run another line back to the wall port, that's when things got ugly. It was an easy issue to resolve. The BPDU from the switch that connects to the wall port is seen by the conf. room switch and then shipped back out to the wall port. The switchport that connected to the other open wall port was set to access in the same VLAN, there was a MAC FLAP that was generated and traffic went down, effectively looping the traffic.
So by deploying VxLAN solution to the distribution layer, the distribution switches does not need to go to the core for distribution switches to communicate from one to another. So only traffic that needs to go to the core will go, otherwise they will stay on the distribution level and below?
The idea with VXLAN is tunnel traffic from distro switch to distro switch over the core without the core having to learn the layer 2 information. It makes the distro switches appear directly connected to each other. If you have a large Layer 2 domain, VXLAN cab be used to hide the network. Think of the core as a LAN cloud that should only be used to forward traffic between distro switches. The core shouldn't learn anything about the access layer at all. Traditional router/switching it does learn about the access, VXLAN can be used to hide the access from the core. I plan on covering VXLAN in CCNP/CCIE so stay tuned for that.
Would you say that implementing VxLan (so that distribution switches talk to another without going up to the core switches or learning anything about the switches in the access layer) is a security practice? ....What are the benefits of implementing VxLAN?
Have businesses by shocked to find that they have been running on the backup / redundant core switch or access layer routing and / or switching due to failure? Assuming everything was "A ok" until a net network or sys admin checked the network health and performance?
Based on the second architecture the collapsed core layer is layer 3 switch, is that layer 3 switch able to go through internet? I have this question is because the switch suppose to use for LAN and router is for WAN.
Totally, today's larger switch platforms can totally do that. I wouldn't put a 3550 on the internet edge, not a good place for it, better to use it in the LAN. A 6500 or 4500, much better on the internet edge.
I have another question that just popped in my head. So in a 3 layer architecture where there is Access, Distribution, and Core layer switches. We have computer A connected to Access switch A then connected to Distribution switch A. Then We have computer B connected to Access switch B then connected to Distribution switch B. When computer A communicates to computer B, it'll go over the distribution layer A and B switches and down to Access switch B then to computer B. My question is how does the packet know to not travel to the Core switches and back down to the distribution switches and then Access switch to communicate to computer B?
Assuming that Computer A and B are in the same VLAN, the MAC address table and Spanning Tree Protocol will come into play. Ethernet, regardless of the switch, is a flood and learn technology. The Core will still know about the MAC address via ARP, but since A knows it's destination is B, The switching environment knows where B exists. So based on STP cost and where the MAC for B was learned, the switches know to forward traffic from A to B, the traffic needs to follow the Access A to Distribution A to Distribution B to Access B to Computer B. If A and B are not on the same VLAN, then the Core will get involved, but the destination MAC will be the SVI MAC or the FHRP MAC (HSRP) and the core will receive the traffic, route it to the outgoing interface, rebuild the layer 2 header and send down to Computer B. The reverse happens from B to A. HTH!
Thanks for the super clear explaination Rob. It'll be interesting to see your video when you explain VxLAN when Computer A and B are on different VLANs.
How was this unstructured? The video covered different architectures, which was the point of the video. Did you have difficulty following along due to a lack of understanding on something? If so, I'd be happy to clarify anything for you.
I agree with you on the ahead part, I probably shouldn't have gone down the VxLAN part but the point was to show how it could be used. Since its a newer technology, I thought it may have some relevance. I definitely don't know too much, I have been fortunate to be exposed to many networks and deployments, its humbling to see what other engineers have designed and deployed. Always gotta stay on your toes!
Great video. Especially on the practical app, scalability $$$ side.
Glad you liked it man!
thanks for the real world situations. ur good at that
Thanks for your video explanation on the CCENT level and nice touch to bring in real world examples with this. Just curious how did he create a loop by plugging in a switch to the conference room port to cause the problem. So no STP configured?
STP is configured/enabled by default. When you connect a cable from the wall port to the switch, you are good to go, but when you run another line back to the wall port, that's when things got ugly. It was an easy issue to resolve. The BPDU from the switch that connects to the wall port is seen by the conf. room switch and then shipped back out to the wall port. The switchport that connected to the other open wall port was set to access in the same VLAN, there was a MAC FLAP that was generated and traffic went down, effectively looping the traffic.
So by deploying VxLAN solution to the distribution layer, the distribution switches does not need to go to the core for distribution switches to communicate from one to another. So only traffic that needs to go to the core will go, otherwise they will stay on the distribution level and below?
The idea with VXLAN is tunnel traffic from distro switch to distro switch over the core without the core having to learn the layer 2 information. It makes the distro switches appear directly connected to each other. If you have a large Layer 2 domain, VXLAN cab be used to hide the network. Think of the core as a LAN cloud that should only be used to forward traffic between distro switches. The core shouldn't learn anything about the access layer at all. Traditional router/switching it does learn about the access, VXLAN can be used to hide the access from the core. I plan on covering VXLAN in CCNP/CCIE so stay tuned for that.
Would you say that implementing VxLan (so that distribution switches talk to another without going up to the core switches or learning anything about the switches in the access layer) is a security practice? ....What are the benefits of implementing VxLAN?
Have businesses by shocked to find that they have been running on the backup / redundant core switch or access layer routing and / or switching due to failure? Assuming everything was "A ok" until a net network or sys admin checked the network health and performance?
Based on the second architecture the collapsed core layer is layer 3 switch, is that layer 3 switch able to go through internet? I have this question is because the switch suppose to use for LAN and router is for WAN.
Totally, today's larger switch platforms can totally do that. I wouldn't put a 3550 on the internet edge, not a good place for it, better to use it in the LAN. A 6500 or 4500, much better on the internet edge.
I have another question that just popped in my head. So in a 3 layer architecture where there is Access, Distribution, and Core layer switches. We have computer A connected to Access switch A then connected to Distribution switch A. Then We have computer B connected to Access switch B then connected to Distribution switch B. When computer A communicates to computer B, it'll go over the distribution layer A and B switches and down to Access switch B then to computer B. My question is how does the packet know to not travel to the Core switches and back down to the distribution switches and then Access switch to communicate to computer B?
Assuming that Computer A and B are in the same VLAN, the MAC address table and Spanning Tree Protocol will come into play. Ethernet, regardless of the switch, is a flood and learn technology. The Core will still know about the MAC address via ARP, but since A knows it's destination is B, The switching environment knows where B exists. So based on STP cost and where the MAC for B was learned, the switches know to forward traffic from A to B, the traffic needs to follow the Access A to Distribution A to Distribution B to Access B to Computer B.
If A and B are not on the same VLAN, then the Core will get involved, but the destination MAC will be the SVI MAC or the FHRP MAC (HSRP) and the core will receive the traffic, route it to the outgoing interface, rebuild the layer 2 header and send down to Computer B. The reverse happens from B to A.
HTH!
Thanks for the super clear explaination Rob. It'll be interesting to see your video when you explain VxLAN when Computer A and B are on different VLANs.
Sorry but I had to give up. Completely unstructured presentation and therefore lacks a proper flow.
How was this unstructured? The video covered different architectures, which was the point of the video. Did you have difficulty following along due to a lack of understanding on something? If so, I'd be happy to clarify anything for you.
You should stick to your guns. You run way ahead of yourself. What you know & understand, others may not. You are good but you know too much.
I agree with you on the ahead part, I probably shouldn't have gone down the VxLAN part but the point was to show how it could be used. Since its a newer technology, I thought it may have some relevance. I definitely don't know too much, I have been fortunate to be exposed to many networks and deployments, its humbling to see what other engineers have designed and deployed. Always gotta stay on your toes!