[c-nsp] SoO For Every Route Advertised

Alex K. nsp.lists at gmail.com
Tue Jul 10 11:51:05 EDT 2012


Hi Saku,

To begin with – each PE in the network discussed has the same VRFs.

In quite the same fashion, vrf-export has matching command on the import
side (which is vrf-import, to be exact). Both commands allow Juniper router
to turn the import/export process to something more evolved than list of
RTs. Each route you're exporting or importing, can go thru elaborate set of
filters JunOS provide all of us with – and, as a result, be attached with
different RTs, SoO and other BGP communities.

So, right now it works as following (the following example only illustrates
what can be achieved with such design/CLI on JunOS, not the actual design
and traffic flows): Let assume that 2 different Juniper boxes advertise a
default route for VRF A. Now, by the means of vrf-export <policy> you can
attach SoO 100:1 only to the default route. The other Juniper box (located
in remote data center) is attaching SoO 100:22 in the same way (for VRF A,
either). Now, other Juniper boxes are matching those SoO values using
vrf-import <policy> and assigning higher weight to route coming from PE
residing in the same DC facility.

I know this design not perfect. If I were to design something like this, I
was probably used BGP confederations but this is not the point. Juniper
made it easy to make the network like this, and that the way it was done in
the past. Now, I'm only moving some functionality from those machines
(MX960s) to Cisco's (Cat6500/Sup2-T). Obviously I look to introduce the
smallest amount of change I can.

So, if there is a way to make the same configuration on Cisco, I'd go for
it. But unfortunately, Cisco's CLI deals in a very different way with SoO
than Juniper's. BTW, your suggestion about the route-reflectors sounds very
interesting … if I only can match on RTs on the RR (another MX box) … I'll
check, thank you.

Best Regards,
Alex.


More information about the cisco-nsp mailing list