Próbuję odpalić na 6500 (sup2) taki prosty PBR:
Kod: Zaznacz cały
route-map ZABLOKOWANI permit 10
match ip address ZABLOKOWANI
set ip next-hop a.b.c.d
!
route-map ZABLOKOWANI permit 20
!
ip access-list standard ZABLOKOWANI
permit a.b.c.d
permit a.b.c.d
permit a.b.c.d
permit a.b.c.d
permit a.b.c.d
!
Kod: Zaznacz cały
interface Vlan901
description jakassiec
ip address a.b.c.d 255.255.252.0 secondary
ip address a.b.c.d 255.255.255.0 secondary
ip address a.b.c.d 255.255.254.0
ip verify unicast source reachable-via rx allow-default
no ip redirects
no ip unreachables
no ip proxy-arp
!
Kod: Zaznacz cały
Core#sh proc cpu sorted
CPU utilization for five seconds: 87%/83%; one minute: 56%; five minutes: 37%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
116 22818984 138286912 165 4.55% 4.67% 4.32% 0 IP Input
6 663196 47924 13838 2.31% 0.32% 0.24% 0 Check heaps
9 3013384 10703226 281 0.71% 1.22% 1.02% 0 ARP Input
157 1462436 56800 25747 0.47% 0.55% 0.57% 0 Adj Manager
166 1183200 407350 2904 0.39% 0.55% 0.56% 0 CEF process
262 387436 1878965 206 0.31% 0.10% 0.11% 0 Port manager per
162 677512 145203 4665 0.23% 0.17% 0.17% 0 IPC LC Message H
297 40384 17288 2335 0.15% 0.01% 0.00% 0 BGP Scanner
• The PFC does not provide hardware support Unicast RPF check for policy-based routing (PBR) traffic. (CSCea53554)
Niestety wyłączenie URPF na tym VLANie nic nie pomaga, nadal dostaje kosmiczne obciążenie. Zgodnie z moim rozumowaniem powinno się wszystko odbywać w sprzęcie, a wygląda to zupełnie inaczej (na co zresztą wskazywałyby duże liczniki, które o ile dobrze rozumiem powinny być mało rzeczywiste ze względu na to, że odzwierciedlają tylko trafienia w MSFC):
Kod: Zaznacz cały
route-map ZABLOKOWANI, permit, sequence 10
Match clauses:
ip address (access-lists): ZABLOKOWANI
Set clauses:
ip next-hop a.b.c.d
Policy routing matches: 37 packets, 34329 bytes
route-map ZABLOKOWANI, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 74632805 packets, 742335703 bytes