RE: redistribution bgp>ospf

Is this one Physical Location the ONLY location where your routes are actually being announced in the whole internet Tony?

I would not do the ospf<->bgp redistribute thing - I would just throw a few static routes to "null0 254" into my router and use bgp network statements under the process to announce them. Why?

Because why add risk and overhead when you don't need to?

The ONLY time I would EVER redistribute ospf (or any igp) into bgp running with a carrier is *IF* I had several other ways out of my network and my network had private/internal networking between the places where I speak bgp - kind of like a huge company with datacenters in NYC and San Fran, etc. but the inside is connected via Fiber, MPLS, etc.

Now, the redistribution of OSPF <-> BGP buys me:

1. My ospf network will use the "closest" exit point - via using E1 metrics to carry the hop by hop cost of taking the exit they find to the Internet...
2. My bgp edge network will advertise routes to the WHOLE internet it can actually get to - and wont advertise them out when it can't get there - say that FIBER between my coasts is down.

In tribute to the great Jimi Hendrix, I call this design "There must be some kind of way out of here".

-Joe

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Tony Singh
Sent: Sunday, February 24, 2013 7:23 AM
To: Cisco certification
Subject: redistribution bgp>ospf

Hi

Just a quick sanity check...

I'm redistributing bgp>ospf and using network statements to control how my ospf subnets are sent to my ebgp peer, now please correct my understanding but the ebgp peer see's the ospf routes coming from my AS number...and when I reset this connection I can see in debug ip bgp updates the update message for the original ospf routes when the ebgp peers synchronize will deny my originated prefixes coming back to due to = DENIED due to: AS-PATH contains our own AS;

So therefore there is no risk if I redistribute bgp into ospf of double redistribution as the ebgp boundary would deny any originally originated prefixes in the first instance?

in summary, I am using network statements to control ospf>bgp and bgp>ospf is using redistribute keyword with tag<as number> and I can see in ospf rib on internal devices only the tagged prefixes which I would expect.

I have seen some examples using bgp community to tag & deny but this is only when using mutual redistribute command under both processes.

Best Regards

Tony

Blogs and organic groups at http://www.ccie.net
Received on Sun Feb 24 2013 - 17:32:34 ART