Re: Inter AS MPLS L3VPN Option C - ASBRs Peering BGP+Label

Can you please send the configs of

ASBR in first AS
ASBR in second AS
RR in AS1
RR in AS2

On 5 June 2014 12:51, Maarten Vervoorn <mr.vervoorn_at_gmail.com> wrote:

> Brain, Gaurav
>
> The other VRF's B and C have full connectivitys.
> I know when I configure next-hop unchanged on one of the VPNV4
> route-reflectors the issue is resolved and XR2 does impose its LDP
> transport label for R6. The only problem I have is that I cannot clalrify
> this behaviour.
> I thought that if I do not configure next hop unchanged all traffic will
> be passed through the RR it is not optimal I know but I want to understand
> what is happening. When next-hop unchanged is not configured and all
> traffic should flow over the RR vrf C and B have full connectvity only VRF
> A is not working. After analysing I can see that XR2 which is the RR for
> domain 2 has a Label in the LDP forwarding table for R2 (RR in domain1) but
> when I look in the MPLS forwarding table it has a pop label and therefor
> pops the first label from traffic and leaves the VPN label ad passes it to
> R6. R6 is not aware of this VPN label and drops the packet.
>
> Kind regards,
>
> Maarten Vervoorn
>
>
> 2014-06-05 9:14 GMT+02:00 GAURAV MADAN <gauravmadan1177_at_gmail.com>:
>
> Hello
>>
>> Although I dont have topo diagram to refer to your case ; I can just
>> summarize few points in option C :
>>
>> 1) next-hop-unchanged is required on RR in case they are falling in
>> forwarding paths
>> 2) LSP will be end to end .(across both AS , there is no change in
>> next-hop anywhere and hence single LSP)
>> 3) In case you have IOS<-> XR as your ASBRs then
>>
>> on ios side : send-label ( i belive mpls bgp fwd command will come
>> automatic)
>> on xr side : address-family labeled unicast AND a /32 static route
>>
>> If you can share topo and running configs ; I can have a look
>>
>> Regards
>> Gaurav Madan
>>
>> On 5 June 2014 12:38, Maarten Vervoorn <mr.vervoorn_at_gmail.com> wrote:
>>
>>> 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] <http://8.8.8.8/32%5BV%5D>
>>> 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] <http://10.10.10.10/32%5BV%5D>
>>> 2.2.2.2 1040
>>> >
>>> > 16010 26 10.10.104.0/24[V] <http://10.10.104.0/24%5BV%5D>
>>> 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] <http://8.8.8.8/32%5BV%5D>
>>> 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] <http://10.10.10.10/32%5BV%5D>
>>> 2.2.2.2 7280
>>> >
>>> > 16015 26 10.10.104.0/24[V] <http://10.10.104.0/24%5BV%5D>
>>> 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
>>>
>>> _______________________________________________________________________
>>> 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 - 13:00:49 ART