Solved: MPLS VPN with two CEs running OSPF area 0

Julio Garcia · ‎11-26-2011

Been having issues setting up mpls vpn -- specifically involving ospf running between PE's and CE's, the remote site routes dont appear to either of the CE routers.

Diagram is attached, both CEs are set up in ospf area 0 with the corresponding PE

I see the networks advertised by ospf to the respective PEs and are in the vrf routing tables.

PE1:

O 114.114.0.0 [110/2] via 172.31.10.14, 00:33:58, FastEthernet0/0.781

PE2:

O 115.115.0.0 [110/2] via 172.31.30.14, 00:33:44, FastEthernet0/1.781

Both Networks also appear in the MP-BGP table in Both PEs , seems VPN is working okay:

PE1:

Route Distinguisher: 3:4 (default for vrf D)

*> 114.114.0.0/16 172.31.10.14 2 32768 ?

*>i115.115.0.0/16 1.1.1.3 2 100 0 ?

PE2:

Route Distinguisher: 3:4 (default for vrf D)

*>i114.114.0.0/16 1.1.1.1 2 100 0 ?

*> 115.115.0.0/16 172.31.30.14 2 32768 ?

I also see the remote network in the ospf database for Area 0 in both CEs

CE1:

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
115.115.0.0 172.31.10.13 4 0x80000001 0x0030C0

CE2:

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
114.114.0.0 172.31.30.13 517 0x80000002 0x00BA23

But nothing in IP routing table of either , i assumed that they would show up in IP routing table as (IA) routes -- but dont see anything.

Would really appreciate if anyone can give me some pointers , relevant PE config below..

PE1:

!

ip vrf D

rd 3:4

route-target export 3:4

route-target import 3:4

!

interface FastEthernet0/0.781

encapsulation dot1Q 781

ip vrf forwarding D

ip address 172.31.10.13 255.255.255.252

no ip proxy-arp

ip ospf network point-to-point

!

router ospf 5 vrf D

log-adjacency-changes

redistribute bgp 10 subnets

network 172.31.10.12 0.0.0.3 area 0

!

router bgp 10

address-family ipv4 vrf D

redistribute ospf 5

no auto-summary

no synchronization

exit-address-family

PE-2:

!

ip vrf D

rd 3:4

route-target export 3:4

route-target import 3:4

!

interface FastEthernet0/1.781

encapsulation dot1Q 781

ip vrf forwarding D

ip address 172.31.30.13 255.255.255.252

ip ospf network point-to-point

router ospf 5 vrf D

log-adjacency-changes

redistribute bgp 10 subnets

network 172.31.30.12 0.0.0.3 area 0

router bgp 10

address-family ipv4 vrf D

redistribute ospf 5

no auto-summary

no synchronization

exit-address-family

Peter Paluch · ‎11-26-2011

Hey Rob,

Hmmm... Can you please try configuring this command on the CE1 in the OSPF process running over the VRF?

router ospf 1

capability vrf-lite

In theory, it shoud not help but just to be sure... The point is that if an OSPF process is run in a VRF, it considers itself to be connected to the MPLS Superbackbone (a concept of OSPF/BGP cooperation in MPLS L3 VPNs). In other words, it considers itself to be an ABR. That causes reachability issues with inter-area networks because an ABR processes only those LSA-3 that are received from area 0. Also, it causes reachability issues with external networks because when BGP redistributes them from a VRF into OSPF, they get the "Down" bit set and as a result, they are ignored by other OSPF routers that also consider themselves to be connected to the MPLS Superbackbone to avoid redistribution loops.

The funny thing is that neither of these limitations should apply to you - you are running your routers in area 0 so the limitation about LSA-3 should not apply, and you do not indicate seeing the remote networks as LSA-5 but rather as LSA-3, so the Down bit should not apply, neither. In any case, let us make sure that I haven't overlooked anything in this logic.

