[c-nsp] Cross-subnet wake-on-lan (directed broadcast) with 6500s

[Phil Mayers]

Dale W. Carder wrote:
> 
> On Dec 5, 2006, at 9:10 AM, Phil Mayers wrote:
> [directed broadcasts]
>>   You can either have them forwarded in hardware with no filtering, or
>> you can have them forwarded in software with filtering
> 
> That's my impression, too.  However, I would like to be proved wrong.
> 
>>   2. Can people provide concrete details that I can use to argue against
>> implementation of either of the directed broadcast options?
> 
> Directed broadcasts without packet filtering is a no-go.
> Software implementation of ACL's is a no-go.

Tell me about it! Sadly it's like speaking a different language. People 
just don't want to hear it.

For info, I benchmarked the CPU hit the other day.

On a stock sup720 with 6748 and DFCs, ~900pps of directed broadcasts 
eats ~20% of the RP CPU - of which ~10% is in interrupt, ~10% in the "IP 
input" process. The packets most definitely are not software-CEF switched!

These numbers seem to have given management pause. 5k pps to bring the 
router to 100% utilisation is not a nice idea ;o)

> 
>>   3. Are people aware of any other technical solution which might
>> provide this facility? An ability to emit them from the routers via TCL
>> perhaps, or some other fiendish way?
> 
> If you're going to be forced into this, here's what I think would work
> (crappy example off the top of my head, don't try anything like this
> without thinking):
> 
> 
> int vlan4097
>  ip directed-broadcast 153
> !
> access-list 153 permit udp x.x.x.x y.y.y.255 any eq z
> access-list 153 deny udp any any
> !
> ip access-list extended everythingelse
>   permit ip any any
> !
> class-map match-all wakeonlan
>   match access-group 153
> class-map match-all default
>   match access-group name everythingelse
> !
> mls qos
> !
> policy-map control-plane-in
>   class wakeonlan
>    police cir 32000 bc 32000 be 32000 conform-action transmit 
> exceed-action drop violate-action drop
>   class default
>    police cir 100000000 bc 640000 be 640000 conform-action transmit 
> exceed-action drop
> !
> control-plane
> !
> service-policy input control-plane-in

Interesting. I originally imagined that CoPP only applied to traffic 
destined *to* the router but have since found our otherwise e.g. RPF 
checks with an ACL - the denied ACL entries are processed on the RP and 
are certainly hit by CoPP - before SXF6 and the "mls ip cef rpf 
hw-enable-rpf-acl" command of course, when the permitted ACLs are 
forwarded (bizarrely).

This is a good suggestion - thanks, I'll give it a try.