On 11/12/12 8:48 PM, CiscoNSP_list CiscoNSP_list wrote:
> 
> Hi Guys,
> We currently run OSPF across our POPs - redistributing connected + static 
> subnets.
> So, provision a customer tail, and all POPs know about the new subnet....and 
> also if we statically route an additional subnet to a customer, all other 
> POP's are updated.
> Our issue is if we need to run OSPF to the customer(eg if they have redundant 
> connections), and they require an additional subnet(So they advertise the 
> additional subnet back to us via OSPF), the only POP that is "aware" of the 
> advertised additional subnet is the one that has the OSPF session to the 
> customer - All our other POP's dont see this advertisement as it is within a 
> different OSPF process to our "Internal" OSPF process - Solution is to 
> redistribute ospf process(customer) in our "Internal" OSPF...but we also have 
> to use route-map/acl to ensure they dont potentially blackhole us(by 
> advertising something back to us that they shouldnt)....Is there a "better" 
> way to be doing this?  As having to redistribute customer ospf/controlling 
> that redist with route-map/acl just doesnt seem like a "good" solution?(At 
> the very least, it's terrible to manage)  

I would suggest migrating to iBGP for customer routes, redistributing
connected and static into iBGP much like you do now for OSPF.  You are
going to run in to scalability problems with OSPF for customer routes.
Keep OSPF for your infrastructure but not for customer routes.  You
really don't want your infrastructure routing process recalculating
every time a customer serial link flaps or a customer has a power blip.

Customers with redundant connections can use a private AS into iBGP or
tracked floating statics redistributed.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to