Please try configuring that command on CE1, give the router some time and re-check the routing table if the network appears. If it does, ... I am going to press you for more information how that is possible, and if it does not, well, I will need to press you for more information as well

Best regards,

Peter

EDIT: The red lines claim incorrect facts and shall be considered as provably wrong. Please see my response below for corrected information. My sincere apologies for publishing misleading information!

View solution in original post

Peter Paluch · ‎11-26-2011

Hi Rob,

Are you perhaps using VRFs and OSPF within these VRFs on CE routers as well? That could theoretically cause some reachability issues, although they would be more pronounced with external routes or if the area was different from area 0. Just checking...

In addition, can you please issue the following command on CE1 and post the result here?

show ip ospf database summary 115.115.0.0

Thank you!

Best regards,

Peter

Julio Garcia · ‎11-26-2011

Hi Peter,

Thank you very much for the reply

You are right , i am using vrf lite on the CE edges just so i could keep the routing tables on the CEs a bit separate.

here is the output of the command on CE1:

show ip ospf database summary 115.115.0.0

OSPF Router with ID (199.0.0.1) (Process ID 10)

OSPF Router with ID (172.31.10.14) (Process ID 1)

Summary Net Link States (Area 0)

LS age: 553
Options: (No TOS-capability, DC, Downward)
LS Type: Summary Links(Network)
Link State ID: 115.115.0.0 (summary Network Number)
Advertising Router: 172.31.10.13
LS Seq Number: 80000002
Checksum: 0x2EC1
Length: 28
Network Mask: /16
TOS: 0 Metric: 2

Peter Paluch · ‎11-26-2011

Hey Rob,

Hmmm... Can you please try configuring this command on the CE1 in the OSPF process running over the VRF?

router ospf 1

capability vrf-lite

In theory, it shoud not help but just to be sure... The point is that if an OSPF process is run in a VRF, it considers itself to be connected to the MPLS Superbackbone (a concept of OSPF/BGP cooperation in MPLS L3 VPNs). In other words, it considers itself to be an ABR. That causes reachability issues with inter-area networks because an ABR processes only those LSA-3 that are received from area 0. Also, it causes reachability issues with external networks because when BGP redistributes them from a VRF into OSPF, they get the "Down" bit set and as a result, they are ignored by other OSPF routers that also consider themselves to be connected to the MPLS Superbackbone to avoid redistribution loops.

The funny thing is that neither of these limitations should apply to you - you are running your routers in area 0 so the limitation about LSA-3 should not apply, and you do not indicate seeing the remote networks as LSA-5 but rather as LSA-3, so the Down bit should not apply, neither. In any case, let us make sure that I haven't overlooked anything in this logic.

Please try configuring that command on CE1, give the router some time and re-check the routing table if the network appears. If it does, ... I am going to press you for more information how that is possible, and if it does not, well, I will need to press you for more information as well

Best regards,

Peter

EDIT: The red lines claim incorrect facts and shall be considered as provably wrong. Please see my response below for corrected information. My sincere apologies for publishing misleading information!

Julio Garcia · ‎11-26-2011

Hi Peter,

Thank you for the amazing help , works now after the vrf-lite command put in

very much appreciated!

Peter Paluch · ‎11-26-2011

Rob,

I take back what I wrote because that is a gross inaccuracy. The capability vrf-lite should help in your case

Quoting from

http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_osp1.html#wp1012376

Table 1 PE Checks Performed
Type-3 LSA received	The DN bit is checked. If the DN bit is set, the Type-3 LSA is not considered during the shortest path first (SPF) calculation.
Type-5 or -7 LSA received	If the Tag in the LSA is equal to the VPN-tag, the Type-5 or-7 LSA is not considered during the SPF calculation.

So for LSA-3, the Down flag (also shown in your output) is what counts, and for external LSAs, the route tag is important.

I apologize for publishing misleading information before.

Best regards,

Peter

Julio Garcia · ‎11-26-2011

Thanks once again for the explanation -- have a great weekend.