Routing

Hej

I am having a bit of problem with bringing Shamlink up on one of my PEs.

I have a 4 PE setup interconnecting 3 customer sites.
-->R3 and R4 are connected to the same Customer site
-->R6
-->R8

The problem is at R4, which only establishes shamlink with R3 which it has connection through the same customer site. Whereas 3 establishes Shamlink with all Rs and R6/8 have shamlink with each other and R3

All Rs have the R4's VRF loopback IP 172.30.5.21/32 in their route table learned through BGP. R4 routes are imported into each other R but routes

Shamlink 1 = R4

Oscar-Lab-R3# run show ospf neighbor instance CE1 
Address Interface State ID Pri Dead
192.168.0.70 ge-1/1/3.318 Full 172.31.63.2 128 33
172.30.5.37 shamlink.0 Full 172.30.5.37 0 34
172.30.5.21 shamlink.1 Full 172.30.5.21 0 33
172.30.5.29 shamlink.2 Full 172.30.5.29 0 33

Oscar-Lab-R4# run show ospf neighbor instance CE1 
Address Interface State ID Pri Dead
192.168.0.74 ge-1/1/4.319 Full 172.31.63.3 128 34
172.30.5.17 shamlink.0 Full 172.30.5.17 0 34

Oscar-Lab-R6# run show ospf neighbor instance CE1 
Address Interface State ID Pri Dead
192.168.0.86 ge-1/1/6.322 Full 172.31.63.4 128 35
172.30.5.17 shamlink.0 Full 172.30.5.17 0 35
172.30.5.37 shamlink.2 Full 172.30.5.37 0 3

Oscar-Lab-R8# run show ospf neighbor instance CE1 
Address Interface State ID Pri Dead
192.168.0.94 ge-1/1/8.324 Full 172.31.63.1 128 38
172.30.5.17 shamlink.0 Full 172.30.5.17 0 36
172.30.5.29 shamlink.2 Full 172.30.5.29 0 39

{master}[edit routing-instances CE1 protocols ospf]
odj@test3R1dk:Oscar-Lab-R4# show 
export bgp-to-ospf;
sham-link local 172.30.5.21;
area 0.0.0.0 {
sham-link-remote 172.30.5.17 metric 100; >>>>>>R3
sham-link-remote 172.30.5.29; >>>>>>>>>>>>>>>>>>R6
sham-link-remote 172.30.5.37; >>>>>>>>>>>>>>>>>>R8
interface ge-1/1/4.319;
interface lo0.141;
}

It looks like R4 is sending hello messages to all R3-6-8 but only absorbing R3 and local CE peer. The two messages peerat themselves. The IPs are R3, and Customer peer.

Nov 7 22:21:33.971384 OSPF restart signaling: set L bit in hellos sent on interface shamlink.0.
Nov 7 22:21:33.971412 OSPF sent Hello 172.30.5.21 -> 172.30.5.17 (shamlink.0 IFL 2147549184 area 0.0.0.0)
Nov 7 22:21:33.971498 OSPF restart signaling: Add LLS data for Hello packet on interface shamlink.0.
Nov 7 22:21:33.972321 OSPF restart signaling: set L bit in hellos sent on interface shamlink.1.
Nov 7 22:21:33.972361 OSPF sent Hello 172.30.5.21 -> 172.30.5.29 (shamlink.1 IFL 2147549185 area 0.0.0.0)
Nov 7 22:21:33.972448 OSPF restart signaling: Add LLS data for Hello packet on interface shamlink.1.
Nov 7 22:21:33.972481 OSPF restart signaling: set L bit in hellos sent on interface shamlink.2.
Nov 7 22:21:33.972510 OSPF sent Hello 172.30.5.21 -> 172.30.5.37 (shamlink.2 IFL 2147549186 area 0.0.0.0)
Nov 7 22:21:33.973766 OSPF restart signaling: Add LLS data for Hello packet on interface shamlink.2.

