Destinova

I've been waiting to see if this one got resolved. Great news!

Ok so you've got a non-standards based iteration of VRRP that doesn't follow the protocol. Fair enough. In that case you might want to block it then, or use a standards-based L3 redundancy protocol that doesn't flood your network with multicast traffic.

Yes, but what destination? There are several reasons for multicast traffic, you need to find out the destination address before you can determine what it is being used for. Multicast addressing in many cases is reserved, so you can look up what service or protocol is using it. IPv4 Multicast Address Space Registry Blocking it with respect to VRRP is bad. You'll just cause all VRRP gateways to constantly believe they should be the active device because they will not be able to communicate with each other. Also, you can ping the multicast address and see what responds. A ping to 224.0.0.18 should return replies from any VRRP device.

From what source? Unless you are seeing it specifically to 224.0.0.18 using IP protocol 112, it isn't your VRRP devices.

VRRP doesn't use broadcast except for the initialization phase during which it sends a gratuitous ARP request containing the virtual router MAC address. Otherwise multicast is used between VRRP routers to multicast address 224.0.0.18 using IP protocol 112.

You're on track with the exception of the STP part. STP plays no role in VRRP operation. You do not want to disable the link to the backup router. Your layer 2 devices (switches) are forwarding traffic to a virtual MAC address (the layer 2 address of the virtual IP or default gateway), so absolutely nothing changes from a switching perspective if the primary router fails. The secondary router simply 'becomes' that L2 address. Your switches simply learn that MAC is on a different port and forward traffic accordingly. Some more info: RFC 3768 - Virtual Router Redundancy Protocol (VRRP) http://www.dell.com/downloads/global/products/pwcnt/en/app_note_32.pdf

They are a decent SMB managed switch. That being said you are limited to configuration via the web interface as these do not run the full Cisco IOS. If you don't require some advanced layer 2 features, these would be fine for general access closet switches.

This is a rather ignorant statement, in light of the fact that Keith Parsons is one of the most respected wireless professionals in North America and has probably forgotten more about 802.11 than anyone on these boards will ever know. The test was designed (as is mentioned in the first pages) to take all of these access points to their limit, to their breaking point. The point at which they stopped being able to service any clients. This, done using an example that we as edu professionals should all be well familiar with, a classroom full of tablets. If you think that 30 iPads streaming multicast video is not a real-world scenario, then you are behind the times.

The only way to do this is using 802.1x and machine authentication.

Untagged in the HP world means "native" or access in the Cisco world. So, on the Cisco side your port is access vlan 1 and native vlan 1, while on the HP side you are using vlan 113. This is why they aren't talking. You either need to make both sides access ports for the same vlan or trunk both sides and ensure they are using the same native vlan (recommended for interswitch links). (although it is best practice from a security perspective to use a native vlan that does not exist on any access port) Example: (Cisco) interface GigabitEthernet10/6 switchport switchport trunk encapsulation dot1q switchport mode trunk switchport trunk native vlan 113 spanning-tree mode point-to-point end (HP) vlan 113 untagged b21 (any other vlans that need to be carried across this trunk should be "tagged") vlan xxx tagged b21 vlan yyy tagged b21 Also, you need to ensure the Cisco switch is aware of the layer 2 vlan (113). 'Show vlan' will confirm this. The longer explanation here is that in the Cisco world creating a trunk port automatically carries all tagged (802.1Q) vlan traffic and will forward any untagged traffic to ports on the native vlan (1 by default). In the HP world you have to assign the native vlan (untagged, also 1 by default) and specify which vlans are to be carried across the trunk by "tagging" each.

Here is where I ran into issues with this survey: "Please rate how each configuration would negatively affect wireless security posture. * Default Device IP Address - What does this mean? Devices do not come with a default IP address. Disabled Encryption - Are you talking about using open authentication? You can have open authentication and still have encryption. Captive portal authentication using https for example. The traffic is encrypted, the wireless connection itself is not. Disabled MAC Filtering - This is not a single item that is simply on, or off. This is a potential additional security feature that can be layered with your choice of authentication and encryption methods. "Please rate the significance of the below measures in the context of improving wireless security." Firewall - What kind of firewall? Host firewalls? Access Point firewalls? Client isolation on an individual access point? Network firewalls? But my biggest issue comes with the question about encryption. Implementing Encryption (TKIP, LEAP, WPA) Only one of those three things is encryption - TKIP. WPA is a protocol, not encryption. (See 802.11i) LEAP is also a protocol, used for authentication, not encryption. It's also one of about 15 methods of EAP, and is proprietary to Cisco. See RFC 5247 - Extensible Authentication Protocol (EAP) Key Management Framework For example, one can use WPA and implement 802.1X, EAP and RADIUS for authentication, and TKIP for encryption. Smaller deployments or home networks may not use a strong authentication method and simply use PSK or pre-shared keys instead of 802.1X or EAP/RADIUS. WPA2, still a protocol, not encryption - can use all of the above authentication methods and also TKIP or AES for encryption. The key here is understanding the fundamental differences between authentication, and encryption (and associated encapsulation methods). If you are going to me a MSc in InfoSec, one would assume you should have some in depth knowledge of the standards protocols and methods used in a modern (wireless) network. Read some RFC's - they are boring as hell, but you'll learn more than you will from this survey.

