Solved: Re: OSPF for redundancy (CE) to 2 PE's

johnelliot · ‎10-28-2006

Hi,

We have a client with 2 connections (1 Ethernet + 1 ATM(SHDSL) - The connections terminate on 2 seperate PE's - We have OSPF advertising the clients LAN subnet into there VRF via the ethernet connection(And we adv default route), we now wanted to bring the ATM(SHDSL) connection on, and have OSPF somehow ensure that the ethernet connection is used as primary, and SHDSL as secondary - If both tails terminated on the one PE it wouldn't be a problem...hoping someone has suggestions on the best way to achieve this.

(Traffic egress from client is functioning correctly(i.e. Going via PE1 primary, and PE2 if PE1 is down), ingress is not to the clients LAN subnet)

I've tried adding a higher ospf metric to the atm int on PE2, but this did not force traffic destined to the clients LAN sub. to go via PE1

PE1 (Primary eth terminates here)

router ospf 16 vrf MFS

log-adjacency-changes

passive-interface default

no passive-interface Port-channel1.995

network 10.10.9.4 0.0.0.3 area 16

default-information originate metric 100

address-family ipv4 vrf MFS

redistribute connected

redistribute static

redistribute ospf 16 vrf MFS match external 2

default-information originate

no synchronization

PE2

router ospf 16 vrf MFS

log-adjacency-changes

passive-interface default

no passive-interface ATM1/0.207

network 10.10.9.0 0.0.0.3 area 16

default-information originate metric 110

address-family ipv4 vrf MFS

redistribute connected

redistribute static

redistribute ospf 16 vrf MFS match external 2

default-information originate

no synchronization

CE

router ospf 16

router-id 10.10.9.5

log-adjacency-changes

redistribute connected subnets

passive-interface default

no passive-interface FastEthernet0/1.1

no passive-interface ATM0/0/0.1

swaroop.potdar · ‎10-29-2006

To get the traffic coming in from PE towards your CE only via your primary link, you can try any of the below two options.

1) Use BGP as the PE-CE protocol and manipulate the outgoing MED to make the PE prefer the right link for incoming traffic.

2) If you want to stick with OSPF without much changes then, just go to the router ospf process of PE2 where your backup link is coming. and make this modification

=========

PE2

!

router ospf 16 vrf MFS

log-adjacency-changes

passive-interface default

no passive-interface ATM1/0.207

network 10.10.9.0 0.0.0.3 area 16

<<<<<< distance ospf external 210 >>>>>>>

This line would take care of the incoming traffic and all traffic will come in through the PE1 and when its down will come in through the PE2.

default-information originate metric 110

!

=====================

HTH-Cheers,

Swaroop

View solution in original post

swaroop.potdar · ‎10-29-2006

To get the traffic coming in from PE towards your CE only via your primary link, you can try any of the below two options.

1) Use BGP as the PE-CE protocol and manipulate the outgoing MED to make the PE prefer the right link for incoming traffic.

2) If you want to stick with OSPF without much changes then, just go to the router ospf process of PE2 where your backup link is coming. and make this modification

=========

PE2

!

router ospf 16 vrf MFS

log-adjacency-changes

passive-interface default

no passive-interface ATM1/0.207

network 10.10.9.0 0.0.0.3 area 16

<<<<<< distance ospf external 210 >>>>>>>

This line would take care of the incoming traffic and all traffic will come in through the PE1 and when its down will come in through the PE2.

default-information originate metric 110

!

=====================

HTH-Cheers,

Swaroop

johnelliot · ‎10-30-2006

Excellent! - Thanks Swaroop....worked nicely.

johnelliot · ‎11-03-2006

Hi Swaroop,

I may have been a little hasty in saying it worked - As the CE is in production, I only performed a few tests of the failover - Last night, the ethernet service was bought down for ~1hour - After the link came back up, traffic to the 192.168.9.0/24 network is still going via the PE2(Via SHDSL):

PE2:

#sh ip bgp vpnv4 vrf MFS

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 17766:16 (default for vrf MFS)

