cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1270
Views
5
Helpful
8
Replies

MPLS issues with redundant PE routers

alex.dersch
Level 4
Level 4

Hello,

i'd like to set up an mpls lab. the layout of the gear is attached (mpls.jpg) At site A i have to PE router R4 and R6 which should have knowledge of the network 10.0.129.0/24 from site B. Router R1 is configured as a route reflector. the configuration of R1, R4, R5 and R6 are attached as well.

with the configuration

Routing Table R6

O E2     10.0.129.0 [110/1] via 172.16.128.9, 00:04:37, FastEthernet0/1.200

Routing table R4

B        10.0.129.0 [200/11] via 150.1.5.5, 00:05:00

a traceroute shows the path goes through R4 instead direkt through R1

Tracing the route to 10.0.129.1

VRF info: (vrf in name/id, vrf out name/id)

  1 172.16.128.9 4 msec 0 msec 4 msec

  2 172.16.128.1 [MPLS: Labels 19/29 Exp 0] 96 msec 100 msec 96 msec

  3 150.1.0.2 [MPLS: Labels 19/29 Exp 0] 68 msec 64 msec 68 msec

  4 172.16.129.9 [MPLS: Label 29 Exp 0] 64 msec 64 msec 64 msec

  5 172.16.129.10 40 msec *  36 msec

show bgp vpnv4 unicast all 10.0.129.0 indicates an error

Rack1R6# show bgp vpnv4 unicast all 10.0.129.0

BGP routing table entry for 200:1:10.0.129.0/24, version 63

