This topic is to discuss the following lesson:
The control-plane command is not recognized on
3560CX iOS version 15.2
nor on a
3850 IOS-XE version 16.6.6
Is there an alternative?
Hello Bradley
According to this Cisco Documentation, the Cisco IOS Release 15M&T supports these features.
Now for your specific IOS version, you can take a look at Cisco’s Feature Navigator to see which versions support which features.
I hope this has been helpful!
Laz
Hi,
Great presentation on MPP… I was wondering, is there a concept for MPP on Catalyst switches (3K and 9K) and what about NX-OS (9K). Other than dedicated management interfaces, is it possible to restrict management to a switch port?
Hello Christopher
Remember that Management Plane Protection (MPP) is a subset of Control Plane Policing (CoPP). CoPP is something that is available on all Cisco devices including IOS and NX-OS devices.
Information about CoPP for NX-OS devices can be found here:
Notice the “management plane” section of the document.
Information about MPP for Catalyst devices, and in particular the 9K Catalyst series can be found here:
I hope this has been helpful!
Laz
cool, but even using MPP, I still need ACL to block by IP(Line VTY)
Hello Marlon
The specific example shows how to limit management connectivity to your device via only the interfaces you choose. If you want to further limit connectivity to specific hosts with particular IP addresses, then yes, you must add an access list specifying those addresses. You can do that by referencing an access list using the access-class command under the line vty configuration mode. More information on this can be found here:
I hope this has been helpful!
Laz
Hi
Is MPP a CPPr feature related to the host sub-interface of the control-plane?
Thank you
Hello Giovanni
The MPP and CPPr features are distinct and separate. For the CPPr feature, take a look at this NetworkLessons note that explains more about what it is. It is involved in all types of control traffic and enhances these QoS features of CoPP.
MPP on the other hand is specifically used for management traffic, that is, traffic used to control, configure, and manage a device (SSH, Telnet, etc…), as described in the lesson.
I hope this has been helpful!
Laz
So if I understand correctly.
MPP consist actually on this configuration, so it care only about management traffic
R1(config)#control-plane host
R1(config-cp-host)#management-interface GigabitEthernet 2 allow ?
CPPr consist on configuring policies on these sub-interfeces (except the management-interface under control-plane->host because it actually is MPP. )
Is it correct?
R1(config)#control-plane ?
cef-exception Cef-exception traffic control-plane configuration
host Host traffic control-plane configuration
transit Transit traffic control-plane configuration
<cr>
Also, I saw that I not have this command on IOSv in GNS3, does this feature is available only for physical devices with IOS (so not IOSv) ?
R1(config-cp-host)#?
Control Plane host configuration commands:
exit Exit from control-plane host configuration mode
no Negate or set default values of a command
service-policy Configure QOS Service Policy
R1(config-cp-host)#management-interface GigabitEthernet 0/2 allow telnet
^
% Invalid input detected at '^' marker.
Thank you
Hello Laz,
Greetings of the day,
Do COPP & MPP is cisco propreitary protocols?
or its available in other vendor products also?
BR//
Nitin
Hello Giovanni
Yes, you are correct. MPP simply deals with the management plane under the control-plane host command, while CPPr does indeed provide three additional control-plane subinterfaces under the top-level (aggregate) control-plane interface. Each subinterface receives and processes a specific type of control-plane traffic. These subinterfaces are host, transit, and CEF-Exception as seen in your post.
After doing a bit of reading I was unable to find out why this is the case, but I have been left with the impression that MPP is unavailable on virtual platforms such as the IOSv. Others have seen similar results with the IOS-XRv as well. My assumption is that it is simply a limitation of the virtual device.
I hope this has been helpful!
Laz
1 Like
Hello Nitin
The terms CoPP and MPP are used specifically by Cisco, but they are not proprietary protocols. The term CoPP is also used by other vendors as well, such as Aruba and HP. I haven’t seen MPP used by other vendors, but as a concept, it exists in their implementations.
Note that CoPP and MPP are not protocols. They are policing features, and more specifically QoS mechanisms that are applied to the control plane and to the management plane to achieve certain levels of security. All vendors have some form of QoS features that are specifically designed to protect these planes of communication, but the names are not always the same. You’ll have to see documentation or ask the vendor for more information.
I hope this has been helpful!
Laz
okay thanks
now its clear
1 Like
Hello, everyone!
I’ve a question. Why not just use ACLs instead of MPP? Most of the designs that I can think of wouldn’t even work well with MPP I think, consider the three-layer Cisco design
The Core switches wouldn’t be able to run MPP well here because managemement traffic must be permitted on all their interfaces because if one interface was to fall, the other one would need to accept management traffic otherwise management wouldn’t work at all.
So does MPP depend on what specific network design is being used? In other words, there might be times where ACLs will provide better control and flexibility than MPP or vice-versa?
Thank you all!
David
Hello David
It is possible to achieve results similar to those provided by MPP by using ACLs. However, MPP provides a more specific focus on protecting management interfaces and is designed specifically for that purpose. ACLs, while versatile, are a broader tool and require more careful configuration to achieve the same level of protection specifically for management interfaces.
The primary difference is the ease of configuration. MPP is generally easier to configure for the specific task of protecting management interfaces. With ACLs, you need to ensure that your configurations are precise to avoid inadvertently blocking legitimate traffic or allowing unauthorized access.
This is true of both MPP and ACLs. ACLs do not deliver an advantage in this scenario, since if an interface goes down on a core switch, and you’ve applied ACLs on ports to allow management traffic only via that port, then you will still lose management connectivity. The only way this would be avoided is if you apply the ACL to the VTY, thus not limiting connectivity to any one port.
It all comes down to weighing what’s most important to you. By restricting management traffic to a single port, you are dramatically reducing the attack surface, but you are introducing a single point of failure. By using MPP, you are deploying a configuration that is simpler and less prone to errors. By using ACLs, you have more granular control over everything but have a much higher administrative overhead. Does that make sense?
I hope this has been helpful!
Laz