11-05-2010 12:32 PM
This is driving me insane, it's not a difficult problem, I have a loopback in the VRF on both cores, configurations were copy and pasted to ensure they were identical, BGP peer's are up, redistribution is working fine, but I cannot ping between the loopbacks!
I have 2 6509's, connected with a 802.1q trunk
Configuration:
ip vrf Testing
rd 111:1
route-target both 111:1
int vlan 400
ip address 10.65.65.2 255.255.255.0
mpls ip
int loopback 0
ip address 10.65.64.255
router eigrp 64
no auto-summary
network 10.0.0.0 0.31.255.255
network 10.32.0.0 0.15.255.255
network 10.48.0.0 0.7.255.255
network 10.64.0.0 0.63.255.255
network 10.128.0.0 0.127.255.255
address-family ipv4 vrf Testing
no auto-summary
network 10.0.0.0 0.31.255.255
network 10.32.0.0 0.15.255.255
network 10.48.0.0 0.7.255.255
network 10.64.0.0 0.63.255.255
network 10.128.0.0 0.127.255.255
default-metric 10000 100 255 1 1500
autonomous 111
redistribute bgp 65064
router bgp 65064
no auto-summ
no synch
network 0.0.0.0
neighbor R peer-group
neighbor R remote-as 65064
neighbor R update-source loop 0
neighbor 10.65.64.254 peer-group R
address-family vpnv4
neighbor 10.65.64.254 peer-group R
neighbor R send-community both
address-family ipv4 vrf Testing
no auto-summ
no synch
redistribute eigrp 111
int loopback 99
ip vrf forward Testing
ip address 10.111.1.1 255.255.255.0
Router 1:
show ip bgp neighbor:
BGP neighbor is 10.65.64.254, remote AS 65064, internal link
Member of peer-group R for session parameters
BGP version 4, remote router ID 10.65.64.254
BGP state = Established, up for 03:36:33
For address family: VPNv4 Unicast
BGP table version 10, neighbor version 10/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
R peer-group member
Community attribute sent to this neighbor
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 2 1 (Consumes 68 bytes)
show ip route vrf Testing:
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
C 10.111.2.0 is directly connected, Loopback99
C 10.111.22.0 is directly connected, Loopback98
B 10.111.1.0 [200/0] via 10.65.64.254, 03:38:30
show mpls ldp neigh:
Peer LDP Ident: 10.65.64.254:0; Local LDP Ident 10.65.64.255:0
TCP connection: 10.65.64.254.646 - 10.65.64.255.36970
State: Oper; Msgs sent/rcvd: 793/795; Downstream
Up time: 02:12:39
LDP discovery sources:
Vlan400, Src IP addr: 10.65.65.3
Router 2:
show ip bgp neighbor:
BGP neighbor is 10.65.64.255, remote AS 65064, internal link
Member of peer-group R for session parameters
BGP version 4, remote router ID 10.65.64.255
BGP state = Established, up for 03:39:34
For address family: VPNv4 Unicast
BGP table version 10, neighbor version 10/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
R peer-group member
Community attribute sent to this neighbor
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 1 2 (Consumes 136 bytes)
Prefixes Total: 1 3
Implicit Withdraw: 0 1
Explicit Withdraw: 0 0
Used as bestpath: n/a 2
Used as multipath: n/a 0
show ip route vrf Testing:
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
B 10.111.2.0 [200/0] via 10.65.64.255, 03:41:22
B 10.111.22.0 [200/0] via 10.65.64.255, 02:35:31
C 10.111.1.0 is directly connected, Loopback99
From router 2:
R2#ping vrf Testing 10.111.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.111.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R2#ping vrf Testing 10.111.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.111.2.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Solved! Go to Solution.
11-08-2010 07:23 AM
Hello again,
R1#show ip cef vrf Testing 10.111.1.1 detail
10.111.1.0/24, epoch 3, flags rib defined all labels
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
recursive via 10.65.64.254 label 26
nexthop 10.64.1.254 Port-channel1 unusable: no label <--- !!
So, you have the vpnv4 route and the prefix. But, the recursion to the IGP global route
and the associated label failed in producing an MPLS label. This usually means that
MPLS is broken in the core/global context across the outgoing interface.
What does the following give you?
show ip route 10.65.64.254
show ip cef 10.65.64.254
show running interf Port-channel1
show mpls ldp disc
show mpls ldp neighbor
Thanks,
Luc
11-05-2010 01:21 PM
Hello,
post a show module
be aware that not all hardware combinations on C6500 support MPLS full features: for example, you need SUP720BXL or better the sup720B or Base is not eligible for MPLS services.
This can result in lack of connectivity in the forwarding plane
Hope to help
Giuseppe
11-05-2010 01:34 PM
Thanks for the reply! Here is the output of the show mod, looks like I am running the VS720 3C model, which does support MPLS.
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 16 16 port 1000mb GBIC ethernet WS-X6416-GBIC SAL0603GPJZ
2 16 16 port 1000mb GBIC ethernet WS-X6416-GBIC SAL0603GQ4T
4 48 48-port 10/100/1000 RJ45 EtherModule WS-X6148A-GE-45AF SAL1432QAFS
5 5 Supervisor Engine 720 10GE (Active) VS-S720-10G SAL1317NVA2
6 0 2 port adapter Enhanced FlexWAN WS-X6582-2PA JAE1353T7OV
7 0 2 port adapter Enhanced FlexWAN WS-X6582-2PA JAE115182E9
9 48 48 port 10/100/1000mb EtherModule WS-X6148-GE-45AF SAL1306JB8F
Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
1 0008.207a.0728 to 0008.207a.0737 2.0 5.4(2) 8.7(0.22)BUB Ok
2 0008.207a.0c68 to 0008.207a.0c77 2.0 5.4(2) 8.7(0.22)BUB Ok
4 f866.f2b2.5f20 to f866.f2b2.5f4f 4.1 8.4(1) 8.7(0.22)BUB Ok
5 0023.33ab.2608 to 0023.33ab.260f 3.1 8.5(3) 12.2(33)SXH7 Ok
6 8843.e129.3080 to 8843.e129.30bf 2.4 12.2(33)SXH7 12.2(33)SXH7 Ok
7 001e.7a5b.b400 to 001e.7a5b.b43f 2.3 12.2(33)SXH7 12.2(33)SXH7 Ok
9 0024.c40f.7908 to 0024.c40f.7937 8.2 7.2(1) 8.7(0.22)BUB Ok
Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
4 IEEE Voice Daughter Card WS-F6K-48-AF SAL1432Q5J7 2.5 Ok
5 Policy Feature Card 3 VS-F6K-PFC3C SAL1321QE3K 1.0 Ok
5 MSFC3 Daughterboard VS-F6K-MSFC3 SAL1319PRPG 1.1 Ok
9 IEEE Voice Daughter Card WS-F6K-48-AF SAL1306J1QX 2.3 Ok
Mod Online Diag Status
---- -------------------
1 Pass
2 Pass
4 Pass
5 Pass
6 Pass
7 Pass
9 Pass
11-08-2010 05:28 AM
Hi,
Can you ping with specifying the source IP address of the loopback in the VRF?
Let's have a look at this output:
show ip bgp vpnv4 all labels
show mpls forwarding detail
show mpls interface detail
show ip cef vrf Testing 10.111.1.1 detail
on both routers (reversing the IP address for that last command)
Thanks,
Luc
11-08-2010 06:50 AM
Thanks for the reply, even with specifying a source address within the VRF I am unable to successfully ping.
R1#show ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 111:1 (Testing)
10.111.1.0/24 10.65.64.254 nolabel/26
10.111.2.0/24 0.0.0.0 IPv4 VRF Aggr:26/nolabel(Testing)
10.111.22.0/24 0.0.0.0 IPv4 VRF Aggr:26/nolabel(Testing)
The forwarding detail is actually a large output (several hundred interfaces active on this router), so I grabbed the Testing VRF and a random label:
26 Pop Label IPv4 VRF[V] 0 aggregate/Testing
MAC/Encaps=0/0, MRU=0, Label Stack{}
VPN route: Testing
No output feature configured
31 No Label 10.6.16.0/24 0 Po1 10.64.1.254
MAC/Encaps=14/14, MRU=1504, Label Stack{}
0024509DE8000023EA356C000800
No output feature configured
Per-destination load-sharing, slots: 0 4 8 12
No Label 10.6.16.0/24 0 Vl488 10.66.80.3
MAC/Encaps=14/14, MRU=1504, Label Stack{}
0024509DE8000023EA356C000800
No output feature configured
Per-destination load-sharing, slots: 1 5 9 13
No Label 10.6.16.0/24 0 Vl493 10.66.85.3
MAC/Encaps=14/14, MRU=1504, Label Stack{}
0024509DE8000023EA356C000800
No output feature configured
Per-destination load-sharing, slots: 2 6 10 14
No Label 10.6.16.0/24 0 Vl505 10.66.97.3
MAC/Encaps=14/14, MRU=1504, Label Stack{}
0024509DE8000023EA356C000800
No output feature configured
Per-destination load-sharing, slots: 3 7 11 15
R1#show mpls int detail
Interface Vlan400:
IP labeling enabled (ldp)
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1500
R1#show ip cef vrf Testing 10.111.1.1 detail
10.111.1.0/24, epoch 3, flags rib defined all labels
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
recursive via 10.65.64.254 label 26
nexthop 10.64.1.254 Port-channel1 unusable: no label
R2#show ip bgp vpnv4 all labels
Network Next Hop In label/Out label
Route Distinguisher: 111:1 (Testing)
10.111.1.0/24 0.0.0.0 IPv4 VRF Aggr:26/nolabel(Testing)
10.111.2.0/24 10.65.64.255 nolabel/26
10.111.22.0/24 10.65.64.255 nolabel/26
26 Pop Label IPv4 VRF[V] 0 aggregate/Testing
MAC/Encaps=0/0, MRU=0, Label Stack{}
VPN route: Testing
No output feature configured
37 No Label 10.6.124.0/24 0 Se7/1/1 point2point
MAC/Encaps=4/4, MRU=4474, Label Stack{}
0F000800
No output feature configured
R2#show mpls int detail
Interface Vlan400:
IP labeling enabled (ldp)
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1500
R2#show ip cef vrf Testing 10.111.2.1 detail
10.111.2.0/24, epoch 5, flags rib defined all labels
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
recursive via 10.65.64.255 label 26
nexthop 10.64.1.253 Port-channel1 unusable: no label
11-08-2010 07:23 AM
Hello again,
R1#show ip cef vrf Testing 10.111.1.1 detail
10.111.1.0/24, epoch 3, flags rib defined all labels
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
recursive via 10.65.64.254 label 26
nexthop 10.64.1.254 Port-channel1 unusable: no label <--- !!
So, you have the vpnv4 route and the prefix. But, the recursion to the IGP global route
and the associated label failed in producing an MPLS label. This usually means that
MPLS is broken in the core/global context across the outgoing interface.
What does the following give you?
show ip route 10.65.64.254
show ip cef 10.65.64.254
show running interf Port-channel1
show mpls ldp disc
show mpls ldp neighbor
Thanks,
Luc
11-08-2010 07:36 AM
You are right on the money, right after I posted that, I went to figure out why port-channel 1 was showing no label, and I wasn't running a port-channel between my cores! I added mpls ip to the port-channel interface going into my datacenter and it worked like a charm! Thanks for the help in getting me there! That show ip cef vrf command definitely did it!
Craig
11-08-2010 11:25 AM
After I added the mpls ip to the port-channel interface and did my testing, I thought about why my data path wasn't the path I expected it to be. We upgraded our backbone to ten gig two weeks ago, the port channel properly scaled, but the trunk port between the cores did not scale to the VLAN's, the VLAN's still have a default speed of 1gig, so the EIGRP believes the optimal path to the other core is through my datacenter instead of the directly connected link.
Thanks again for your help!
Craig
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide