[c-nsp] Loopback Advertise in OSPF

[Phil Mayers]

Mark Tinka wrote:
> On Wednesday 27 February 2008, Darryl Dunkin wrote:
> 
>> If you're using /32 masks for your loopbacks (as you
>> should): router ospf ####
>>   redistribute connected subnets
>>
>> The key part is to define 'subnets'.
> 
> I'd advise against using 'redistribute' to announce any kind 
> of prefixes into any kind of routing protocols (with the 

I think that's probably a bit dramatic (no offence intended). We've used 
"redis connected / static" for "customer" routes (edge networks) for 
quite a while now here with no problesm; initially in a VRF-lite model:

router ospf 2 vrf CUST2
  ! enable OSPF on loopback and p2p
  network 192.168.0.0 0.0.1.255 area 0
  redis connected
  redis static
router ospf 3 vrf CUST3
  ! enable OSPF on loopback and p2p
  network 192.168.2.0 0.0.1.255 area 0
  redis connected
  redis static

...then later with MPLS VPNS:

router bgp 65xxx
  address-family ipv4 vrf CUST1
   redis connected
   redis static
  address-family ipv4 vrf CUST2
   redis connected
   redis static

In the former case (OSPF/VRF-lite), there are several advantages to 
doing this that I can see:

  * you don't have to have lots of network statements (or one large one 
with a netmask of /0) and lots *more* passive-interface statements - the 
latter of which aren't available on the per-VRF OSPF processes anyway in 
some IOS and have to be put on the non-VRF OSPF process :o(

  * the routes generates are OSPF E2 which since they are at the leaves 
of the tree, churn in them does not require an SPF recompute - provided 
"ispf" is specified on the OSPF process.

  * you can specify a route-map to control what is redistributed which 
seems to me cleaner for several reasons - it separates the policy from 
the config of the L3 interface, and obviously provides much better 
policy controls

  * Assuming it's not covered by a large network statement, addition of 
a new interface/subnet require operators to fiddle with the router 
config statements if using "network" statements. Tedious and risky IMHO.

The major disadvantages that I can see are:

  * because the routes are E2s it increases the number of LSAs - which 
obviously went away with the move to MPLS/BGP

  * "redistribution is bad" - which is certainly true *between* the 
dynamic protocols, but no-one has ever convinced me that's true for 
connected or static routes

I'd be interested to hear specific instances of redis connected/static 
causing problems.


> exception of MPLS/VPN's, as that is scope is quite more 
> limited [VRF instances] and easily manageable/predictable).
> 
> Rather, specify your networks within the OSPF process, 
> explicity:
> 
> router ospf 1
>  network 1.2.3.4 0.0.0.0 area 0
> 
> Alternatively, if you have the opportunity to run IOS 12.4, 
> you can now deploy OSPFv2 directly on an interface:
> 
> int lo0
>  ip address 1.2.3.4 255.255.255.255
>  ip ospf 1 area 0
> 
> I find the above approach to be more manageable, 
> cosmetically appealing as well as less prone to mistakes, 
> e.g., forgeting to add the (correct) 'network' statement 
> under the OSPF process, e.t.c.
> 
> The scalable approach - use OSPF to carry ONLY your 
> infrastructure and Loopback addresses. DO NOT carry your 
> customer's IPv4/IPv6 addresses in OSPF, do this in iBGP 
> instead.
> 
> Cheers,
> 
> Mark.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/