*> 10.10.9.0/30 0.0.0.0 0 32768 ?

r>i10.10.9.4/30 PE1_IP 0 100 0 ?

* i192.168.9.0 PE1_IP 20 100 0 ?

*> 10.10.9.2 20 32768 ?

I'm getting a rib failure for 10.10.9.4 (Which is the p-t-p ethernet link from PE1->CE) - but I do have a route for 192.168.9.0/24 via both PE's

#sh ip route vrf MFS

O E2 192.168.9.0/24 [240/20] via 10.10.9.2, 04:32:38, ATM1/0.207

OSPF *appears* to have the correct info(i.e. 192.168.9.0/24 is via 10.10.9.5) :

#sh ip ospf 16 database

OSPF Router with ID (10.10.9.1) (Process ID 16)

Router Link States (Area 16)

Link ID ADV Router Age Seq# Checksum Link count

10.10.9.1 10.10.9.1 1239 0x8000001C 0x00C6B8 2

10.10.9.5 10.10.9.5 518 0x800000D8 0x00D4CB 3

10.10.9.6 10.10.9.6 491 0x800000D0 0x008152 1

Net Link States (Area 16)

Link ID ADV Router Age Seq# Checksum

10.10.9.6 10.10.9.6 491 0x8000002B 0x005730

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 10.10.9.1 1239 0x8000001B 0x00543D 3489678694

0.0.0.0 10.10.9.6 491 0x800002A1 0x00D6A3 16

192.168.9.0 10.10.9.5 518 0x800000BE 0x004FFE 0

192.168.101.25 10.10.9.5 518 0x800000BE 0x005C7C 0

PE1:

#sho ip bgp vpnv4 vrf MFS

r>i10.10.9.0/30 PE2_IP 0 100 0 ?

*> 10.10.9.4/30 0.0.0.0 0 32768 ?

* i192.168.9.0 PE2_IP 20 100 0 ?

*> 10.10.9.5 20 32768 ?

#sho ip route vrf MFS

O E2 192.168.9.0/24 [150/20] via 10.10.9.5, 04:37:56, Port-channel1.995

#sho ip ospf 16 database

OSPF Router with ID (10.10.9.6) (Process ID 16)

Router Link States (Area 16)

Link ID ADV Router Age Seq# Checksum Link count

10.10.9.1 10.10.9.1 1564 0x8000001C 0x00C6B8 2

10.10.9.5 10.10.9.5 841 0x800000D8 0x00D4CB 3

10.10.9.6 10.10.9.6 812 0x800000D0 0x008152 1

Net Link States (Area 16)

Link ID ADV Router Age Seq# Checksum

10.10.9.6 10.10.9.6 812 0x8000002B 0x005730

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 10.10.9.1 1564 0x8000001B 0x00543D 3489678694

0.0.0.0 10.10.9.6 812 0x800002A1 0x00D6A3 16

192.168.9.0 10.10.9.5 841 0x800000BE 0x004FFE 0

192.168.101.25 10.10.9.5 841 0x800000BE 0x005C7C 0

swaroop.potdar · ‎11-04-2006

Hi John,

Is the requirement for sites of the same VPN termiateing on PE2 itself to reach via PE1, and if PE1 down then via PE2. Just checking if I understood the requirement correctly.

1) You are seeing a RIB failure for routes which are reachable via IGP but which are installed in the BGP best path. You can ignore it as its not by error but for primary and secondary its done knowingly.

2) Add this line on PE2

!

address-family ipv4 vrf MFS

redistribute ospf 16 vrf MFS match external x metric 200 !<--This line will take care of remote PE's trying to reach the LAN.

distance ospf external 240 !--->would take care of same VPN customers on PE2 to reach via PE1.

!

--------------------------

OT-PS: I also wanted to clear the previous couple of posts, for which lets look at this topoogy.

Remote PoPs : PE3, PE4 , n...

Remote PoPs : PE5, PE6, n....

Core Location : PE1, PE2.

