BGP MPLS PING ISSUE

[Ammartehsein]

CUSTOMER SITE NOT ABLE TO PING SITE 2, even routes are advertised properly via mpls bgp. I am pinging using loopback 10.10.10.1 as source from site 1.as you see below 10.10.10.0 network is received on other end

PE1 vrd routing table:

PE1#sh ip route vrf Riyadh-branch

Routing Table: Riyadh-branch
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/30 is directly connected, Ethernet1/0
L 1.1.1.2/32 is directly connected, Ethernet1/0
2.0.0.0/30 is subnetted, 1 subnets
B 2.2.2.0 [200/0] via 90.90.90.2, 01:14:58
10.0.0.0/24 is subnetted, 1 subnets
B 10.10.10.0 [20/0] via 1.1.1.1, 02:10:24
20.0.0.0/24 is subnetted, 1 subnets
B 20.20.20.0 [200/0] via 90.90.90.2, 01:14:58

PE-2 vrf routing table:

PE2#sh ip route vrf
PE2#sh ip route vrf Jeddah-branch

Routing Table: Jeddah-branch
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 70.70.70.1, 00:56:50
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/30 is directly connected, Ethernet1/0
L 2.2.2.2/32 is directly connected, Ethernet1/0
10.0.0.0/24 is subnetted, 1 subnets
B 10.10.10.0 [200/0] via 70.70.70.1, 00:56:50
20.0.0.0/24 is subnetted, 1 subnets
B 20.20.20.0 [20/0] via 2.2.2.1, 00:56:50

Cust site-1 routing table:

Cust-1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/30 is directly connected, Ethernet1/0
L 1.1.1.1/32 is directly connected, Ethernet1/0
2.0.0.0/30 is subnetted, 1 subnets
B 2.2.2.0 [20/0] via 1.1.1.2, 00:54:00
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.10.10.0/24 [200/0] via 0.0.0.0, 01:41:56, Null0
C 10.10.10.1/32 is directly connected, Loopback1
20.0.0.0/24 is subnetted, 1 subnets
B 20.20.20.0 [20/0] via 1.1.1.2, 00:54:00

Cust site-2 routing table:

Cust-2#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 2.2.2.2, 00:54:13
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/30 is directly connected, Ethernet1/0
L 2.2.2.1/32 is directly connected, Ethernet1/0
10.0.0.0/24 is subnetted, 1 subnets
B 10.10.10.0 [20/0] via 2.2.2.2, 00:54:13
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 20.20.20.0/24 [200/0] via 0.0.0.0, 01:44:39, Null0
C 20.20.20.1/32 is directly connected, Loopback1

[Harold Ritter]

Hi @MHM Cisco World ,

No need for AS override, as the two CEs are in different ASN. Also, if you check the original post, the loopback from each CE is learnt on the opposite CE, The issue is the VPNv4 session established using the physical interface instead of the loopback interface. This breaks the end to end LSP between the two PEs.

Regards,

[MHM Cisco World]

He have many issue in lab

1- redistrubte connect <<- this solve

2- both site use AS 100 so he need override or allowas-in <<- he need to confirming he solve it or not

3- the next-hop of ibgp LO' this I think he need to use mask/32 not other mask' since global IGP is ospf and it adverise LO with /32 where in real it /30'to solve this he need to use /32 LO for ibgp (mpls label issue can arise from this issue)

MHM

[Harold Ritter]

Hi @MHM Cisco World ,

> 1- redistrubte connect <<- this solve

This is only required if he pings from the PE.

> 2- both site use AS 100 so he need override or allowas-in <<- he need to confirming he solve it or not

As I mentioned, the initial post shows that the two CEs received the loopback interface IP address from the opposite CE.

> 3- the next-hop of ibgp LO' this I think he need to use mask/32 not other mask' since global IGP is ospf and it adverise LO with    > /32 where in real it /30'to solve this he need to use /32 LO for ibgp (mpls label issue can arise from this issue)

The issue is that he used the physical interface address rather than the loopback interface address for the iBGP VPNv4 session. 

Regards,

[MHM Cisco World]

Ok' he use interface not LO and I dont know rule prevent that except' he use ""mpls ip"" under interface use as next-hop of ibgp vpnv4.

If he can remove LO and return use interface without mpls ip' I think it work.

And why mpls ip under interface make issue that another story.

For AS100 in same sites' I really dont get how it work but later after I finished my course of sdwan I will try do some search about this point.

MHM

[Harold Ritter]

Hi @MHM Cisco World ,

> Ok' he use interface not LO and I dont know rule prevent that 

Please refer to the explanation I provided to the OP about why using the physical interface breaks the end to end LSP and why it recommended to always use the loopback interface for the VPNv4 session.

> For AS100 in same sites' I really dont get how it work

The diagram provided shows site 1 using AS100 and site 2 using AS300, although the configurations provided for PE1 and PE2 show AS100 being used on both sides. The OP seems to have fixed it, as routes are being propagated between the CE. 

Regards,

[MHM Cisco World]

You  can not use mpls ip under LO that why Engineer recommend use it since there is no chance for error.

And as I mentioned before he can use physical interface if that interface not use mpls ip.

He can check it' but I think he dont interesting to check.

Have a nice day

MHM

[Harold Ritter]

Hi @MHM Cisco World ,

The issue here is that he is using the physical interfaces that are shared between PE1 and P1 and PE2 and P2. That is what is leading to the broken LSPs.

It is safer to follow the recommendation to use the loopback interface.

Regards,

[Harold Ritter · Accepted solution]

Hi @Ammartehsein ,

You should use the PE loopback interface to establish the VPNv4 session between the two PEs. Also make sure the loopback interface is advertised by ospf.

This should solve the issue.

Regards,

[Ammartehsein]

It worked with loopback neighbourship, But why ? Can you give explanation thanks

[Harold Ritter]

Hi @Ammartehsein ,

Using the physical interface breaks the end to end LSP between PE1 and PE2, which causes the L3VPN traffic to be blackholed.

PE1 for example uses 90.90.90.2 as the next hop for traffic destined to 20.20.20.1. P2 advertises an implicit label for prefix 90.90.90.0/30, as it is directly connected to this subnet.  This causes the LSP to 90.90.90.2 to stop at P2 rather than PE2. This breaks the end to end LSP between PE1 and PE2. 

This is why it is strongly recommended to use the loopback address for the VPNv4 session. In recent IOS versions, you even receive a warning message if you don't.

Regards,

[Giuseppe Larosa]

Thanks @Harold Ritter yiou are always some giiant steps before me I hope all is well for you and yiour familly at Mexico City.

Trabajo en Milan in the same compnany since July 2019

Best Regards

Giusepee

[Harold Ritter]

Thanks for the king words @Giuseppe Larosa . I am doing well. Hope you are doing well too my friend.