[c-nsp] OSPF and BGP relationship

Wed Mar 4 05:23:12 EST 2015

Hi Aron,

The HW limitation only hits Trident line-cards with default profile that allows only 512K v4 routes.
So these have to be set with L3 or L3XL profiles before they can be used for Internet routing. 
Using cmd "hw-module profile scale l3/L3xl". 
-but it requires reload of the LC to take effect. 

The VRF limitation. 
-there are also some inefficiencies related to lookups on Trident cards because of the FIB architecture. 
You have to use cmd "mode big" so that the VRF gets TableID 1-15 as TableIDs 16+ have only one subtree limited to 256k. 

There are no such limitations on Typhoon LCs as those use mtries. 

adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Aaron
> Sent: 03 March 2015 13:48
> To: 'Network'; 'Clint Wade'
> Cc: 'cisco-nsp'
> Subject: Re: [c-nsp] OSPF and BGP relationship
> 
> Also, while we are on the subject of full bgp internet routing table….
> 
> 
> 
> My Internet connections are landing on my PE ASR9k’s.  so the internet 10gig
> interface is in a vrf.  Currently I only learn one route from my upstream
> provider…0/0.  If I were to learn the full bgp internet table, is this OK?  I read
> somewhere that there are concerns about learning the full bgp table into a
> MPLS L3VPN vrf.  Maybe what I read was specific to asr9k running certain cpu
> and trident linecard, I don’t recall, but I would appreciate anyone’s insights.
> 
> 
> 
> Aaron
> 
> 
> 
> 
> 
> From: Network [mailto:network at cwo.com]
> Sent: Monday, March 02, 2015 8:08 PM
> To: Clint Wade
> Cc: Aaron; cisco-nsp
> Subject: Re: [c-nsp] OSPF and BGP relationship
> 
> 
> 
> I should have mentioned that I'm only getting a default route from my
> upstream providers. I guess I could request a full table, as we have enough
> resources to handle it on the edge routers. In the past there has not been a
> convincing reason to receive a full bgp route table.
> 
> 
> 
> Just curious, how large,in megabytes, is the current bgp table?
> 
> 
> 
> JB
> 
> 
> On Mar 2, 2015, at 5:11 PM, Clint Wade <jarod.wade at gmail.com> wrote:
> 
> Everything I'm stating below here is under the assumption you're receiving a
> full route table from the ISP's and not just a default route. If all you're getting
> is a default, you're looking at something like policy based routing or possibly
> PFR to fix this as far as I know.
> 
> 
> Weight and Local Pref to affect outbound --> You'll want it higher on the one
> you want to be the exit point and as long as you have an iBGP connection
> between your two BGP edge routers you'll be ok. If no iBGP link between
> your two edge routers exists then affecting outbound is impossible as you're
> limited by OSPF and the best you can do is force one to be the outbound for
> all prefixes. Another way I've seen done what you're doing is to originate 1
> default in OSPF as Type 1 and the other as Type 2, obviously the exit path to
> the Type 1 route is preferred, but once it makes it to that edge router you'll
> have to rely on BGP path selection to affect which edge router to egress for
> specific prefixes, which is why the iBGP link is required.
> 
> 
> AS Path and MED to affect inbound --> Usually done by sending communities
> to your providers to affect their routes; Each provider has a list of
> communities they accept to perform functions such as 'Add 4x AS# to
> existing AS_Path' or 'Set local pref' on the provider side. You'll need to use a
> looking glass server to verify these changes, and you'll want to check them
> from a couple different providers looking glass to see what effects it has on
> routing outside of the provider you're trying to traffic engineer. Keep in mind
> you have to be careful as some providers transit to other provider
> connections can get saturated which can lead to some unexpected side
> affects, so you'll have to keep a close eye on performance (latency, etc.)
> 
> 
> 
> On Mon, Mar 2, 2015 at 4:12 PM, Aaron <aaron1 at gvtc.com> wrote:
> 
> I also have 2 (working on 3) Internet connections and only learn default route
> from upstream provider....
> 
> I don’t know if this is best/common practice but if I ever prefer a /32 to exit
> out one of my particular internet connections, I'll point a static /32 out that
> internet connection and redistribute it into my igp....my igp happens to be
> mb-ibgp for my l3vpn's to rcv it across my mpls network.
> 
> Aaron
> 
> 
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> CWO Network Operations
> Sent: Monday, March 02, 2015 3:40 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] OSPF and BGP relationship
> 
> I have a question about the common practice of using OSPF and (i)bgp.
> 
> Here is my setup:
> 
> 
> I have 4 Cisco routers (A, B, C & D). All routers are connected to each other
> through metro ethernet connections. The 4 routers have other “stuff”
> behind them speaking only OSPF and require a injected default route.
> Router A and B are connected to different internet backbone providers using
> BGP.
> Internally I use iBGP and OSPF. I do not redistribute OSPF routes into BGP,
> nor do I do the opposite.
> Router A injects a default route into the network using OSPF’s default-
> information originate metric 100.
> Router B also injects a default route into the network using OSPF’s default-
> information originate metric 110.
> 
> So, right now all my outbound traffic goes out through router A (because of
> the metric 100). Inbound traffic comes through both internet connections,
> based on the preferred BGP route.
> Since the IGP (ospf) has the lower IGP metric (in comparison to ibgp) the
> ospf default routes (0.0.0.0/0) routes determine the flow of outbound
> traffic. Because of that, I can’t seem to “direct” outbound traffic using a local
> route map (local-preference). Ideally I would like to be able to direct
> outbound traffic as specific as I like.
> 
> What is the common setup, in terms of BGP and OSPF, on networks that
> resemble ours?
> 
> Thanks
> JB
> 
> 
> 
> 
> _______________________________________________
> 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/
> 
> 
> _______________________________________________
> 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/
> 
> 
> 
> _______________________________________________
> 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/
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------