But it is only absorbing R3 and Local CE peer

Nov  7 22:21:33.969965 OSPF hello from 172.30.5.17 (IFL 2684341140, area 0.0.0.0) absorbed
Nov  7 22:21:33.970148 OSPF hello from 192.168.0.74 (IFL 2684341140, area 0.0.0.0) absorbed

In contrast for example R6 absorbs hello from R3-6-8 and local CE peer

Nov 7 22:22:51.194933 OSPF hello from 172.30.5.17 (IFL 2684341140, area 0.0.0.0) absorbed
Nov 7 22:22:54.161435 OSPF hello from 192.168.0.86 (IFL 2684341140, area 0.0.0.0) absorbed
Nov 7 22:22:55.239672 OSPF hello from 172.30.5.37 (IFL 2684341140, area 0.0.0.0) absorbed
Nov 7 22:21:33.970148 OSPF hello from 192.168.0.74 (IFL 2684341140, area 0.0.0.0) absorbed

Appreciate any advice
Regards
Oscar

If you disable R3 completely. Will R4 to R6 and R4 to R8 sham link come up?

Can you confirm R6 and R8 are sending hellos to R4? also you can try specifying a metric on R2 for the sham-links towards R6 and R8

Hej

When I disable R3 the R4 still does not establish any shamlinks with R6 and R8

When I check >show ospf route instance CE1 on R4 I do not see routes for Shamlink even from R3.

However, on R3 I see routes from R4 shamlink

R6 and R8 both send hello messages for the shamlink

As the configuration is not completely given here, I assume that the sham-link local and remote addresses are those of the VRF loopback interface, right? I also assume that the IP addresses of these loopback interfaces are announced via MP-BGP to the remote PE - just to rule out that you have a simple connectivity problem.

If so, please remove the lo0.141-interface from the OSPF area 0 configuration stanca and just keep it in the VRF config.

Cheers,

Carsten

If you disbale R3, you are still seeing same behavior on R4, that means mostly issue on R4 config. And there's nothing related to dual-homing.

Also you mentioned R6 and R8 sending hellos as expected. 

I'd suggest to past config on R3 and R4 and check what's the difference

Hej

Loo.141 is loopback specific to that VRF, main instance uses lo0.0. Each Router is configured the same way.

The problem does indeed look like a routing problem.

Even though each router have the VRF loopback address in their routing tables, R6 and R8 can not ping R4 VRF Loopback even when R3 is active/deactive

{master}[edit]
odj@test3pe1dk:Oscar-Lab-R3# run show route 172.30.5.0/24 table CE1.inet.0 | no-more 

CE1.inet.0: 23 destinations, 44 routes (23 active, 0 holddown, 5 hidden)
+ = Active Route, - = Last Active, * = Both

172.30.5.17/32     *[Direct/0] 10:37:10
                    > via lo0.131
172.30.5.21/32     *[BGP/170] 10:37:29, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.22 via ge-1/1/3.134, Push 50
                      to 172.30.0.22 via ge-1/1/3.134, Push 50
172.30.5.29/32     *[BGP/170] 10:38:20, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.22 via ge-1/1/3.134, label-switched-path Q
                      to 172.30.0.13 via ge-1/1/3.123, label-switched-path Bypass->172.30.0.22
172.30.5.37/32     *[BGP/170] 10:38:20, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.13 via ge-1/1/3.123, label-switched-path J
                      to 172.30.0.22 via ge-1/1/3.134, label-switched-path L
                      to 172.30.0.22 via ge-1/1/3.134, label-switched-path Bypass->172.30.0.13->172.30.0.1

odj@test3pe1dk:Oscar-Lab-R4# run show route 172.30.5.0/24 table CE1.inet.0 | no-more 

CE1.inet.0: 28 destinations, 45 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.30.5.17/32     *[BGP/170] 10:26:09, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.21 via ge-1/1/4.134, Push 54
                      to 172.30.0.21 via ge-1/1/4.134, Push 54
