[149494] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Optimal IPv6 router

daemon@ATHENA.MIT.EDU (Leo Bicknell)
Mon Feb 6 09:19:50 2012

Date: Mon, 6 Feb 2012 06:18:46 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <20120206073426.GB8779@srv03.cluenet.de>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roese=
n wrote:
> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
> on XR]).

IOS-XR is fully AFI-agnostic, as far as I can tell.  It also updated
the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar
syntax.  I think also that all of the platforms on which IOS-XR
runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in
hardware, with features.

While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has
one very cool feature.  You can pass parameters in route policy.  Many
networks maintain slightly different versions of policies like
"peer-in/peer-out" due to various load balancing or preference needs,
with a 5-15 stanza policy repeated over and over.  When you have to
update one of the stanzas in all policies it becomes a big mess.
In IOS-XR, you can write a generic policy and then call with with
parameters:

route-policy generic-out($routeCommunity)
  ... ! Do all the common things
  if community matches-any $routeCommunity then
    accept
  endif
  drop
end-policy

community-set send-to-private-peers
  1234:5678
end-set

route-policy private-peer-out
  apply generic-out(send-to-private-peers)
end-policy

community-set send-to-public-peers
  1234:4321
end-set

route-policy public-peer-out
  apply generic-out(send-to-public-peers)
end-policy

With a little bit of careful thought you can really collapse down the
policy to be much shorter, easier to understand, and have almost no
cut-and-paste in it, which should reduce errors when updating in the
future.

--=20
       Leo Bicknell - bicknell@ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQIVAwUBTy/hRrN3O8aJIdTMAQIYgg//XDIrMhBYT+sSO91ZQSLGA+JFV0vUjSxs
34lm2TWopPvSX4snNyugFBDySAf8dFD14rf0unTH+oHA9UXPCsdAqt9SbbaCXXBC
pe5umAx8VvzO2E4SKhGMSZdZmrjItauzWedeIb2kajrjiT95O4m9TwrWyvfKVLGS
VNwkxcood42pPULlGFIj9VvBNqQMHAAPGGyASJBz/yW3ovOQOC/a4Ub2TxYyZard
stETNV3z7QwSy/yTimS7YQlQfUZdm+OoMyJwzt7lY7c6QUqr/qUfpYm4H4Mpsx1H
0rUQcNDP4PEc2n/R3geKM4YVaMy5GMd9rsrf6FYofTmgCALGIGBU9iiV3N0HXTdM
uHihSFWIX8CE3qACiDtmGb52x7X/Lt0JmO6GwbYCm0Cr5w56Zi8Mrw0UIYja1iDw
gSheqe9HQo9vI6SBJQSkV1ht5jJY7oX6tz6MnvW0ysPM6OWQ4wUWr41EyAysSC5I
d5znp1yw1WFB2H39xgar3SiwMETiRcWs8HdRM7I1HjBLlYN9HwUe0qIyYKjd8ZRY
MmQ9hyVqqdtIamcoD6R6Hka490jw731w8Kn+u4KkoS3ZkXZTq9ROo2NrhT9jC8sO
8axph6MjFPGS9+mMWR4tqif9bc4N4ztrSxh80KghasFHWibNUqBN1YIkZF8wIx5R
Z0Th7XIr1gE=
=ISUy
-----END PGP SIGNATURE-----

--pWyiEgJYm5f9v55/--


home help back first fref pref prev next nref lref last post