In bold below. Jason Boyers, CCIE #26024 (Wireless) Blog: netboyers.wordpress.com
On Wed, Mar 5, 2014 at 3:57 PM, Sreejith Kuruppu <[email protected]>wrote: > Hi Jeff; > > Thanks for the reply. I have viewed your videos and it was > very nice as it was more related to the practical sessions. Please find my > queries inline > > > 1. In HSRP configuration , preempt is configured for secondary router > also. Is it required ? > > In a 2 switch setup, preempt is never needed on the secondary switch for > what we need to worry about. It would only come into play if we were doing > tracking, which is too deep for the wireless lab in my opinion. > > > If we are configuring preempt in both switches will it be considered as > over configuration. I am confused as in Lab1 solutions preempt is > configured on both switches. > > *Overconfiguring in the lab, unless specifically denied, is allowed. Of > course, overconfiguring can often break other things, so be careful > (general statement - not specifically about HSRP).* > > > 2. While configuring DHCP we split down the DHCP pool and configured in > both switches. Is it required to split the DHCP pool or we can configure > the complete pool in both switches. Since the HSRP is configured it will > always take it from the active router ? > > It is not required to split the DHCP pool between the switches. But if > you have the same range on both, you increase your chance of duplicate IPs. > The switches do a check prior to handing out an IP, but it's not > fool-proof. > > Any switch that receives the DHCP request should respond. So a > broadcasted request would be received and responded to by both switches. A > directed broadcast (maybe coming from a client through a WLC), would only > be received by the switch that it was sent to. > > > For example i have a subnet 10.10.12.0/24. and the virtual ip is > 10.10.12.1. In the WLC i have configured the primary DHCP server as > 10.10.12.1. In this case only the active router will respond correct and > the standby router will not respond. Please correct me if i am wrong. If > my assumption is correct then we can replicate the same pool to both > switches correct. > > > Why i am saying is if we are splitting the DHCP pool then each pool will > serve only 128 IP's at a time. So if Cisco expecting all 254 IP's then we > are wrong. isnt it. > > *In the scenario you are describing, you are using the DHCP proxy feature > of the controller, which is passing the DHCP request as a unicast to a > single IP address. Because one switch would be primary for HSRP, it would > be the one to respond. If you turned off DHCP proxy and just passed > through the DHCP requests, then both switches would respond, since both are > on that same network with pools in that network. The first one that the > client receives is the one that they would use. The other would not be > used and would be available for another client.* > > > 3. In QOS section, dscp is configured in the trunk links as well. Is it a > typing error? > > It doesn't explicitly say what to trust for any given port. It just says > to trust layer2/3 markings where appropriate. On switch to switch links, > you could trust either CoS or DSCP. I prefer DSCP myself if given the > option. If you trust CoS, be careful about native VLANs. You will lose > all QoS markings on a native VLAN when you trust CoS (since it doesn't have > an 802.1q tag). > > > I am confused. > > Could you please give me a hint the question pattern in the following > cases > > 1. Where we should use DSCP completely. > > 2. Where we should use CoS completely > > 3. Based on which question we should use the combination of CoS and DSCP. > > *Unless specifically indicated, Cisco best practice is to trust DSCP on > switch to switch connections. This maintains the value that has already > been set at ingress. Say, for instance, that you had a switch that trusted > DSCP values from end devices. If one had packets that were marked with > AF41, and another with CS4, both would have a CoS value of 4 (by default > mapping) across the link to the next switch. At the second switch, if we > just trust CoS, both packets would now be marked with CS4. Therefore, we > no longer have end-to-end QoS, but hop-by-hop QoS.* > > > 4. In QOS section the access list for marking is general. its for any any > with ports. Is it fine or we need to be specific with the source and > destination. > > It comes down to how the requirements are worded. It didn't actually say > voice traffic from the voice subnet in the MO. Just generic voice traffic > and no subnets or VLANs were mentioned. So in this instance, we can't > really call out IP ranges in our ACLs. But one change that I would make is > in the RTP ACL. It currently reads this. > > permit udp any any range 16384 32767 > permit udp any range 16384 32767 any > > I would change it to this. > > permit udp any range 16384 32767 any range 16384 32767 > > You generally should try to be as specific as you can. If they mentions > specific subnets/hosts, I would absolutely include those in my ACLs. > > > > Got it. > > > 5. In Autonomous section why we have configured the other groups. We need > only rad_group correct ? > > Those other groups get added automatically if you use the GUI to add in > the RADIUS server. The only group needed for the solution was the > rad_group one that you mentioned. > > > > does it required > > aaa group server radius rad_eap > server 10.10.110.100 auth-port 1812 acct-port 1813 > ! > > aaa authentication login eap_methods group rad_eap > > > aaa authentication login mac_methods local does it required > > aaa authorization exec default local does it required > > > > aaa accounting network acct_methods start-stop group > rad_acct does it required > > > ip radius source-interface BVI1 > radius-server local > no authentication leap > no authentication mac > nas 10.10.110.100 key 7 08285C4B1109000506 > user crane nthash 7 > 06202D721C1B2D49523130532E537D7A01791567034B54475658040D0877712C52 > > ! > radius-server attribute 32 include-in-access-req format %h does it > required > > > radius-server host 10.10.110.100 auth-port 1812 acct-port 1813 key 7 > 000D03031C4B0E141B Confused with this command as we already mentioned > the radius server in rad_eap and radius server local. > > radius-server vsa send accounting does it required > *I would suggest studying the various AAA commands a lot more. The "radius-server host" command, towards the end, configures the system to be able to connect to the RADIUS server on the specified ports using the specified key. When it is listed under the "radius-server local", it is saying that this device is acting as a RADIUS server using the specified IP address for the server, and that devices (including the local one) needs to connect to it using the specified key. At the top, the reference to the radius server simply says that the server is put into a specific server-group for mapping under the aaa authentication/authorization/accounting commands.* > > On Tue, Mar 4, 2014 at 11:28 PM, Jeff Rensink <[email protected]>wrote: > >> 1. In HSRP configuration , preempt is configured for secondary router >> also. Is it required ? >> >> In a 2 switch setup, preempt is never needed on the secondary switch for >> what we need to worry about. It would only come into play if we were doing >> tracking, which is too deep for the wireless lab in my opinion. >> >> 2. While configuring DHCP we split down the DHCP pool and configured in >> both switches. Is it required to split the DHCP pool or we can configure >> the complete pool in both switches. Since the HSRP is configured it will >> always take it from the active router ? >> >> It is not required to split the DHCP pool between the switches. But if >> you have the same range on both, you increase your chance of duplicate IPs. >> The switches do a check prior to handing out an IP, but it's not >> fool-proof. >> >> Any switch that receives the DHCP request should respond. So a >> broadcasted request would be received and responded to by both switches. A >> directed broadcast (maybe coming from a client through a WLC), would only >> be received by the switch that it was sent to. >> >> >> 3. In QOS section, dscp is configured in the trunk links as well. Is it a >> typing error? >> >> It doesn't explicitly say what to trust for any given port. It just says >> to trust layer2/3 markings where appropriate. On switch to switch links, >> you could trust either CoS or DSCP. I prefer DSCP myself if given the >> option. If you trust CoS, be careful about native VLANs. You will lose >> all QoS markings on a native VLAN when you trust CoS (since it doesn't have >> an 802.1q tag). >> >> 4. In QOS section the access list for marking is general. its for any any >> with ports. Is it fine or we need to be specific with the source and >> destination. >> >> It comes down to how the requirements are worded. It didn't actually say >> voice traffic from the voice subnet in the MO. Just generic voice traffic >> and no subnets or VLANs were mentioned. So in this instance, we can't >> really call out IP ranges in our ACLs. But one change that I would make is >> in the RTP ACL. It currently reads this. >> >> permit udp any any range 16384 32767 >> permit udp any range 16384 32767 any >> >> I would change it to this. >> >> permit udp any range 16384 32767 any range 16384 32767 >> >> You generally should try to be as specific as you can. If they mentions >> specific subnets/hosts, I would absolutely include those in my ACLs. >> >> 5. In Autonomous section why we have configured the other groups. We need >> only rad_group correct ? >> >> Those other groups get added automatically if you use the GUI to add in >> the RADIUS server. The only group needed for the solution was the >> rad_group one that you mentioned. >> >> Regards, >> >> >> >> Jeff Rensink : Sr Instructor : iPexpert <http://www.ipexpert.com/> >> >> CCIE # 24834 :: Wireless / R&S >> >> :: World-Class Cisco Certification Training >> >> Direct: +1.810.326.1444 >> >> :: Free Videos <http://www.youtube.com/ipexpertinc> >> >> :: Free Training / Product Offerings <http://www.facebook.com/ipexpert> >> >> :: CCIE Blog <http://blog.ipexpert.com/> >> :: Twitter <http://www.twitter.com/ipexpert> >> >> >> On Tue, Mar 4, 2014 at 11:31 AM, Sreejith Kuruppu >> <[email protected]>wrote: >> >>> Hi Team; >>> >>> I have some doubts while going through Lab1. Could you >>> please help in clearing those. >>> >>> 1. In HSRP configuration , preempt is configured for secondary router >>> also. Is it required ? >>> >>> 2. While configuring DHCP we split down the DHCP pool and configured in >>> both switches. Is it required to split the DHCP pool or we can configure >>> the complete pool in both switches. Since the HSRP is configured it will >>> always take it from the active router ? >>> >>> >>> 3. In QOS section, dscp is configured in the trunk links as well. Is it >>> a typing error? >>> >>> 4. In QOS section the access list for marking is general. its for any >>> any with ports. Is it fine or we need to be specific with the source and >>> destination. >>> >>> 5. In Autonomous section why we have configured the other groups. We >>> need only rad_group correct ? >>> >>> >>> Thanks & Regards >>> Sreejith R >>> >>> _______________________________________________ >>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>> >>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>> >> >> > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc >
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
