To expand upon Ronnie's answer, you can technically do either.
For non-Cisco phones on non-Cisco switches, if there is no option of Voice VLAN on the switch, the switchports would be configured as trunks (or 'general' ports), with the data VLAN set as native/PVID and then have the voice VLAN tagged/trunked to the phone. In the end, that is what the phone cares about, assuming it is split on to a different VLAN than the data traffic. So if data is on VLAN 1 and voice is on VLAN2, the port would be configured U1/T2.
The Voice VLAN function makes this a bit easier and essentially automates the process. Not only does it provide the same VLAN trunking functionality as above, but it also uses CDP/LLDP to tell the phone what VLAN it should be on. Without this, each phone would need to be manually configured for VLANs (which can by quite time consuming if you aren't otherwise provisioning them). It also simplifies the switch config since you don't need to worry about configuring every port as a trunk and excluding all the other VLANs off.
But to answer your question, in Voice VLAN mode, it isn't purely an access port, nor purely a trunk port. It's a special mode that functions a bit like a hybrid with added benefits. Hope that helps.
As someone who got their initial VCP (VCP5-DCV) back when they were "lifetime" certs and you simply opted, if you wanted to, to go for the newer versions after they came out, I was livid when I heard 5 or so years ago that they were changing this policy and expiring them after only 2-years. And if you didn't renew in that time, you had to start from scratch, including taking the overpriced official course. All in all, a pure money grab. But I digress...
Today I just saw this posted on Reddit, which was posted by VMware on their official YouTube channel:
While it doesn't look like this has gone into effect yet (the video says immediately, but the VMware MyLearn site doesn't reflect it as of now), it sounds like VMware got enough grief from the people they screwed over that they are doing a 180 and making the certs valid for life again, with renewing them "optional". Part of me wants to say thank you to them for this, but it should never have changed IMHO in the first place. Nonetheless, great news for all of us who either have or are working towards the VCP exam.
So I’ve been watching the CCNP SWITCH videos in preparation for taking the exam again to renew my CCNP R&S and came across a couple problems in the Etherchannel Protocols video.
When going over PAgP, there was a matrix graphic to illustrate the compatibility between On, Off, Auto and Desirable. The first thing I noticed was that the matrix had a discrepancy between Auto and On. On one side (Auto/On) it said it would work, whereas the other axis (On/Auto) said it would not work. I think this was a simple typo since the value and result would be the same either way. But the bigger issue was when Ronnie was going over it and he said that Auto on one side and On (Manual Etherchannel) on the other side would work. I am 99% certain that this is incorrect.
For the same reason why Auto/Auto won’t work, PAgP is a protocol that requires communication between the two devices to negotiate the channel group. Having one side set to statically On would not meet this requirement, and is why Desirable, which sends PAgP packets in an ‘active’ fashion, is required. In saying that this Auto/On would work, he said that this is a difference between PAgP and LACP, but again I don’t believe this is the case and, just like LACP’s Active/Passive, having the other side set to On or Off would not allow the protocol to bring up the LAG. Both sides needs to be set to a PAgP or LACP protocol and at least one has to be active/desirable.
You may want to edit the matrix graphic and modify that part so that it gives the correct information in case it confuses someone.
I haven’t had a chance to test and confirm my belief (hence my 99% comment), but it immediately caught me off guard based on what my understanding was, and I did some research on it which confirmed my assumption.
Outside of that, everything else looked good :). Keep up the great work. Thanks!
It's not a guarantee, and depends on the switch, but according to Cisco:
"Note that most modern switches including the Catalyst 2900 XL, 3500 XL, 2940, 2950, 2970, 3550, 3750, 4500/4000, 5000, and 6500/6000 series switches maintain L2 forwarding tables per VLAN."
It may occupy the same place in memory and share the same overall caps, but even if all the resources are exhausted, the switch should never allow cross-VLAN traffic as a result of an attack. Even if the CAM table is full, the VLAN assignment is still present.
With VLANs, the same risks would be applicable regarding your own native VLAN as it would be on a non-VLAN (e.g. non-managed switch) environment. You could look at it like a bunch of virtual switches inside of one, or multiple, physical switches. However, the inherent security benefits of utilizing VLANs to segregate traffic have their own security concerns, which is what I assume you are asking about.
Each VLAN should have it's own MAC table, so flooding one should not directly impact the other(s). With that said, it comes down to the implementation (good or bad) of the switch vendor. But the general rule is that what happens on one VLAN stays on one VLAN. Assuming the network is designed correctly, local traffic should not cross VLANs unless going through some network intermediary device (e.g. a router).
If you are able to connect to a trunk port, or are able to fool the switch into thinking you are a legitimate switch and can dynamically enable trunking, then you have a pretty large attack surface as you can then receive all broadcast traffic across all (or some, depending on configuration) of the VLANs. This is why it's important for a network admin to make sure dynamic trunking is disabled on all, especially access, ports. Don does a good job of explaining this in the Cisco videos.
But even on an access port, there are some attacks that could get you to circumvent the VLAN you are a member of. I've never personally seen this done in practice, but my understanding is that if you can craft packets in a way that corrupts the VLAN tagging being done, you can get your traffic to drop to the native VLAN for the trunking between switches. This is why it's best practice to set this to some unused blackhole network and put all of your important traffic (including device management) on to it's own separate, and trunked, VLAN.
Of course there are other ways a network admin can help mitigate risks on people connecting to access ports.
@enki Congrats :+1:
What was your study strategy?
I definitely used the ITProTV SWITCH training videos. I also used some of the Cisco training resources and setup some home labs for practice. Since it was switching, GNS3 could only do so much, but I had a couple old Catalyst switches I was able to play with for other stuff. Most of the generic stuff I was able to rely on previous work experience. Even though we rarely use Cisco switches in our client's production networks, many other vendors have similar CLI environments. I've setup countless VLANs, trunks, LAGs, STP, etc. so have a strong fundamental understanding of those concepts. Even with that, there were a few questions I really just guessed at. Combined with the issues mentioned above in one of the lab questions, I really thought I might have failed. I was astonished when I got 1000. I did that on my CCNA, but felt very confident that I knew all the stuff (plus had been CCNA certified twice before hand since 2000). I spent a LOT more time studying for the route, since it was a weakness in terms of experience, and got 9-something. Hopefully my luck continues for the TSHOOT exam. I took Cisco's TSHOOT simulator, since the format is very different compares to other exams, and it looks kind of fun. I got 4/4 right, but I imagine those are just basic 'how-to' type questions. I'm going to begin studying for that tomorrow and hope to sit for it sometime next month.
Technically both situations were 'off-site'. We initially setup the Sonicwall in our office, but the connectivity was always to the client's data center. We ran into the issue during initial setup, which magically fixed itself, and then re-occurred at the client's site but never worked properly there. In both cases, outside of a different IP address (which we obviously changed in the configs once it moved), everything else was identical. Even the carrier.
It's not an EIGRP issue because we weren't using EIGRP at the new site (since it's Sonicwall). While they are using EIGRP internally between the other sites, it wasn't really necessary since it's a simple hub and spoke topology with no redundant routes or connectivity.
I'm pretty sure that the underlying issue is with the Cisco router in the hub. I say this because, even though the VPN tunnel is up to the new site, and even though it routes traffic to/from those subnets without issue, the new site's subnets aren't showing up in the routing table and , as a result, aren't being distributed out via EIGRP.
Under normal circumstances, I would look into rebooting the hub router since the uptime was something crazy and it might just be a hang up. It's also running an older IOS, but they don't have a smartnet contract on it. But since this was a one-off project for a non-managed client, with a T&M rate, eventually we just did static routes on the other sites back to the hub and everything worked fine with that.
But it's one of those things that still bothers me and I would eventually like to figure out why it didn't work properly all the time. My assumption is just a glitch in something.
Here is a perfect example of my comment (just a few hours ago) about how the Cisco test simulators can be broken. In between that comment and now, I sat for my SWITCH exam. I have to be careful to stay within the scope of the NDA, but suffice it to say I was not very happy with one of the questions. It was a fairly complex multi-step simulation that required numerous things to be configured.
Long story short, after I was done doing everything I thought I needed to, I went to verify it was working probably. One thing was not according to the information presented. I tried troubleshooting, but came up empty. My options were limited since you don't get to really 'debug' anything. So I spent about 30mins going back and forth trying to get this last piece working. Redoing all of the commands and kicking myself thinking I missed something obvious. Eventually, and with much reluctance, I gave up. This was at almost the beginning of the exam. As a result, even though I moved on, my mind kept going back to the issue and trying to think if I missed something and what it could be. This was obviously disruptive for me since I stilled had 30 questions left to go. Eventually I took a breath and just pushed on.
Since labs can be a big portion of the exam score, I was concerned that I failed. Honestly, I felt it was 50/50 whether or not I passed, where normally I'm pretty confident. Fortunately I did not fail. In fact, I got 100% (still can't believe it). Which goes to show:
- The labs don't always work properly and can't be trusted.
- Even if they don't, you can still get the question correct if everything else is done correctly.
But I'm still upset over the whole thing.
On a somewhat related note, there were also quite a few obvious spelling issues. Overall, I think the QA on this exam was poor at best. On to TSHOOT!
Well as I mentioned, I have seen instances where certain commands are actually disabled on purpose. I imagine this is for Cisco to see if you know the other options. When I took the CCNA years ago, I ran into a similar issue trying to create an ACL. The standard method I always used didn't work and I was banging my head against the wall for 10 minutes, almost giving up, thinking I was crazy. Finally I tried a different method that did work and moved on. Not sure if this was on purpose or just a broken simulator. To the latter, I also agree that the SIMs are a bit wonky. Weird things happen that can be very frustrating. Especially when trying to validate your work.
But my earlier point was more regarding standard multiple choice questions than labs/sims. I have actually seen ones where NONE of the answers were valid (the question itself was badly worded and I reported it), but I've never seen one where it asked for a number of correct answers (e.g. 1, 2 or 3) and there were more correct available and you had to chose between them.