1. Home
  2. Cisco Systems
  3. Redist. OSPF into BGP -- matching and prepending

Redist. OSPF into BGP -- matching and prepending

OK. Here's the scenario:

Customer has two locations; let's call them 10 Main St. and 20 Main St. Customer has its own OSPF network which connects the two.

I have an MPLS network and am providing WAN connectivity to customer's many locations (not just those two). I use eBGP on the WAN.

Customer is tagging the routes with, let us say, "10" if they originate from

10 Main St and "20" if they originate from 20 Main St. What I want to do is advertise both sites of routes out of both locations, but do it in such a way that the 10 routes are preferred out of 10 and the 20 routes are preferred out of 20. I also want to filter them inbound from the WAN -- in other words, I never want my CE router at 10 to learn any routes that 20 is advertising out, and vice versa.

My initial thought was that I would prepend a private AS to the routes advertised out, and filter that private AS inbound (to avoid the looping), and set MEDs outbound such that 10 routes advertised out of 10 would have a MED of 100,

20 routes advertised out of 10 would have a MED of 200, 10 routes advertised out of 20 would have a MED of 200, and 20 routes advertised out of 20 would have a MED of 100. I tried this using an outbound route-map on my BGP neighbor statements, but evidently you cannot match tags on an outbound BGP route-map.

OK, not a big deal, I figured. Instead I tried this: when I redistribute routes from OSPF into BGP, I'd match the tags do prepending. So, for example, at 10 Main, any "20" tagged routes would have the private AS prepended TWICE, and the "10" tagged routes would have the private AS prepended once. The reverse at 20 Main.

No complaints from the router...but the prepending doesn't actually seem to be working at all. Now I get routes looping (in other words, at 20 Main I learn some "10" routes which I advertise out to the WAN, and 10 Main is picking those up via eBGP and ignoring the OSPF routes altogether) due to a route race condition. If I go to a third location and do a "show ip bgp" on any of the routes, the private AS isn't in the AS path at all.

Any ideas?

--chris

Reply to
Christopher Heer
Loading thread data ...

are you really sure of that? it's quite typical that MPLS routers speak iBGP to each other, except if you network is large and you have confederation borders, then you run eBGP at the border, but still iBGP within sub-AS.

it's a bit confusing. if routes belong to 10 Main St., then why should 20 Main St. advertise them. Is there some backdoor link between these locations that doesn't go via your MPLS cloud?

what should each CE learn then, only default?

