I agree that a much cleaner solution is to map a subscriber to a context directly. But for other cases (assuming non subscriber traffic), PBR is possible. Here is a snippet for source based routing..<br><br> policy access-list Source_based_routing<br>
  seq 10 permit ip 192.168.1.0 0.0.255.255 any class ClassA<br>  seq 20 permit ip 192.168.2.0 0.0.255.255 any class ClassB<br>  seq 30 permit ip 192.168.3.0 0.0.255.255 any class ClassC<br><br>forward policy Source_based_redirect <br>
 access-group Source_based_routing<br>  class ClassA<br>   redirect destination next-hop  10.0.0.1<br>class ClassB<br>   redirect destination next-hop 10.0.1.1<br>  class ClassC<br>   redirect destination next-hop 10.0.2.1<br>
<br>//cheers<br><br><br><div class="gmail_quote">On Thu, May 19, 2011 at 3:22 AM, Pawel Jarosz <span dir="ltr"><<a href="mailto:pj@hostersi.pl">pj@hostersi.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Wed, 18 May 2011, Ian Calderbank wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pawel,<br>
</blockquote>
Ian,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Its not clear to me what you are asking / trying to do, the explanation<br>
seems a little confused?<br>
<br>
If you are asking, whats the equivalent of cisco PBR (make forwarding<br>
decision based on source IP or other arbitrary criteria), its "forwarding<br>
policy" applied to circuit, which it seems you are already trying using.<br>
</blockquote></div>
Exactly.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can apply forwarding policy by radius attribute per-subscriber, if<br>
that's more scalable for you.<br>
</blockquote></div>
Static is for now, I try to get it work.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most scalable design is to bind the subscriber to the right context in the<br>
first place. Why are you binding all subs to context OSPF? Why not bind him<br>
to context A in the first place, then he automatically routes through<br>
context A?<br>
</blockquote></div>
topology is:<br>
customer(subscriber)- (port) --OSPF --- (port) - ISP A (bgp)<br>
                                    |-- (port) - ISP B (BGP)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The subscriber static route that you see is expected behaviour given that<br>
you have defined that static subscriber and it is bound.<br>
</blockquote></div>
Maybe I get it wrong, and clips is not for<br>
routed subscribers, only direct attached?<br>
If so, the route is created as expected.<div><div></div><div class="h5"><br>
<br>
Pawel<br>
<br>
_______________________________________________<br>
redback-nsp mailing list<br>
<a href="mailto:redback-nsp@puck.nether.net" target="_blank">redback-nsp@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/redback-nsp" target="_blank">https://puck.nether.net/mailman/listinfo/redback-nsp</a><br>
</div></div></blockquote></div><br>