My question is to do with the ACL filtering that is performed on the PFC, since i'm testing the use of CoPP.
As an example:
- My machine (188.8.131.52) is connected to a switchport on a 6509, running a SUP720, PFC3B
- My machine is configured on VLAN50, where the subnet 184.108.40.206/24 is homed on this 6509.
- An appropriate ACL (in and out) is applied to the SVI for VLAN50.
- There is also an ACL applied to the VTY lines on the router, allowing only SSH connections from certain hosts. Note, for this test case my machine is not permited to SSH to the router.
- If i try to SSH to my default gateway (220.127.116.11), i cannot, so this verifies that the ACLs attached to the VTY lines are working as expected.
However, if i generate a huge amount of UDP traffic (in the order of 5Mbps) from my machine to my gateway 18.104.22.168, port 22, i notice that the CPU load increases from 5% to about 20-30 within a matter of seconds.
(Note, I'm running this test just as a test case to see how useful Control Plane Policing will be to us)
Noticing this, my question is:
- When a packet enters the PFC to be L3 switches, shouldn't the ACLs (which govern what devices are permitted access to the router on port 22) have firstly stopped my flood of data to port 22, whether it be UDP or TCP? Thus preventing the CPU from reaching 30%.
- I would have expected that the VTY ACLs would have stopped my flood in hardware - am i missing something?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...