Paths: (1 available, best #1, table CENTRAL, RIB-failure(17) - next-hop mismatch)

  Not advertised to any peer

  Local

    150.1.5.5 (metric 67) from 150.1.1.1 (150.1.1.1)

      Origin incomplete, metric 11, localpref 100, valid, internal, best

      Extended Community: RT:200:1 OSPF DOMAIN ID:0x0005:0x000000C80200

        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.129.242:0

      Originator: 150.1.5.5, Cluster list: 150.1.1.1

      mpls labels in/out nolabel/29

Rack1R4#show bgp vpnv4 unicast all 10.0.129.0

BGP routing table entry for 200:1:10.0.129.0/24, version 146

Paths: (1 available, best #1, table CENTRAL)

  Not advertised to any peer

  Local

    150.1.5.5 (metric 67) from 150.1.1.1 (150.1.1.1)

      Origin incomplete, metric 11, localpref 100, valid, internal, best

      Extended Community: RT:200:1 OSPF DOMAIN ID:0x0005:0x000000C80200

        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.129.242:0

      Originator: 150.1.5.5, Cluster list: 150.1.1.1

      mpls labels in/out nolabel/29

any ideas what i have to do in order to have a redundant path towards site B?

thanks in advanced

Alex

2 Accepted Solutions

Accepted Solutions

Akash Agrawal
Cisco Employee
Cisco Employee

Hi Alex,

I think you still have redundancy via R6, but BGP route on R6 is not getting installed in routing table because it is having OSPF route with lesser AD value. If R4 goes down, R6 will loose OSPF route for 10.0.129.0/24 coming from R4, install BGP route ,redistribute this to OSPF and will advertise it to SW4.

Routing Table R6

O E2     10.0.129.0 [110/1] via 172.16.128.9, 00:04:37, FastEthernet0/1.200

Rack1R6# show bgp vpnv4 unicast all 10.0.129.0

BGP routing table entry for 200:1:10.0.129.0/24, version 63

Paths: (1 available, best #1, table CENTRAL, RIB-failure(17) - next-hop mismatch)

  Not advertised to any peer

  Local

    150.1.5.5 (metric 67) from 150.1.1.1 (150.1.1.1)

      Origin incomplete, metric 11, localpref 100, valid, internal, best

      Extended Community: RT:200:1 OSPF DOMAIN ID:0x0005:0x000000C80200

        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.129.242:0

      Originator: 150.1.5.5, Cluster list: 150.1.1.1

      mpls labels in/out nolabel/29

View solution in original post

Then change OSPF admin distance (above 200) to prefer iBGP routes on PE routers.

Router(config-router)#distance ospf

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

View solution in original post

8 Replies 8

Akash Agrawal
Cisco Employee
Cisco Employee

Hi Alex,

I think you still have redundancy via R6, but BGP route on R6 is not getting installed in routing table because it is having OSPF route with lesser AD value. If R4 goes down, R6 will loose OSPF route for 10.0.129.0/24 coming from R4, install BGP route ,redistribute this to OSPF and will advertise it to SW4.

Routing Table R6

O E2     10.0.129.0 [110/1] via 172.16.128.9, 00:04:37, FastEthernet0/1.200

Rack1R6# show bgp vpnv4 unicast all 10.0.129.0

BGP routing table entry for 200:1:10.0.129.0/24, version 63

Paths: (1 available, best #1, table CENTRAL, RIB-failure(17) - next-hop mismatch)

  Not advertised to any peer

  Local

    150.1.5.5 (metric 67) from 150.1.1.1 (150.1.1.1)

      Origin incomplete, metric 11, localpref 100, valid, internal, best

      Extended Community: RT:200:1 OSPF DOMAIN ID:0x0005:0x000000C80200

        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.129.242:0

      Originator: 150.1.5.5, Cluster list: 150.1.1.1

      mpls labels in/out nolabel/29

Hi Akash,

that's true, i just switched off the R4 and the route was installed properly in the routing table of R6.But it's not what i actually want. so no chance for load balancing?

regards

alex

blau grana
Level 7
Level 7

Hello Alex,

Delete capability vrf-lite from OSPF configuration on both PEs and you will see both PE to use BGP learned routes. I do not see any point to use capability vrf-lite in your scenario.

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

Hi,

i need the capability vrf-lite, i'll have more vrf's later.

regards

alex

Then change OSPF admin distance (above 200) to prefer iBGP routes on PE routers.

Router(config-router)#distance ospf

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

Thanks a lot, it's working now.

Harold Ritter
Level 12
Level 12

Hi Alex,

There is a few things I noticed while looking at your configurations. On R4 and R6 you redistribute between BGP and OSPF without any kind of filtering, which means routes received from BGP are redistributed in OSPF and these same routes could potentially be redistributed back into BGP on the other PE. It is usually best practice to put some kind of filtering in place when doing mutual redistribution.

As for the specific issues that you are seeing on R6, the rib(17) error code indicates that this route is already installed in the RIB from another protocol with a lower admin distance. The "next-hop mistmatch" means that the other route does not have the same next hop as the BGP learned route.

Would it be possible for you to provide us with the output of a "show ip route vrf CENTRAL 10.0.29.0 255.255.255.0".

Regards

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hello Harold,

here are the outputs

Rack1R4#show ip route vrf CENTRAL 10.0.129.0 255.255.255.0

Routing Table: CENTRAL

Routing entry for 10.0.129.0/24

  Known via "bgp 100", distance 200, metric 11, type internal

  Redistributing via ospf 200

  Advertised by ospf 200 subnets

  Last update from 150.1.5.5 02:19:17 ago

  Routing Descriptor Blocks:

  * 150.1.5.5 (default), from 150.1.1.1, 02:19:17 ago

      Route metric is 11, traffic share count is 1

      AS Hops 0

      MPLS label: 29

      MPLS Flags: MPLS Required

Rack1R4#

show ip route vrf CENTRAL 10.0.129.0

Routing Table: CENTRAL

Routing entry for 10.0.129.0/24

  Known via "ospf 200", distance 110, metric 1

  Tag Complete, Path Length == 1, AS 100, , type extern 2, forward metric 10

  Redistributing via bgp 100

  Last update from 172.16.128.9 on FastEthernet0/1.200, 02:19:52 ago

  Routing Descriptor Blocks:

  * 172.16.128.9, from 172.16.128.242, 02:19:52 ago, via FastEthernet0/1.200

      Route metric is 1, traffic share count is 1

      Route tag 3489661028

Rack1R6#