Hi Brian,
Thanks for helping me.
The link for EBGP+Labels is between R1 and XR1 just like your example
video. This is the link is 10.10.101.0/24 (R1 .1 and XR1 .19). The host
route should then be present on XR1 right? R1 is IOS so it will
automatically do that for you. XR2 is the route reflector which has a EBGP
VPNV4 connection to R2. I have not created an host route on XR2 Anywhay
Below are the routing tabels of R1, XR1 and R6 and XR2.
R1:
R1#sh ip route | b Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
i L2 2.2.2.2 [115/30] via 10.10.13.3, 00:10:36, Ethernet0/0
3.0.0.0/32 is subnetted, 1 subnets
i L2 3.3.3.3 [115/20] via 10.10.13.3, 00:10:36, Ethernet0/0
4.0.0.0/32 is subnetted, 1 subnets
i L2 4.4.4.4 [115/30] via 10.10.13.3, 00:10:36, Ethernet0/0
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/12] via 10.10.101.19, 00:07:36
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.10.13.0/24 is directly connected, Ethernet0/0
L 10.10.13.1/32 is directly connected, Ethernet0/0
i L2 10.10.23.0/24 [115/20] via 10.10.13.3, 00:10:36, Ethernet0/0
i L2 10.10.34.0/24 [115/20] via 10.10.13.3, 00:10:36, Ethernet0/0
C 10.10.101.0/24 is directly connected, Ethernet0/1.101
L 10.10.101.1/32 is directly connected, Ethernet0/1.101
C 10.10.101.19/32 is directly connected, Ethernet0/1.101
20.0.0.0/32 is subnetted, 1 subnets
B 20.20.20.20 [20/12] via 10.10.101.19, 00:07:36
XR1:
RP/0/0/CPU0:XR1#sh route | b Gateway
Sat May 17 05:12:05.060 UTC
Gateway of last resort is not set
B 2.2.2.2/32 [20/30] via 10.10.101.1, 00:08:18
B 4.4.4.4/32 [20/30] via 10.10.101.1, 00:08:18
O 5.5.5.5/32 [110/12] via 10.10.196.6, 00:09:19,
GigabitEthernet0/0/0/0.196
O 6.6.6.6/32 [110/2] via 10.10.196.6, 00:09:19,
GigabitEthernet0/0/0/0.196
O 10.10.56.0/24 [110/11] via 10.10.196.6, 00:09:19,
GigabitEthernet0/0/0/0.196
C 10.10.101.0/24 is directly connected, 00:09:20,
GigabitEthernet0/0/0/0.101
S 10.10.101.1/32 is directly connected, 00:09:20,
GigabitEthernet0/0/0/0.101
L 10.10.101.19/32 is directly connected, 00:09:20,
GigabitEthernet0/0/0/0.101
C 10.10.196.0/24 is directly connected, 00:09:20,
GigabitEthernet0/0/0/0.196
L 10.10.196.19/32 is directly connected, 00:09:20,
GigabitEthernet0/0/0/0.196
O 10.10.206.0/24 [110/11] via 10.10.196.6, 00:09:19,
GigabitEthernet0/0/0/0.196
L 19.19.19.19/32 is directly connected, 00:09:20, Loopback1
O 20.20.20.20/32 [110/12] via 10.10.196.6, 00:08:59,
GigabitEthernet0/0/0/0.196
R6:
R6#sh ip route | b Gateway
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/1] via 10.10.196.19, 00:08:57, Ethernet0/0.196
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/1] via 10.10.196.19, 00:08:57, Ethernet0/0.196
5.0.0.0/32 is subnetted, 1 subnets
O 5.5.5.5 [110/11] via 10.10.56.5, 00:11:32, Ethernet0/0.56
6.0.0.0/32 is subnetted, 1 subnets
C 6.6.6.6 is directly connected, Loopback1
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.10.56.0/24 is directly connected, Ethernet0/0.56
L 10.10.56.6/32 is directly connected, Ethernet0/0.56
C 10.10.196.0/24 is directly connected, Ethernet0/0.196
L 10.10.196.6/32 is directly connected, Ethernet0/0.196
C 10.10.206.0/24 is directly connected, Ethernet0/0.206
L 10.10.206.6/32 is directly connected, Ethernet0/0.206
19.0.0.0/32 is subnetted, 1 subnets
O 19.19.19.19 [110/11] via 10.10.196.19, 00:09:53, Ethernet0/0.196
20.0.0.0/32 is subnetted, 1 subnets
O 20.20.20.20 [110/11] via 10.10.206.20, 00:09:33, Ethernet0/0.206
XR2:
RP/0/0/CPU0:XR2#sh ip route | b Gateway
Wed Jun 4 23:13:52.736 UTC
Gateway of last resort is not set
O E2 2.2.2.2/32 [110/1] via 10.10.206.6, 00:10:56,
GigabitEthernet0/0/0/0.206
O E2 4.4.4.4/32 [110/1] via 10.10.206.6, 00:10:56,
GigabitEthernet0/0/0/0.206
O 5.5.5.5/32 [110/12] via 10.10.206.6, 00:11:38,
GigabitEthernet0/0/0/0.206
O 6.6.6.6/32 [110/2] via 10.10.206.6, 00:11:38,
GigabitEthernet0/0/0/0.206
O 10.10.56.0/24 [110/11] via 10.10.206.6, 00:11:38,
GigabitEthernet0/0/0/0.206
O 10.10.196.0/24 [110/11] via 10.10.206.6, 00:11:38,
GigabitEthernet0/0/0/0.206
C 10.10.206.0/24 is directly connected, 00:11:46,
GigabitEthernet0/0/0/0.206
L 10.10.206.20/32 is directly connected, 00:11:46,
GigabitEthernet0/0/0/0.206
O 19.19.19.19/32 [110/12] via 10.10.206.6, 00:11:38,
GigabitEthernet0/0/0/0.206
L 20.20.20.20/32 is directly connected, 00:11:46, Loopback1
Kind regards,
Maarten Vervoorn
2014-06-05 1:05 GMT+02:00 Brian McGahan <bmcgahan_at_ine.com>:
> Is 10.10.206.0 the link that the EBGP + Label peering is established on?
> If so, what is XR2's route to 10.10.206.6? It needs to be a host route in
> order to perform the MPLS encapsulation. Post the "show ip route" from R6
> and XR2.
>
> Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
> bmcgahan_at_INE.com
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Maarten Vervoorn
> Sent: Wednesday, June 04, 2014 2:53 PM
> To: Cisco certification
> Subject: Inter AS MPLS L3VPN Option C - ASBRs Peering BGP+Label
>
> Hi all,
>
> I'm studying for CCIE service provider with the INE all access pass. After
> watching the video about:"Inter AS MPLS L3VPN Option C - ASBRs Peering
> BGP+Label " I build the lab my self-according to the same diagram used
> BGP+in
> the video with the exact same setup. I tried to follow the movie as much
> as possible to learn the technology. I started with the configuration where
> the traffic still flows over the route reflector so the ebgp peers still
> are changing the next-hop vaue. That is where my issueis. The control plane
> is correct I received all routes in all VRFb s The dataplane for VRF B and
> C is also correct because I can reach the loopback addresses within the VRF.
> However the dataplane of VRF A is not working. I cannot reach the loopback
> address. I have researched the issue and found out where the problem is and
> how I can resolve it. However I failed to figure out exactly why this
> behavior is like this so maybe you can help me out here.
>
> *I have enable: debug mpls packet on all IOS routers and found out that
> the path from R10 to R8 is okay the ICMP packets arrived at R8*
>
> R10#ping 8.8.8.8 source lo 1
>
> Type escape sequence to abort.
>
> Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
>
> Packet sent with a source address of 10.10.10.10
>
> .....
>
> Success rate is 0 percent (0/5)
>
>
>
> R8#
>
> *May 15 08:38:12.787: ICMP: echo reply sent, src 8.8.8.8, dst 10.10.10.10,
> topology BASE, dscp 0 topoid 0
>
> R8#
>
> *May 15 08:38:14.787: ICMP: echo reply sent, src 8.8.8.8, dst 10.10.10.10,
> topology BASE, dscp 0 topoid 0
>
> R8#
>
> *May 15 08:38:16.789: ICMP: echo reply sent, src 8.8.8.8, dst 10.10.10.10,
> topology BASE, dscp 0 topoid 0
>
> R8#
>
> *May 15 08:38:18.794: ICMP: echo reply sent, src 8.8.8.8, dst 10.10.10.10,
> topology BASE, dscp 0 topoid 0
>
> R8#
>
> *May 15 08:38:20.793: ICMP: echo reply sent, src 8.8.8.8, dst 10.10.10.10,
> topology BASE, dscp 0 topoid 0
>
> R8#
>
>
>
> *At the debug mpls packet on R6 I can see the traffic returning from R8,
> XR2 did not send a transport label*
>
> R6#
>
> *May 15 08:40:33.025: MPLS les: Et0/0.196: rx: Len 1514 Stack {16 0 251}
> {16001 0 254} - ipv4 data s:10.10.10.10 d:8.8.8.8 ttl:254 tos:0 prot:1
>
> *May 15 08:40:33.025: MPLS les: Et0/0.206: tx: Len 1510 Stack {16001 0 250}
> - ipv4 data s:10.10.10.10 d:8.8.8.8 ttl:254 tos:0 prot:1
>
> *May 15 08:40:33.027: MPLS les: Et0/0.206: rx: Len 1514 Stack {25 0 254} -
> ipv4 data s:8.8.8.8 d:10.10.10.10 ttl:254 tos:0 prot:1
>
> R6#
>
> *May 15 08:40:35.027: MPLS les: Et0/0.196: rx: Len 1514 Stack {16 0 251}
> {16001 0 254} - ipv4 data s:10.10.10.10 d:8.8.8.8 ttl:254 tos:0 prot:1
>
> *May 15 08:40:35.027: MPLS les: Et0/0.206: tx: Len 1510 Stack {16001 0 250}
> - ipv4 data s:10.10.10.10 d:8.8.8.8 ttl:254 tos:0 prot:1
>
> *May 15 08:40:35.029: MPLS les: Et0/0.206: rx: Len 1514 Stack {25 0 254} -
> ipv4 data s:8.8.8.8 d:10.10.10.10 ttl:254 tos:0 prot:1
>
>
>
> *When I look into the vpnv4 table on XR2 I can see it is using a VPN label
> 25 with a next-hop of 2.2.2.2*
>
> RP/0/0/CPU0:XR2#sh bgp vpnv4 unicast vrf A 10.10.10.10
>
> BGP routing table entry for 10.10.10.10/32, Route Distinguisher: 100:1
>
> Versions:
>
> Process bRIB/RIB SendTblVer
>
> Speaker 337 337
>
> Local Label: 16009
>
> Last Modified: May 14 07:23:21.885 for 00:03:37
>
> Paths: (1 available, best #1)
>
> Advertised to peers (in unique update groups):
>
> 5.5.5.5
>
> Path #1: Received by speaker 0
>
> Advertised to peers (in unique update groups):
>
> 5.5.5.5
>
> 1
>
> 2.2.2.2 (metric 1) from 2.2.2.2 (2.2.2.2)
>
> Received Label 25
>
> Origin incomplete, localpref 100, valid, external, best, group-best,
> import-candidate, imported
>
> Received Path ID 0, Local Path ID 1, version 337
>
> Extended community: OSPF domain-id:0x5:0x000000020200 OSPF
> route-type:0:2:0x0 OSPF router-id:10.10.104.4 RT:100:1
>
> Source VRF: A, Source Route Distinguisher: 100:1
>
> RP/0/0/CPU0:XR2#
>
>
>
> *When I look into the forwarding table I noticed that destination 2.2.2.2
> has pop as outgoing label to 6.6.6.6 so it indeed does not send a
> transport label. This is what I cannot figure out why this is*
>
> RP/0/0/CPU0:XR2#sh mpls forwarding
>
> Wed May 14 07:29:50.367 UTC
>
> Local Outgoing Prefix Outgoing Next Hop Bytes
>
> Label Label or ID Interface Switched
>
> ------ ----------- ------------------ ------------ ---------------
> ------------
>
> 16000 Aggregate A: Per-VRF Aggr[V] A 0
>
> 16001 Unlabelled 8.8.8.8/32[V] Gi0/0/0/0.208 10.10.208.8 81840
>
> 16002 Pop 6.6.6.6/32 Gi0/0/0/0.206 10.10.206.6 6830
>
> 16003 Pop 10.10.56.0/24 Gi0/0/0/0.206 10.10.206.6 0
>
> 16004 Pop 10.10.196.0/24 Gi0/0/0/0.206 10.10.206.6 0
>
> 16005 18 5.5.5.5/32 Gi0/0/0/0.206 10.10.206.6 7370
>
> 16006 17 19.19.19.19/32 Gi0/0/0/0.206 10.10.206.6 0
>
> 16007 Pop 2.2.2.2/32 Gi0/0/0/0.206 10.10.206.6 3215
>
> 16008 20 4.4.4.4/32 Gi0/0/0/0.206 10.10.206.6 4860
>
> 16009 25 10.10.10.10/32[V] 2.2.2.2 1040
>
> 16010 26 10.10.104.0/24[V] 2.2.2.2 0
>
> 16011 21 100:2:10.10.115.0/24 \
>
> 5.5.5.5 0
>
> 16012 22 100:2:11.11.11.11/32 \
>
> 5.5.5.5 0
>
> 16013 23 100:3:10.10.125.0/24 \
>
> 5.5.5.5 0
>
> 16014 24 100:3:12.12.12.12/32 \
>
> 5.5.5.5 0
>
> *When I look into R6 MPLS forwarding table it does not say it is local but
> has a local label of 19 (so why is XR2 not have label 19 into its
> forwarding table)*
>
> R6#sh mpls forwarding-table
>
> Local Outgoing Prefix Bytes Label Outgoing Next Hop
>
> Label Label or Tunnel Id Switched interface
>
> 16 Pop Label 20.20.20.20/32 96772 Et0/0.206
> 10.10.206.20
>
> 17 Pop Label 19.19.19.19/32 0 Et0/0.196
> 10.10.196.19
>
> 18 Pop Label 5.5.5.5/32 9229 Et0/0.56 10.10.56.5
>
> 19 16000 2.2.2.2/32 36336 Et0/0.196
> 10.10.196.19
>
> 20 16001 4.4.4.4/32 68130 Et0/0.196
> 10.10.196.19
>
>
>
> *I have cleared all process even reloaded all routers but this did not help
> *
>
> *After that I decided to configure the next-hop unchanged command on the
> route reflectors and somehow this fixed the issue for VRF A to make it work
> for the other VRFb s I needed to redistribute the other PE loopbacks into
> the core IGP so they would also receive labels. This change also changed
> the MPLS forwarding table on XR2 in such way that it had a label for R2. I
> cannot related the next-hop unchanged feature to changing the LDP behavior
> it only ensures it does not change the next hop to its own address. Below
> is the BGP configuration of XR2*
>
> RP/0/0/CPU0:XR2#sh runn router bgp
>
> Wed May 14 07:36:07.721 UTC
>
> router bgp 2
>
> address-family ipv4 unicast
>
> !
>
> address-family vpnv4 unicast
>
> !
>
> neighbor 2.2.2.2
>
> remote-as 1
>
> ebgp-multihop 255
>
> update-source Loopback1
>
> address-family vpnv4 unicast
>
> route-policy PASS in
>
> route-policy PASS out
>
> !
>
> !
>
> neighbor 5.5.5.5
>
> remote-as 2
>
> update-source Loopback1
>
> address-family vpnv4 unicast
>
> route-policy PASS in
>
> route-reflector-client
>
> route-policy PASS out
>
> !
>
> !
>
> vrf A
>
> rd 100:1
>
> address-family ipv4 unicast
>
> redistribute ospf main
>
> !
>
> !
>
> !
>
> * When at the XR2 MPLS forwarding table it is different then the mpls ldp
> forwarding table. I caanot indetify where the pop label comes from in the
> mpls forwarding table. The mpls LDP forwarding table and binding table
> shows the correct label. The router however installes a pop label into the
> mpls forwarding table.*
>
> RP/0/0/CPU0:XR2#sh mpls ldp forwarding
> Wed May 14 12:58:52.225 UTC
>
> Codes:
> - = GR label recovering, (!) = LFA FRR pure backup path
> {} = Label stack with multi-line output for a routing path
> G = GR, S = Stale, R = Remote LFA FRR backup
>
> Prefix Label Label(s) Outgoing Next Hop
> Flags
> In Out Interface G S
> R
> --------------- ------- -------------- ------------ -------------------
> -----
> 2.2.2.2/32 16007 19 Gi0/0/0/0.206 10.10.206.6
> 4.4.4.4/32 16008 20 Gi0/0/0/0.206 10.10.206.6
> 5.5.5.5/32 16005 18 Gi0/0/0/0.206 10.10.206.6
> 6.6.6.6/32 16002 ImpNull Gi0/0/0/0.206 10.10.206.6
> 10.10.56.0/24 16003 ImpNull Gi0/0/0/0.206 10.10.206.6
> 10.10.196.0/24 16004 ImpNull Gi0/0/0/0.206 10.10.206.6
> 19.19.19.19/32 16006 17 Gi0/0/0/0.206 10.10.206.6
>
>
> XR2 has no labels within BGP for ipv4 only for vpnv4. It the option C
> example in the stage where R2 and XR2 still does not have the next-hop
> unchange feature enabled and the traffic should flow via XR2 and R2 BGP
> labels are only exchange between XR1 and R1. XR1 is redistributing the
> routes into the IGP (OSPF in this case) because it is the IGP LDP should
> generate the labels so XR2 should have the label from LDP and it has only
> it does not install them.
>
>
> Also the strange thing if I also distribute R4b s loopback with the same
> technology it does have a label from LDP only R2 show strange behavior
> which I cannot clarify.
>
>
>
> RP/0/0/CPU0:XR2#sh mpls forwarding
>
> Thu May 15 09:56:26.496 UTC
>
> Local Outgoing Prefix Outgoing Next Hop Bytes
>
> Label Label or ID Interface Switched
>
> ----- ----------- ------------------ ------------ ---------------
> ------------
>
> 16001 Unlabelled 8.8.8.8/32[V] Gi0/0/0/0.208 10.10.208.8 7440
>
> 16002 Pop 6.6.6.6/32 Gi0/0/0/0.206 10.10.206.6 146640
>
> 16003 17 19.19.19.19/32 Gi0/0/0/0.206 10.10.206.6 0
>
> 16004 Pop 10.10.196.0/24 Gi0/0/0/0.206 10.10.206.6 0
>
> 16005 Pop 2.2.2.2/32 Gi0/0/0/0.206 10.10.206.6 133952
>
> 16006 Pop 10.10.56.0/24 Gi0/0/0/0.206 10.10.206.6 0
>
> 16007 19 5.5.5.5/32 Gi0/0/0/0.206 10.10.206.6 180691
>
> *16008 18 4.4.4.4/32 <http://4.4.4.4/32> Gi0/0/0/0.206
> 10.10.206.6 0*
>
> 16009 Aggregate A: Per-VRF Aggr[V] A 0
>
> 16010 22 100:2:10.10.115.0/24 \
>
> 5.5.5.5 0
>
> 16011 23 100:2:11.11.11.11/32 \
>
> 5.5.5.5 0
>
> 16012 24 100:3:10.10.125.0/24 \
>
> 5.5.5.5 0
>
> 16013 25 100:3:12.12.12.12/32 \
>
> 5.5.5.5 52220
>
> 16014 25 10.10.10.10/32[V] 2.2.2.2 7280
>
> 16015 26 10.10.104.0/24[V] 2.2.2.2 0
>
>
>
>
> Can you please help me clear this up.Thanks in advance
>
>
>
> Maarten Vervoorn
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Thu Jun 05 2014 - 09:08:05 ART
This archive was generated by hypermail 2.2.0 : Tue Jul 01 2014 - 06:32:35 ART