if you indeed use confederations and try to prepend AS corresponding to one of the confederations, then it won't work as path along sub-AS's still considered as single AS (so they're equal). I have found that mapping tags to local-pref and community works very reliable; it's also very flexible to support virtually any IGP as long as it allows piggybacking tags to route advertisements. If you want to go down this road, then you need at least two tags and two communities that correspond to local-pref smaller than 100 and greater than 100. You construct a route-map for redistributing from your IGP to BGP to match tag and set both community and local-pref (community is necessary if you want to match these routes at the other end when they're redistributed back from BGP into some IGP). Next you need a route-map for performing reverse redistribution from BGP to IGP.

I'm really curious how does eBGP come here as usually PE run iBGP. If you provide a bit more details on what you trying to achieve (including ASCII network diagram and rough addressing plan), I might be able to help. PE-CE routing solutions that I've designed for our network are quite flexible to address most common scenarios, so we can try to match it to your problem.

Kind regards, iLya

Reply to
Charlie Root

Hello Charlie,

100% certain. All CE routers in our MPLS network run using a private AS (same on all in a region, but we have ASN override configured at the PERs so that one CE can see the routes originated by another) and the core runs a public AS. Config snippits below.

Exactly. So the idea is, we want the WAN link for 10 Main to be the preferred path for "10" routes and 20 Main to be the preferred route for "20" routes, but if either link goes down we want failover.

From the WAN, each CE should learn about other remote locations. But the

10 Main route shouldn't learn routes from 20 Main, and vice versa.

We're not using confederations, so I would expect the prepending to work. But I'm clearly missing something.

This might be feasable, although looking at the configs the customer appears to be setting community values for some other purpose I have yet to identify. So I shall have to tread carefully.

OK, diagram (apologies -- used to Visio!):

/----\\ /----\\ -|cust|--LAN--| 20 | --DS3--\\ / |rtr | OSPF \\----/ eBGP \\ | \\----/ ASN \\ [ Back ] 65400 \\ [ Door ] /-------\\ [ Link ] | MPLS | | | ASN | | | 100 | \\ /----\\ /----\\ \\-------/ -|cust|--LAN--| 10 | --DS3--/ \\ |rtr | OSPF \\----/ eBGP \\ \\----/ ASN \\--[ other remote sites ] 65400

10 and 20 are my CERs. For the sake of argument, let's assume the following IP addresses:

Cust LAN at 10: 192.168.1.1/30 CER LAN at 10: 192.168.1.2/30 CER WAN at 10: 172.16.1.2/30 PER WAN at 10: 172.16.1.1/30

Cust LAN at 20: 192.168.1.5/30 CER LAN at 20: 192.168.1.6/30 CER WAN at 20: 172.16.1.6/30 PER WAN at 20: 172.16.1.5/30

CER Config at 10:

router ospf 1 network 192.168.1.0 0.0.0.3 area 0 redistribute bgp 65400 metric 500 metric-type 1 subnets route-map bgp2ospf

router bgp 65400 network 192.168.1.0 mask 255.255.255.252 network 172.16.1.0 mask 255.255.255.252 redistribute ospf 1 match internal external 1 external 2 neighbor 172.16.1.1 remote-as 100 neighbor 172.16.1.1 soft-reconfiguration inbound neighbor 172.16.1.1 filter-list 1 in

ip as-path access-list 1 deny _65450_ ip as-path access-list 1 permit .*

route-map ospf2bgp permit 10 match tag 20 set as-path prepend 65450 65450

route-map ospf2bgp permit 20 match tag 10 set as-path prepend 65450

CER Config at 20:

router ospf 1 network 192.168.1.4 0.0.0.3 area 0 redistribute bgp 65400 metric 500 metric-type 1 subnets route-map bgp2ospf

router bgp 65400 network 192.168.1.4 mask 255.255.255.252 network 172.16.1.4 mask 255.255.255.252 redistribute ospf 1 match internal external 1 external 2 neighbor 172.16.1.5 remote-as 100 neighbor 172.16.1.5 soft-reconfiguration inbound neighbor 172.16.1.5 filter-list 1 in

ip as-path access-list 1 deny _65450_ ip as-path access-list 1 permit .*

route-map ospf2bgp permit 10 match tag 10 set as-path prepend 65450 65450

route-map ospf2bgp permit 20 match tag 20 set as-path prepend 65450

Sure seems like it ought to work to me...

--me

Reply to
Slade Wilson

Stupid newsreader. Attaching txt file for diagram.

Reply to
Slade Wilson

ah, it's PE-CE, I assumed it was PE-PE. Nevermind that comment that.

[...]

Ok. Last question to clarify the policy - what should be primary path between 10 and 20? Should they use their backdoor link, or should they go via MPLS? If primary communication path between these two sites should be via backdoor link, then it's all quite straight forward - mapping tags to community and setting respectively local-pref does job just fine. If on the other hand you want backdoor link to be backup for MPLS, then you most likely will have to resort to building OSPF sham-link between two CE. All this is only about communication between sites 10 Main St. and 20 Main St.; communication with other sites is so far irrelevant.

This is easily done by attaching some BGP community specific to this site and then blocking marked routes on PE when it builds updates towards CE.

Ok, it's clear with iBGP/eBGP. I'll run test with prepends one of these days, but for our own purpose I've found local-pref and community provide a bit more flexibility. If you don't mind, here I'll stick for a while to using local-pref (will let you know when I test prepends).

Does customer manage CE or do you? It won't harm if you add your communities (as opposed to overriding existing communities). And if you use community numbering in form :, you should be free from numbering collision.

The diagram is fine, was mainly to confirm my assumptions on the setup. I'll look closely at the addressing and configs that you've sent tomorrow and post possible route-maps. Sorry, gotta go now.

Kind regards, iLya

Reply to
Charlie Root

??

So, here are parts of the config that you could use. Two BGP communities will be used: 100:50 - request lower local-pref; and 100:1 - "routes belong to either 10 Main St. or 20 Main St.". Assume that OSPF routes are properly tagged (let's say tag 10010 for routes of 10 Main St., and 10020 for routes of 20 Main St.). On CE at 10 Main St. following route-map can be used for redistributing from OSPF to BGP:

route-map ospf2bgp perm 10 match tag 10020 set community 100:50 100:1 additive route-map ospf2bgp perm 20 set community 100:1 additive

Similar route-map for CE at 20 Main St., only difference is requesting lower local-pref for routes of 10 Main St.:

route-map ospf2bgp perm 10 match tag 10010 set community 100:50 100:1 additive route-map ospf2bgp perm 20 set community 100:1 additive

On each CE you apply above route-maps as follow:

! router bgp redistribute ospf route-map ospf2bgp !

On both PE now you can set lower local-pref for routes marked with community

100:50 as follow:

! ip community-list standard IS_BACKUP perm 100:50 ! route-map bgp-PE2CE-in perm 10 match community IS_BACKUP set local-pref 50 route-map bgp-PE2CE-in perm 20 !

For the updates from PE to CE you want to block routes marked with community

100:1 and pass everything else unmodified: ! ip community-list standard IS_MAIN_ST_SITE perm 100:1 ! route-map bgp-PE2CE-out deny 10 match community IS_MAIN_ST_SITE route-map bgp-PE2CE-out perm !

Attach these two route-maps to peering with CE: ! applied on each PE router bgp 100 address-family ipv4 vrf neighbor route-map bgp-PE2CE-in in neighbor route-map bgp-PE2CE-out out !

The only thing remains, is to make WAN link at each site to be primary only for this site. You can achieve this by using external Type I for routes redistributed from BGP into OSPF on CE:

router ospf 1 redistribute bgp metric-type 1 metric

Since for Type I routes metric accumulates link cost within OSPF domain as LSA goes through it, using Type I (instead of Type II) will let routers choose nearest exit. You need to choose value N so, that routers upto the border between 10 Main St. and 20 Main St. go via nearest exit. Most likely you will need to increase cost of link between these two sites to value larger than summary cost from inter-site OSPF router to CE at that site.

These solution should give you behaviour that you have asked for (assuming primary communication between sites should go via backdoor link and not via MPLS).

Kind regards, iLya

Reply to
Charlie Root

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.