[alcatel-nsp] 7750 Route Reflector Server Question

[James Jones]

+1



On Fri, Mar 4, 2011 at 10:58 AM, Andy Vance <andy.vance at 360.net> wrote:

>  I would utilize community tags to differentiate the routes and apply
> different behavior to them in my export policy.
>
>
>
>                 entry 5
>
>                     from
>
>                         protocol bgp
>
>                         community ebgp-community-tag
>
>                     exit
>
>                     action accept
>
>                         next-hop-self
>
>                     exit
>
>                 exit
>
>                 entry 10
>
>                     from
>
>                         protocol bgp
>
>                         community ibgp-routes
>
>                     exit
>
>                     action accept
>
>                     exit
>
>                 exit
>
>
>
> Would that accomplish what you need?
>
>
>
> Cheers,
>
> Andy
>
>
>
>
>
> *From:* alcatel-nsp-bounces at puck.nether.net [mailto:
> alcatel-nsp-bounces at puck.nether.net] *On Behalf Of *Ben Robinson
> *Sent:* Thursday, March 03, 2011 10:35 PM
> *To:* Griego, Michael (Michael)
>
> *Cc:* alcatel-nsp at puck.nether.net
>  *Subject:* Re: [alcatel-nsp] 7750 Route Reflector Server Question
>
>
>
> The goal is to collapse RR an ASBR functions into the same router. The
> solution I'm after would meet the best practice of keeping the route
> reflector out of the forwarding path while allowing the same router to pick
> up external peers.
>
> Ben Robinson
> Systems Engineer
> LS Networks
>
>
>
> -----Original message-----
>
> *From: *"Griego, Michael (Michael)" <michael.griego at alcatel-lucent.com>*
> To: *Ben Robinson <brobinson at lsnetworks.net>*
> Cc: *"alcatel-nsp at puck.nether.net" <alcatel-nsp at puck.nether.net>*
> Sent: *Fri, Mar 4, 2011 03:21:17 GMT+00:00*
> Subject: *Re: [alcatel-nsp] 7750 Route Reflector Server Question
>
> Where is the placement of the route-reflector?  If you place the
> route-reflector so that it is not the ebgp peering router (asbr) then all
> that is needed is to set next hop self on asbr and leave route reflector
> without next hop self.  I thought best practice was to typically remove a
> route reflector from forwarding path.
>
> Mike
>
>
> On Mar 3, 2011, at 5:28 PM, "Ben Robinson" <brobinson at lsnetworks.net>
> wrote:
>
>  Greetings,
>
>
>
> I’m using route reflection on 7750-SR (8.0R7) and want to set next hop self
> for routes learned from external BGP peers, but not on routes learned from
> internal BGP peers. The goal is to reflect routes from internal peers,
> preserving the IGP next hop while setting next hop self on routes from
> external peers. Perhaps this is the default behavior.
>
>
>
> I can set all routes to next hop self in the 7750 Peer/Group configuration
> and with a policy. Since I don’t want all routes advertised internally by
> the 7750 to have the next hop self set, I’m assuming that it is accomplished
> in a policy.
>
>
>
> Firstly, does anyone know if this is the default behavior? Or, if possible,
> how to accomplish this with SROS policy.
>
>
>
> The Juniper policy equivalent is:
>
>
>
> term external {
>
>     from route-type external;
>
>     then {
>
>         next-hop self;
>
>         accept;
>
>     }
>
> }
>
> term internal {
>
>     from route-type internal;
>
>     then accept;
>
> }
>
>
>
> …
>
>
>
> Policy nhs-ipv6:
>
>     Term external:
>
>         from route-type external
>
>         then nexthop self accept
>
>     Term internal:
>
>         from route-type internal
>
>         then accept
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Ben Robinson
>
> Systems Engineer
>
> LS Networks, Inc.
>
>
>
>  _______________________________________________
> alcatel-nsp mailing list
> alcatel-n <alcatel-nsp at puck.nether.net>
>
>
>
> _______________________________________________
> alcatel-nsp mailing list
> alcatel-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/alcatel-nsp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/alcatel-nsp/attachments/20110304/2b651d06/attachment.html>