> > You can also apply attributes directly to the aggregate. > > So you can set origin code, local pref etc. directly on > > the route. > > Yes, but you can also do that with a regular route-map for > your outbound BGP policy toward the route reflectors. > > you have to admit creating a bunch of static routes, redistributing them into BGP with one set of filters, then maintaing routing policy with another, possibly one for iBGP and yet another for upstreams is can be a bit cumbersome. I'm not saying it's not doable, nor am I saying it's a reason in and of itself to go juniper. Just that if I chose a juniper platform for some other reason I'm happy it's there. Just my personal opinion though.
> Moreover, you can apply attributes directly to 'network' > statements too, so the 'aggregate' feature isn't the only > one that brings this. > Agreed, but the network statement is part of the problem.. not saying it's a reason to go juniper, blah blah blah, see above re: import policies. > > > Also, from the non-technical side it's > > cleaner to know it's an aggregate as opposed to a static > > route doing something else. > > Well, I hardly find it useful to use the 'aggregate' command > as documentation, just because it's originating an aggregate > :-). Some other networks might call it something else. > I've heard this practice referred to as "self-documenting". I'm not proposing we all throw out our various repositories and turn to our configs for enlightenment, but when I see a route that says protocol aggregate I know what it is. When I see a route to null0 with a short mask there's some ambiguity. Maybe I chose a bad example... > > But to each his own. > > > That wasn't centered around aggregates and no. Some of > > us don't run gigantic intercontinental ISP's :) So yes > > us lowly Tier-II and Tier-III AS's may on occasion learn > > our own routes from an external connection. > > Hmmh, risky - certainly something I wouldn't advise even for > small ISP's. > It depends on your requirements. Top of the list is buying someone or getting bought and using their upstreams without changing AS number everywhere. Customers multi-homing with your ARIN/APNIC/RIPE space. I can think of a few others.... > > Actually I was. 6509/Nexus vs. EX8200, Cisco ME vs. > > > EX4200, ASR vs. M/MX > > > > and CRS vs. T/TX are all different conversations. I > > thought you were alluding to something like that which I > > would have agreed with. > > No, I wasn't alluding to that at all. > If not then the statement that a particular platform is "99% preferred" for a certain use is arbitrary and will vary from one company to the next. To each his own I guess. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
