[c-nsp] IOS XR BGP

[Mark Tinka]

On Tuesday, November 29, 2011 07:59:00 AM Keegan Holley 
wrote:

> 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.

Understand.

Well, it's not such a major problem for us:

	o For our Juniper route reflectors, we write a
	  static route of the aggregate pointing to
	  'discard', call that via a policy statement, apply
	  the right BGP attributes and send the route on its
	  way.

	o For our Cisco route reflectors, we write a static
	  route of the aggregate poing to 'Null0', dig it
	  into BGP using a 'network' statement, and apply
	  the right BGP attributes via a route-map and send
	  the route on its way. Note that like the Juniper,
	  one could also use a route-map to call the static
	  route into BGP via a tag (I think Gert has
	  mentioned, once or twice, that that's what he
	  does), negating the need for a 'network'
	  statement.

In either case, above, all other routers in the network 
(edge, blackholing, peering, borders, e.t.c.) simply refer 
to communities to get routes out to the Internet, customers 
or peers. No additional "routing" is required on these 
routers, just reference to communities.

> 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.

It's just an implementation style, one of many. It's not 
something we touch everyday, so having to deal with it isn't 
an hourly nightmare that 'network' statements would be too 
cumbersome.

Personally, I prefer 'network' statements because they're 
deliberate. You always know you're doing "something" as it's 
a two-step process. I'm more wary of redistribution in the 
global table, although, like in Gert's case, it can also be 
controlled if you have the right guys at the helm.

Every solution has its risks, costs and benefits.

> I've heard this practice referred to as
> "self-documenting".

Network-authoritative documentation is bad for you :-). But 
I guess we're going off-topic here :-).

> 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...

No, I know what you mean. 

Normally, one would know the aggregates they have from their 
regional registry. Also, if, like me, you originate your 
aggregates form some central device such as a route 
reflector, you're bound to "know" those are aggregates as 
it's likely you wouldn't be originating other routes from 
there.

On a more personal note, I tend to shy away from certain 
explicit features that were designed for a specific task 
that can be achieved in a more feature-independent fashion. 
The reason for this is when you get new kit whose software 
is still developing, the BU for that kit may feel the 
feature you want has no place on their platform, will be 
available only in 5 years because it's low priority 
(industry has settled on another method), is obsolete, was 
never efficient for the system, e.t.c. Of course, there are 
some features you certainly can't do without, but we've hit 
such issues a lot as we've deployed newer kit from vendors, 
making our backbone sometimes inconsistent between old and 
new boxes re: configuration.

A classic case was the IOS XR team who think that prefix 
lists (which support variable subnet lengths in IOS and IOS 
XE) have no place on the CRS or ASR9000 platforms in the 
IOS/IOS XE-style. You can imagine how high we hit the roof 
when we heard their reasons.

> 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....

These are corner cases, which I wouldn't advertise in my 
Best Practices list as the way to go, but let folk know that 
kinky situations may require kinky solutions.

> 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.

You misunderstand me, Keegan. I was saying that "IF" we were 
evaluating Juniper and Cisco and "IF" Cisco turned out to be 
the preferred choice for 99% of the requirements for that 
particular bid, then the 'aggregate' feature on the Juniper 
would not be enough to sway us away from the Cisco which 
represented 99% of what we needed at that point in time.

We are a 50/50 house re: Cisco and Juniper kit. Each time we 
buy kit, we evaluate our needs at that point in time and put 
both vendors through their paces. The best one wins. So it's 
Juniper or Cisco today for the core, Cisco or Juniper 
tomorrow for the edge, Juniper or Cisco the next day for 
peering, Cisco or Juniper the next day for Metro-E, e.t.c.

50/50, with no strong desire for one vendor over the other, 
especially with today's state-of-the-art.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20111129/0c67bbaa/attachment.sig>