{"id":22647,"date":"2026-09-26T06:48:37","date_gmt":"2026-09-26T06:48:37","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=22647"},"modified":"2026-09-26T06:48:37","modified_gmt":"2026-09-26T06:48:37","slug":"cisco-ccnp-300-425-practice-test-questions-and-exam-dumps-part7-q121-140","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cisco-ccnp-300-425-practice-test-questions-and-exam-dumps-part7-q121-140\/","title":{"rendered":"Cisco CCNP 300-425 Practice Test Questions and Exam Dumps Part7 Q121-140"},"content":{"rendered":"

View Full <\/b>Cisco CCNP 300-425 Exam Dumps<\/b><\/a> and Practice Test Dumps.<\/b><\/p>\n


\n<\/b>Question 121. What is the maximum number of controllers in one Catalyst 9800 mobility group<\/b><\/p>\n

    \n
  1. <\/b> 8<\/span><\/li>\n
  2. <\/b> 16<\/span><\/li>\n
  3. <\/b> 24<\/span><\/li>\n
  4. <\/b> 32<\/span><\/li>\n<\/ol>\n

    Correct Answer: 3. 24<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    A Catalyst 9800 mobility group supports up to 24 controllers. Cisco recommends avoiding unnecessarily large mobility groups even when the technical maximum permits them. Controllers should normally be grouped when their access points cover physical areas where clients can realistically roam between controllers. Keeping unrelated controllers in separate groups reduces the client, access point, and rogue information each controller must maintain. This can conserve processing and memory resources while making the mobility design easier to manage. A large enterprise with physically separated buildings can therefore use multiple mobility groups instead of placing every controller into one group.<\/span><\/p>\n

    Question 122. What should determine which controllers belong to one mobility group<\/b><\/p>\n

      \n
    1. <\/b> Areas where clients can physically roam<\/span><\/li>\n
    2. <\/b> Controller serial numbers<\/span><\/li>\n
    3. <\/b> Switch model<\/span><\/li>\n
    4. <\/b> DNS domain length<\/span><\/li>\n<\/ol>\n

      Correct Answer: 1. Areas where clients can physically roam<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      Cisco recommends placing controllers in the same mobility group when their access points serve areas through which clients can physically roam. For example, controllers serving one building or connected campus area often belong together because client context must move between them. Controllers serving distant locations with no realistic roaming path do not need to share one large mobility group. Limiting the group to meaningful roaming areas reduces unnecessary exchange and storage of client, rogue, and access point information. This design approach improves scalability and makes mobility relationships easier to understand and troubleshoot.<\/span><\/p>\n

      Question 123. What identifies an intercontroller Layer 2 roam on Catalyst 9800<\/b><\/p>\n

        \n
      1. <\/b> Different SSID names<\/span><\/li>\n
      2. <\/b> Different client IP addresses<\/span><\/li>\n
      3. <\/b> Different mobility groups<\/span><\/li>\n
      4. <\/b> Same client VLAN ID on both controllers<\/span><\/li>\n<\/ol>\n

        Correct Answer: 4. Same client VLAN ID on both controllers<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        On Catalyst 9800 controllers, intercontroller Layer 2 roaming occurs when the client VLAN ID associated with the WLAN is the same on both controllers. The controllers exchange mobility messages and move the client database entry to the new controller as the client roams. Cisco notes that the Layer 2 or Layer 3 roaming decision depends on the VLAN ID rather than directly on the IP subnet configured behind that VLAN. Designers must still make sure the wired network maps the same VLAN to the correct client subnet across both controller locations.<\/span><\/p>\n

        Question 124. What normally identifies an intercontroller Layer 3 roam<\/b><\/p>\n

          \n
        1. <\/b> Same AP name<\/span><\/li>\n
        2. <\/b> Different client VLAN IDs<\/span><\/li>\n
        3. <\/b> Same controller hostname<\/span><\/li>\n
        4. <\/b> Same switch port<\/span><\/li>\n<\/ol>\n

          Correct Answer: 2. Different client VLAN IDs<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          A Catalyst 9800 intercontroller Layer 3 roam occurs when the client moves to an access point on another controller and the WLAN maps to a different VLAN ID there. Instead of simply transferring the client database entry, the original controller retains an anchor entry and the new controller creates a foreign entry. Mobility tunneling allows the client to preserve its original network identity while operating through the new controller. The process is designed to remain transparent to the wireless client so applications can continue without requiring a new IP address.<\/span><\/p>\n

          Question 125. What happens to the client IP address during a Layer 3 roam<\/b><\/p>\n

            \n
          1. <\/b> It remains unchanged<\/span><\/li>\n
          2. <\/b> It always becomes an IPv6 address<\/span><\/li>\n
          3. <\/b> It changes to the controller address<\/span><\/li>\n
          4. <\/b> It is deleted<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. It remains unchanged<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            During an intercontroller Layer 3 roam, the wireless client keeps its original IP address. The original controller maintains the anchored client state while the new controller receives a foreign client entry. Mobility tunneling handles the data path so the client does not need to obtain an address from the new VLAN or subnet. Preserving the IP address is important for maintaining application sessions because many sessions would otherwise fail when the client moves between subnets. This behavior is one of the major benefits of Cisco controller mobility in large enterprise wireless designs.<\/span><\/p>\n

            Question 126. Which controller keeps the anchor entry during a Layer 3 roam<\/b><\/p>\n

              \n
            1. <\/b> New controller<\/span><\/li>\n
            2. <\/b> Backup controller<\/span><\/li>\n
            3. <\/b> Original controller<\/span><\/li>\n
            4. <\/b> DNS controller<\/span><\/li>\n<\/ol>\n

              Correct Answer: 3. Original controller<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              The original controller where the client was first connected keeps the anchor entry during an intercontroller Layer 3 roam. The client database information is also copied to the new controller, where the client is marked as foreign. The original controller remains the client’s IP point of presence while the new controller provides the current wireless attachment. This separation allows the client to maintain its original IP address and application sessions even though it has moved into an area served by another controller and a different client VLAN.<\/span><\/p>\n

              Question 127. What role does the new controller receive during a Layer 3 roam<\/b><\/p>\n

                \n
              1. <\/b> Anchor<\/span><\/li>\n
              2. <\/b> Foreign<\/span><\/li>\n
              3. <\/b> RF leader<\/span><\/li>\n
              4. <\/b> Primary DHCP server<\/span><\/li>\n<\/ol>\n

                Correct Answer: 2. Foreign<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                During an intercontroller Layer 3 roam, the new controller is treated as the foreign controller for that client. It provides the current wireless attachment through the access point the client has joined. The original controller remains the anchor and continues to provide the client’s original IP point of presence. Client information is copied to the foreign controller so the user can continue operating transparently. Mobility tunneling connects the two roles and allows the client to retain its original address even though its physical wireless attachment has moved.<\/span><\/p>\n

                Question 128. Which UDP ports must be allowed between Catalyst 9800 mobility peers on different subnets<\/b><\/p>\n

                  \n
                1. <\/b> 67 and 68<\/span><\/li>\n
                2. <\/b> 1812 and 1813<\/span><\/li>\n
                3. <\/b> 5246 and 5247<\/span><\/li>\n
                4. <\/b> 16666 and 16667<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 4. 16666 and 16667<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  Cisco documentation identifies UDP ports 16666 and 16667 as required between Catalyst 9800 mobility peers when the controllers are separated by routed networks. Firewalls or access control devices between the controllers must permit this communication so mobility control and data tunnels can form correctly. A design can have correct WLAN and mobility configuration yet still fail to support roaming if these packets are blocked in the network path. Mobility planning should therefore include routed reachability, firewall rules, controller addressing, and verification of the mobility tunnel state between peers.<\/span><\/p>\n

                  Question 129. When must Catalyst 9800 controllers use the same mobility group name<\/b><\/p>\n

                    \n
                  1. <\/b> When all APs use 2.4 GHz<\/span><\/li>\n
                  2. <\/b> When guest anchoring only is used<\/span><\/li>\n
                  3. <\/b> When seamless fast roaming is required<\/span><\/li>\n
                  4. <\/b> When DHCP is centralized<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 3. When seamless fast roaming is required<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    Controllers should use the same mobility group name when they must operate as one mobility group and support seamless roaming features such as Fast Transition. Cisco notes that the same mobility group name is required when fast Layer 2 roaming technologies such as Fast Transition or Cisco Centralized Key Management are used across controllers. Controllers used only for guest anchoring can have different mobility group names because normal client roaming between those controllers is not required. Mobility group naming should therefore reflect the intended roaming relationship rather than simply being made identical everywhere.<\/span><\/p>\n

                    Question 130. What can happen if guest foreign and anchor controllers use different mobility group names<\/b><\/p>\n

                      \n
                    1. <\/b> Guest anchoring can still operate<\/span><\/li>\n
                    2. <\/b> All APs shut down<\/span><\/li>\n
                    3. <\/b> DHCP is disabled<\/span><\/li>\n
                    4. <\/b> RRM stops globally<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 1. Guest anchoring can still operate<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      Guest foreign and anchor controllers do not need to share the same mobility group name merely to build a guest anchor tunnel. Cisco specifically notes that their group names can be different and may preferably remain different when normal roaming between the controllers is not intended. Guest anchoring uses mobility tunneling to carry guest client traffic from the foreign controller to the anchor controller. This is different from building one seamless mobility group for ordinary client roaming, where matching group names become important for supported fast roaming behavior.<\/span><\/p>\n

                      Question 131. What does an RF group coordinate across controllers<\/b><\/p>\n

                        \n
                      1. <\/b> DHCP scopes<\/span><\/li>\n
                      2. <\/b> User passwords<\/span><\/li>\n
                      3. <\/b> Wired routing<\/span><\/li>\n
                      4. <\/b> Radio Resource Management<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 4. Radio Resource Management<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        An RF group is a logical collection of wireless controllers that coordinate Radio Resource Management. Controllers using the same RF group name can share RF information so RRM decisions can consider a broader wireless environment than one controller alone. Cisco maintains separate RF grouping behavior for the supported radio bands. An RF leader is elected to coordinate the group. RF groups are therefore important when neighboring access points belong to different controllers but still need coordinated channel and transmit power behavior. RF grouping is separate from mobility grouping, even though the same controllers can participate in both.<\/span><\/p>\n

                        Question 132. What must match for controllers to participate in one RF group<\/b><\/p>\n

                          \n
                        1. <\/b> Controller serial number<\/span><\/li>\n
                        2. <\/b> RF group name<\/span><\/li>\n
                        3. <\/b> Management IP address<\/span><\/li>\n
                        4. <\/b> Switch hostname<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 2. RF group name<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          Controllers must use the same RF group name to participate in one coordinated RF group. This allows their access points to contribute RF information to a shared Radio Resource Management domain. One controller becomes the RF leader and coordinates algorithms across the group. This is useful when access points managed by different controllers are physically near each other and therefore affect the same RF environment. The RF group name does not need to match switch hostnames or controller addresses. Designers should also distinguish RF grouping from mobility grouping because the two mechanisms solve different problems.<\/span><\/p>\n

                          Question 133. Are RF groups shared across all radio bands as one group<\/b><\/p>\n

                            \n
                          1. <\/b> Always<\/span><\/li>\n
                          2. <\/b> Only on virtual controllers<\/span><\/li>\n
                          3. <\/b> No separate groups exist per radio band<\/span><\/li>\n
                          4. <\/b> Only when using FlexConnect<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 2. Only on virtual controllers<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            Cisco maintains separate RF group operation for different radio networks rather than treating every supported frequency as one common RF environment. Controllers coordinate RRM separately for bands such as 2.4 GHz, 5 GHz, and 6 GHz because each band has different channels and RF conditions. This separation allows channel assignment and related radio management decisions to reflect the actual spectrum being managed. The controllers can still use the same configured RF group name, but the operational RF grouping is handled on a per radio network basis.<\/span><\/p>\n

                            Question 134. What is elected inside an RF group<\/b><\/p>\n

                              \n
                            1. <\/b> Mobility anchor<\/span><\/li>\n
                            2. <\/b> Primary DHCP server<\/span><\/li>\n
                            3. <\/b> RF leader<\/span><\/li>\n
                            4. <\/b> Guest foreign controller<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 3. RF leader<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              An RF leader is elected among controllers participating in an RF group. The leader coordinates Radio Resource Management information and allows RRM algorithms to operate across access points managed by several controllers. This is important in large deployments where neighboring APs may belong to different controllers but still share the same physical RF environment. The RF leader role is different from mobility roles such as anchor and foreign controllers. RF groups focus on radio optimization, while mobility groups focus on roaming, client state, and related intercontroller operations.<\/span><\/p>\n

                              Question 135. What can FlexConnect local authentication provide during a WAN outage<\/b><\/p>\n

                                \n
                              1. <\/b> Client authentication at the branch<\/span><\/li>\n
                              2. <\/b> Global RRM leadership<\/span><\/li>\n
                              3. <\/b> Mobility anchoring<\/span><\/li>\n
                              4. <\/b> Controller SSO<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 1. Client authentication at the branch<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                FlexConnect can perform client authentication locally at a remote branch when connectivity to the central controller is unavailable, provided the design and authentication configuration support local authentication. This is useful for branch offices where wireless access must remain available during a WAN interruption. FlexConnect can also locally switch client data, reducing dependency on the central WAN path. Designers should identify which services must survive controller loss and configure branch infrastructure accordingly. Features that require direct controller or central service access may still be affected during a WAN outage.<\/span><\/p>\n

                                Question 136. Can FlexConnect use local authentication while the controller connection is healthy<\/b><\/p>\n

                                  \n
                                1. <\/b> No<\/span><\/li>\n
                                2. <\/b> Only for guest clients<\/span><\/li>\n
                                3. <\/b> Only after AP reboot<\/span><\/li>\n
                                4. <\/b> Yes<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 4. Yes<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  Cisco documentation states that FlexConnect access points can perform local authentication even while they remain connected to the central wireless controller. Local authentication is therefore not limited only to a controller outage. This provides designers with flexibility when branch authentication services are available locally and should be used regardless of WAN state. FlexConnect can combine local or central authentication with local or central switching according to the deployment requirements. The correct combination depends on WAN reliability, branch services, security policy, and how much dependency on centralized infrastructure is acceptable.<\/span><\/p>\n

                                  Question 137. Which feature is not supported with FlexConnect local authentication according to Cisco guidance<\/b><\/p>\n

                                    \n
                                  1. <\/b> Local switching<\/span><\/li>\n
                                  2. <\/b> RADIUS Change of Authorization<\/span><\/li>\n
                                  3. <\/b> RADIUS authentication<\/span><\/li>\n
                                  4. <\/b> Branch WLAN access<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 2. RADIUS Change of Authorization<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    Cisco notes that RADIUS Change of Authorization is not supported in a FlexConnect local authentication deployment. Change of Authorization is normally used by a RADIUS server to modify an existing client session after authentication, such as changing policy or authorization state. Designers who rely on CoA based workflows must therefore consider central authentication or another supported architecture. FlexConnect local authentication remains useful for branch survivability and local service dependency reduction, but not every centralized AAA capability is available in the local authentication model.<\/span><\/p>\n

                                    Question 138. What is the main design benefit of FlexConnect for remote offices<\/b><\/p>\n

                                      \n
                                    1. <\/b> It eliminates all WAN requirements<\/span><\/li>\n
                                    2. <\/b> It converts APs into routers<\/span><\/li>\n
                                    3. <\/b> It avoids deploying a controller at every branch<\/span><\/li>\n
                                    4. <\/b> It disables CAPWAP<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 3. It avoids deploying a controller at every branch<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      FlexConnect allows organizations to deploy access points at remote branches while managing them from central Catalyst wireless controllers across the WAN. This removes the need to install a separate wireless controller at every office. The access points can switch traffic locally and can support local authentication options depending on the design. Control communication still depends on the controller during normal connected operation, so FlexConnect does not eliminate the WAN. Its value comes from central management combined with flexible local data handling and improved branch survivability.<\/span><\/p>\n

                                      Question 139. What information do controllers in one mobility group share<\/b><\/p>\n

                                        \n
                                      1. <\/b> Client context and AP information<\/span><\/li>\n
                                      2. <\/b> Switch power budgets<\/span><\/li>\n
                                      3. <\/b> DNS root zones<\/span><\/li>\n
                                      4. <\/b> Building construction materials<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Client context and AP information<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        Controllers in one mobility group share information about wireless clients, client state, access points, controller loading, and other mobility related context. This allows clients to roam between controllers while maintaining session continuity and prevents access points belonging to another mobility group member from being incorrectly treated as rogue devices. Sharing this information also supports controller redundancy and intercontroller roaming. Cisco recommends limiting mobility groups to controllers that actually serve common roaming areas so unnecessary state does not consume resources across controllers that never need to exchange client mobility information.<\/span><\/p>\n

                                        Question 140. What is the point of attachment in an anchored guest design<\/b><\/p>\n

                                          \n
                                        1. <\/b> Anchor controller<\/span><\/li>\n
                                        2. <\/b> Internet firewall<\/span><\/li>\n
                                        3. <\/b> Foreign controller<\/span><\/li>\n
                                        4. <\/b> DHCP server<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 1. Anchor controller<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          In Cisco guest access terminology, the foreign controller is the point of attachment because it manages the AP to which the guest client physically associates, while the anchor controller is the point of presence where the guest client enters the wired network. The foreign controller encapsulates the guest traffic and sends it through the mobility tunnel to the anchor. The anchor then decapsulates the traffic into the guest exit network. Separating these roles allows guest access to be offered across the campus while keeping its Layer 3 termination centralized in an isolated location such as a DMZ.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Cisco CCNP 300-425 Exam Dumps and Practice Test Dumps. Question 121. What is the maximum number of controllers in one Catalyst 9800 mobility group 8 16 24 32 Correct Answer: 3. 24 Explanation: A Catalyst 9800 mobility group supports up to 24 controllers. Cisco recommends avoiding unnecessarily large mobility groups even when the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22647"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=22647"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22647\/revisions"}],"predecessor-version":[{"id":22648,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/22647\/revisions\/22648"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=22647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=22647"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=22647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}