A couple of points: This survey, at least to me, suggest the person who wrote the questions does not understand 802.11 or RF fundamentals at all, and this makes it difficult to answer. Also, your use of the WiFi Alliance logo is in violation of copyright/trademark.

Can you post a traceroute to both the router and firewall? Also, have you compare the routing tables on both? Do a "show interfaces counters errors" on the Cisco device, and look for CRC or Frame errors.

FYI Cisco bought Meraki. So your difference is this: Cisco is controller based, Meraki is "cloud" based. I would suggest in either case get some test/trial gear and try it out. Meraki gear is simpler to use out of the box and their management portal is fairly easy to use. If your VAR won't get you gear to try out, get a new VAR. I absolutely will not ever buy anything without using it hands-on. PKI isn't that difficult. Setting up a root CA within your domain and then using that for 802.1x authentication (wired or wireless) is not "easy" but it is fairly intuitive with a little reading and research. If you want a dead simple on-boarding process I'd have to say that Ruckus' Zero-IT Activation is excellent. Users register their own devices, are assigned a PSK (up to 63 characters, that they never see) and the device is automatically configured for the WLAN. BYOD Solution | Ruckus Wireless

Inter-vlan routing requires either: 1) A layer 3 switch with routing enabled and SVI's. 2) A router with subinterfaces (router on a stick).

Bad cable.

D-Link makes data centre products? (mind blown)

That's interesting. The Cisco EDU discount here (Canada) is fairly close to 40% off list price, depending on what gear you're looking at. Comparison on the Cisco/HP side (I sell both as a consultant) Cisco can get very close to HP pricing, but can't offer the 2-for-1 or 3-for-2 deals that they often have on their lower end L2 and L3 switches, which is usually the tipping point for anyone buying bulk.

Only the L2 vlan extends past the local switch. This is fine. Design and security suggests you want to avoid broadcast - this does that. If HP is ripping you off in the UK then look to Cisco. First, their gear is superior and their warranty now matches HP's completely. The only hope HP has ever had in the networking space has been on price, and if they aren't doing that for you, tell them to stuff it.

I'd make this the exception. Your APs are switches, treat them as such and connect via trunks using their own subnet (per SSID). That subnet doesn't change and exists as a L2 vlan on any switch connected to an AP. No access ports using this vlan, so broadcast isn't an issue and your AP's should limit client broadcasts anyway if it's decent gear.

It's actually fairly standard design, and you don't need an L3 switch in every cabinet. The L2 vlan only has to be present on the switch - it doesn't get assigned to any ports, just tagged across your trunks and pruned where necessary. Does that mean the vlan extends past the local switch? Technically perhaps, but the point being you have eliminated the broadcast issue which is the point. If you have L3 switches, great, use them, I'd say there's no point in buying L2 only switches these days anyway, the additional cost is minimal. Hell, HP is offering buy 2 get 1 free on their 2900 switches. Your L3 gateway can still be at your distribution layer - where it should be, not at your core, unless you are a smaller environment running a collapsed core in which case go right ahead.

Some would argue that your vlans should not extend past the local switch.

If you're serious about learning networking, get some gear. Hands-on work with the CLI beats any sim 100% of the time. GNS3 only does routers, not switches so you are going to want at least a 2900 series switch and they are dirt cheap. Plan to study the same way you would be working...and you won't be working with sims. With the new CCENT/CCNA make sure you get something that will run IOS 15.

Be advised the current CCENT and CCNA tracks are being retired. You have 6 months to pass the current blueprint or will be doing the new track.

WZC should be starting as a service when the machine loads. Anything in event viewer showing what might be broken with it?