[c-nsp] Blackholing looped traffic

[Saku Ytti]

On (2005-08-30 15:25 +0100), Tim Franklin wrote:

> >  What I'm completely uncertain is, would allowing this type of hack
> > really be beneficial, or would it encourage more people to poor
> > design. Then again, it's not like it would be only feature, thats
> > there just due to poor (as in not good but also as in ultra 
> > low-budget)
> > design :)
> 
> What's your thought as to what *is* a good design for this case?  (Hub and
> spoke VPN, spokes must not be allowed to communicate with each other, spokes
> must have a default route towards the hub (for Internet or other reason))

 Without thinking it further, something like this perhaps, but I think
the original question was something bit different.

 ip vrf spoke1
  route-target import 1:hub
  route-target export 1:spoke
 ip vrf spoke2
  route-target import 1:hub
  route-target export 1:spoke
 
 ip vrf hub
  route-target import 1:spoke
  route-target export 1:hub  
  (or even no export, just export map and only needed set of /32's tagging
   with extende-dcommunity 1:hub)
  
> I've struggled with it on a couple of occasions, and can't come up with
> anything that doesn't degenerate into hacks at some point - either ACLs, or
> a plethora of VRFs and leakiness.

 The broken-by-design solution I was refering to, doesn't actually
have anything to do with VRF, but it would benefit for a feature
that denies packets going out via same interface they come in. 
 My problem causes broadcast storms. Real solution for my problem would have
been to terminate each connection to own L3 VLAN interface, but as this
particular cutomer has hundreds of sites, VLAN wastage wouldn't been
too and the ACL hacks in CPE's WAN interface does the trick. Ugly, but works
and we can use just one interface per PE (so HSRP is very feasible also).

-- 
  ++ytti