Solved: TDP label distribution

bjornarsb · ‎02-08-2007

We are running MPLS on a cisco 1841 cpe router. But we cannot see any labels at the core router. We are running TDP as mpls label distribution protocol.

172.25.31.111

Peer TDP Ident: 172.25.32.221:0; Local TDP Ident 172.25.32.12:0

TCP connection: 172.25.32.221.32787 - 172.25.32.12.711

State: Oper; PIEs sent/rcvd: 8/8; ; Downstream

Up time: 00:00:06

TDP discovery sources:

ATM6/0.75, Src IP addr: 10.250.32.14

Addresses bound to peer TDP Ident:

10.250.32.14 172.25.32.221

RU9612#

RU9612#sh tag-switching tdp neighbor

!

interface ATM6/0.75 point-to-point

description ADSL_til_ASKO_Drammen_60355011

bandwidth 1024

ip address 10.250.32.13 255.255.255.252

ip mtu 1500

ip ospf network broadcast

atm route-bridged ip

pvc ASKO21DRAMMEN 253/75

ubr 1216

oam-pvc manage

encapsulation aal5snap

!

tag-switching mtu 1516

tag-switching ip

end

RU9612#

CPE:

!

interface FastEthernet0/1

bandwidth 1024

ip address 10.250.32.14 255.255.255.252

duplex auto

speed auto

mpls label protocol both

mpls ip

mpls mtu 1516

traffic-shape rate 1024000 102400 0 1000

!

ru214#sh tag-switching tdp nei

ru214#sh tag-switching tdp neighbor

Peer TDP Ident: 172.25.32.12:0; Local TDP Ident 172.25.32.221:0

TCP connection: 172.25.32.12.711 - 172.25.32.221.32787

State: Oper; PIEs sent/rcvd: 0/17; Downstream

Up time: 00:08:37

TDP discovery sources:

FastEthernet0/1, Src IP addr: 10.250.32.13

Addresses bound to peer TDP Ident:

172.29.253.12 172.29.252.12 172.25.32.12 10.250.32.13

ru214#

mheusinger · ‎02-08-2007

Hi Bjornar,

everything looks normal and labels are assigned by both, CPE and PE and learned respectively. The relevant output from the core:

32 Pop tag 172.25.32.221/32 77455 AT6/0.75 10.250.32.14

This (Pop tag) means the core has learned the proper label from the CPE. For directly connected networks a LSR will allocate the implicit-null label - indicated by Pop tag. For normal IP connectivity this will mean an IP packet is sent to the CPE. The feature is called "Penultimate hop popping".

Additionally you can see:

RU9612#sh tag-switching tdp bindings

tib entry: 10.0.0.0/8, rev 18

local binding: tag: 21

remote binding: tsr: 172.29.252.9:0, tag: 20

remote binding: tsr: 172.29.252.10:0, tag: 18

remote binding: tsr: 172.29.252.11:0, tag: 1262

remote binding: tsr: 172.25.32.221:0, tag: 30

The last entry here tells me the core has learned the labels assigned by the cpe (172.25.32.221:0).

So label switching works as far as I can tell. So what is the issue in your case?

Hope this helps!

Regards, Martin

View solution in original post

mheusinger · ‎02-08-2007

Can you please post

"show mpls ldp binding", "show mpls forwarding-table" "show ip route"?

Regards, Martin

bjornarsb · ‎02-08-2007

Thank you for your help .

The output you requested are attached.

Regards

Bjornar

mheusinger · ‎02-08-2007

Hi Bjornar,

everything looks normal and labels are assigned by both, CPE and PE and learned respectively. The relevant output from the core:

32 Pop tag 172.25.32.221/32 77455 AT6/0.75 10.250.32.14

This (Pop tag) means the core has learned the proper label from the CPE. For directly connected networks a LSR will allocate the implicit-null label - indicated by Pop tag. For normal IP connectivity this will mean an IP packet is sent to the CPE. The feature is called "Penultimate hop popping".

Additionally you can see:

RU9612#sh tag-switching tdp bindings

tib entry: 10.0.0.0/8, rev 18

local binding: tag: 21

remote binding: tsr: 172.29.252.9:0, tag: 20

remote binding: tsr: 172.29.252.10:0, tag: 18

remote binding: tsr: 172.29.252.11:0, tag: 1262

remote binding: tsr: 172.25.32.221:0, tag: 30

The last entry here tells me the core has learned the labels assigned by the cpe (172.25.32.221:0).

So label switching works as far as I can tell. So what is the issue in your case?

Hope this helps!

Regards, Martin

bjornarsb · ‎02-08-2007

Thank you !

Now it works.

ru214#ping vrf internet2

Protocol [ip]:

Target IP address: 193.216.1.10

Repeat count [5]: 10

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 172.17.39.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 193.216.1.10, timeout is 2 seconds:

Packet sent with a source address of 172.17.39.1

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 20/24/28 ms

ru214#

regards

Bjornar