172.30.5.21/32     *[Direct/0] 10:37:30
                    > via lo0.141
172.30.5.29/32     *[BGP/170] 10:26:09, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                      to 172.30.0.21 via ge-1/1/4.134, Push 16
                    > to 172.30.0.30 via ge-1/1/4.145, Push 16
172.30.5.37/32     *[BGP/170] 10:26:09, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.5 via ge-1/1/4.114, Push 16
                      to 172.30.0.30 via ge-1/1/4.145, Push 16

odj@test3pe1dk:Oscar-Lab-R6# run show route 172.30.5.0/24 table CE1.inet.0 | no-more 

CE1.inet.0: 27 destinations, 54 routes (23 active, 0 holddown, 16 hidden)
+ = Active Route, - = Last Active, * = Both

172.30.5.17/32     *[BGP/170] 10:37:10, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.33 via ae1.156, label-switched-path R
                      to 172.30.0.25 via ge-1/1/6.136, label-switched-path Bypass->172.30.0.33
172.30.5.21/32     *[BGP/170] 10:37:29, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.33 via ae1.156, Push 50
                      to 172.30.0.25 via ge-1/1/6.136, Push 50
172.30.5.29/32     *[Direct/0] 11:15:18
                    > via lo0.161
172.30.5.37/32     *[BGP/170] 11:12:03, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.33 via ae1.156, Push 16, Push 31(top)
                      to 172.30.0.33 via ae1.156, Push 16, Push 31(top)
                      to 172.30.0.42 via ge-1/1/6.167, Push 16, Push 24(top)
                      to 172.30.0.42 via ge-1/1/6.167, Push 16, Push 24(top)

odj@test3pe1dk:Oscar-Lab-R8# run show route 172.30.5.0/24 table CE1.inet.0 | no-more 

CE1.inet.0: 23 destinations, 50 routes (23 active, 0 holddown, 12 hidden)
+ = Active Route, - = Last Active, * = Both

172.30.5.17/32     *[BGP/170] 10:37:10, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.9 via ge-1/1/8.118, label-switched-path I
                      to 172.30.0.45 via ge-1/1/8.178, label-switched-path K
                      to 172.30.0.45 via ge-1/1/8.178, label-switched-path Bypass->172.30.0.9->172.30.0.2
172.30.5.21/32     *[BGP/170] 10:37:29, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                    > to 172.30.0.9 via ge-1/1/8.118, Push 50
                      to 172.30.0.37 via ge-1/1/8.158, Push 50
172.30.5.29/32     *[BGP/170] 11:12:03, localpref 100, from 172.30.5.41
                      AS path: I, validation-state: unverified
                      to 172.30.0.37 via ge-1/1/8.158, Push 16, Push 29(top)
                      to 172.30.0.37 via ge-1/1/8.158, Push 16, Push 29(top)
                    > to 172.30.0.45 via ge-1/1/8.178, Push 16, Push 25(top)
                      to 172.30.0.45 via ge-1/1/8.178, Push 16, Push 25(top)
172.30.5.37/32     *[Direct/0] 11:15:18
                    > via lo0.181

Regards

Oscar

Yes, it looks like a routing problem. But with the limited output you provided, it is really hard to debug. Especially as you seem to use a mix of LDP- and RSVP-based LSPs. In addition, output indicates that there is a route reflector (172.30.5.41) involved as well which was not mentioned. Would be really beneficial to see the configs of all system.

Cheers,

Carsten

The output is really limited. Maybe you should try to create RSVP LSP from R4 to R3/R6/R8

@Mhu: Setting RSVP with R6 and R8 brought up the Shamlink.

Although still not sure on the reason.  I can ping both R6 and R8 normal loopbacks through IGP and all VRF loopbacks were advertised within the VRFs before LSP.

I can provide full config on the devices but there is alot of stuff going on in the config since I lab lots of different stuff at it.