Only in the case when the core location redundant PE's are made RR's as well ( which is not recommended as RR's should never be in the forwadring plane) then you cannot use only metric or MED based maipuation.

IBGP mesh peering would be like, PE3 and PE4 RR clients of PE1 and PE5 and PE6 RR clients of PE2, and we have redundant connections termiating on our Core side, PE1 and PE2 with IBGP between PE1 and PE2. So in this case even though its a BGP mesh its no more a matter or question of BGP.

Sometimes I feel I think wild, :-)...doesnt matter...

HTH-Cheers,

Swaroop

swaroop.potdar · ‎11-04-2006

If you have a digram with ip addressing, this can be simulated for you. So the config given is more aptly mapped to your situation.

HTH-Cheers,

Swaroop

johnelliot · ‎11-12-2006

Hi Swaroop - Apologies for the delay in replying, I have been away on holidays.

I attempted to implement your suggested conf, but I do not have an 'ospf' option in:

distance ospf external 240

I only have:

#distance ?

<1-255> Administrative distance

bgp BGP distance

I am running 12.3(15) (c7200-p-mz.123-15)

Really appreciate your assistance with this!

mheusinger · ‎10-30-2006

Hi,

this is basically a BGP question as I understand it. Your other PE routers pick PE2 as BGP next hop and thus the traffic does not exit the primary PE1, right? If this is the case, you could use local preference or modify MED to achieve the desired primary/backup scenario.

Hope this helps! Please rate all posts.

Regards, Martin

swaroop.potdar · ‎10-30-2006

Hi Martin,

THe original poster has a problem with incoming traffic towards the CE, and his PE-CE protocol is OSPF, so how can the incoming interface be manipulated or choosen using MED or Local Pref.

Just a thought.

HTH-Cheers,

Swaroop

mheusinger · ‎10-31-2006

Hi Swaroop,

I was thinking the problem looks like this

CEotherLoc-PEotherLoc - MPLS cloud - PE1/PE2 - CE with redundant connection to PE1 and PE2

In this case the PEotherLoc (or a BGP RR) will decide through BGP path selection which path to pick, either through PE1 or through PE2. Once traffic is arriving there at f.e. PE2 label switched it will be forwarded out to CE. So in this scenario BGP will decide, what is primary and what is backup. You can influence this by modifying MED, or LocPref. MED can also be adjusted through a different OSPF metric, as it is copied to MED during redistribution.

This is why I was refering to BGP and possible path selection adjustments.

Regards, Martin

swaroop.potdar · ‎11-01-2006

Hi Martin,

The topology is correct as per your assumption.

But we cannot infulence which IBGP nexthop we prefer using MED or local pref, as for MPLS VPN's the next hop decisions are taken based on global IPV4 BGP, and if we change the local Pref of a certain next-hop then that PE would always be preferred as primary between those two PE's.

And the MED value introduced while OSPF<-->BGP redis would be locally specific to that VRF and cannot infuence, the Next Hop decision globally.

All this apart, again MED and Local-Pref based manipulation can be achieved if our PE-CE protocol is also BGP, or I believe it may not work.

HTH-Cheers,

Swaroop

mheusinger · ‎11-01-2006

Hi Swaroop,

Unfortunately I do disagree with your statements regarding "next hop selection". The next hop selected is always the next hop in the best VPNv4 BGP update for a VPNv4 prefix. And for VPNv4 the same BGP path selection criteria apply as for any other address-family. So MED and Local Preference will lead to a difference. MED and Local Preference are also part of a VPNv$ BGP update and can be set per prefix (through a route-map). There is no need to set them per PE neighbor.

MED will be set during OSPF (or any other IGP) to BGP redistribution and WILL have an influence on a per prefix basis.

Regards, Martin

swaroop.potdar · ‎11-01-2006

Hi Martin,

I think, our assumptions have some deviation.

I will send you a mail offline detailing my assumed topology and why the same cannot be used.

As this thread here upon may not be useful or helpful to the group.

HTH-Cheers,

Swaroop