i think it all depends on what you are looking for to be broken, and how
much or how many of your IP subnets do you want to be "switched" or
"routed"in your topology...all depends really...and this may be really over
simplified to see the big picture of having a consistent MPLS switched cloud
that works 100% the way it "should" work...
very simple example to try and find what is broken or not broken and not a
production example but still label switched example with the "broken" 'no
host route to transport addr' issue
what i see different is in the CEF output, only after the static host routes
are added is the "tag information set local tag: implicit-null" field...
so i am trying to figure out what the implict-null field is giving me in
this exact case for the "subnet" 129.53.12.1 - 2 LDP local direct connect
other than not doing the penultimate hop popping between R2 and R1 in the
case a packet is coming in from R2 to R1 129.53.12.1 in my simple example...
R1 <-> R2 <-> R3
R1 1.1.1.1/32 loop0
R3 3.3.3.3/32 loop0
R1#sh mpls ldp discovery detail
Local LDP Identifier:
129.53.12.1:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 129.53.12.1
LDP Id: 129.53.12.2:0; no host route to transport addr
Src IP addr: 129.53.12.2; Transport IP addr: 129.53.12.2
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 129.53.12.0/24
R1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 16 3.3.3.3/32 0 Fa0/0 129.53.12.2
17 Pop tag 2.2.2.2/32 0 Fa0/0 129.53.12.2
18 Pop tag 129.53.23.0/24 0 Fa0/0 129.53.12.2
R1#sh ip cef 129.53.12.2
129.53.12.2/32, version 26, epoch 0, connected, cached adjacency 129.53.12.2
0 packets, 0 bytes
via 129.53.12.2, FastEthernet0/0, 0 dependencies
next hop 129.53.12.2, FastEthernet0/0
valid cached adjacency
Traffic to LDP neighbor "routed" as normal direct connect:
R1#traceroute 129.53.12.2
Tracing the route to 129.53.12.2
1 129.53.12.2 96 msec 68 msec *
Traffic across MPLS LSP swiched through LDP neighbor:
R1#traceroute 3.3.3.3 source 1.1.1.1
Tracing the route to 3.3.3.3
1 129.53.12.2 [MPLS: Label 16 Exp 0] 124 msec 88 msec 68 msec
2 129.53.23.3 32 msec 72 msec *
ADD static route to host on both R1 and R2 to get rid of error and take a
look at forwarding table and cef entry:
R1#conf t
R1(config)#ip route 129.53.12.2 255.255.255.255 FastEthernet0/0
R2#conf t
R2(config)#ip route 129.53.12.1 255.255.255.255 f0/0
R1#sh mpls ldp discovery detail
Local LDP Identifier:
129.53.12.1:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 129.53
LDP Id: 129.53.12.2:0
Src IP addr: 129.53.12.2; Transport IP addr: 129
Hold time: 15 sec; Proposed local/peer: 15/15 se
Reachable via 129.53.12.2/32
R1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 16 3.3.3.3/32 0 Fa0/0 129.53.12.2
17 Pop tag 2.2.2.2/32 0 Fa0/0 129.53.12.2
18 Pop tag 129.53.23.0/24 0 Fa0/0 129.53.12.2
R1#sh ip cef 129.53.12.2
129.53.12.2/32, version 26, epoch 0, connected, cached adjacency 129.53.12.2
0 packets, 0 bytes
tag information set
local tag: implicit-null
via 129.53.12.2, FastEthernet0/0, 0 dependencies
next hop 129.53.12.2, FastEthernet0/0
valid cached adjacency
R1#traceroute 129.53.12.2
Tracing the route to 129.53.12.2
1 129.53.12.2 108 msec 64 msec *
R1#traceroute 3.3.3.3 source 1.1.1.1
Tracing the route to 3.3.3.3
1 129.53.12.2 [MPLS: Label 16 Exp 0] 168 msec 120 msec 148 msec
2 129.53.23.3 92 msec 212 msec *
ALSO i think the idea of the broken piece would be found for the most part
when you look at the difference in R2 bindings with and without the /32 LDP
id route to host:
BEFORE the host route or WITHOUT the host route, i.e. "broken" state:
R2#sh mpls ldp bindings 129.53.12.1 32
tib entry: 129.53.12.1/32, rev 14(no route)
local binding: tag: imp-null
R2#sh mpls ldp bindings 129.53.12.0 24
tib entry: 129.53.12.0/24, rev 8
local binding: tag: imp-null
remote binding: tsr: 3.3.3.3:0, tag: 18
remote binding: tsr: 129.53.12.1:0, tag: imp-null
R3#traceroute 129.53.12.1 source 3.3.3.3
Type escape sequence to abort.
Tracing the route to 129.53.12.1
1 129.53.23.2 96 msec 40 msec 84 msec
2 129.53.12.1 96 msec 96 msec *
AFTER the host route is added:
R2#sh mpls ldp bindings 129.53.12.1 32
tib entry: 129.53.12.1/32, rev 14
local binding: tag: imp-null
R2#sh mpls ldp bindings 129.53.12.0 24
tib entry: 129.53.12.0/24, rev 8
local binding: tag: imp-null
remote binding: tsr: 3.3.3.3:0, tag: 18
remote binding: tsr: 129.53.12.1:0, tag: imp-null
R3#traceroute 129.53.12.1 source 3.3.3.3
Type escape sequence to abort.
Tracing the route to 129.53.12.1
1 129.53.23.2 48 msec 32 msec 104 msec
2 129.53.12.1 100 msec 116 msec *
R3#sh mpls fo
R3#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 17 1.1.1.1/32 0 Fa0/1 129.53.23.2
17 Pop tag 2.2.2.2/32 0 Fa0/1 129.53.23.2
18 Pop tag 129.53.12.0/24 0 Fa0/1 129.53.23.2
-- Garry L. Baker "There is no 'patch' for stupidity." - www.sqlsecurity.com On Sun, Aug 8, 2010 at 4:41 PM, William McCall <william.mccall_at_gmail.com>wrote: > The router ID must be routeable with LDP. > > Labels are not exchanged multicast. > > You should read the RFC for LDP [1] and understand this thoroughly, > but basically, the hellos in LDP are just used for session parameter > exchange and for providing keepalive for LDP. Everything else occurs > in a TCP session between the two LSRs. The router ID is the IP address > used (by default exceptions apply) to setup the session. If LSR A and > B have router-IDs of a.a.a.a and b.b.b.b, a.a.a.a connects to b.b.b.b > on port 646 and uses TCP as the transport. It then exchanges labels. > Also, a loopback should generally be used for transport (in > production). > > So basically, things are not working fine if you are expecting label > switched traffic. > > HTH > > -- > William McCall, CCIE #25044 > > [1] http://tools.ietf.org/html/rfc5036 > > > On Sun, Aug 8, 2010 at 8:16 AM, Bernard Steven <buny.steven_at_gmail.com> > wrote: > > > > Some of the documents that i read stated that the exact route should be > in > > place. But as i said it did not break any thing so far except for sham > > links. > > > > Just curious , if i encountered this in the lab , what to do. "no host > route > > to transport addr" whether to leave it as long as it works fine. > > > > > > > > On Sun, Aug 8, 2010 at 6:10 PM, garry baker <baker.garry_at_gmail.com> > wrote: > > > > > WARNING: more my rambles than an actually answer... > > > > > > i would say it doesnt matter in a link local (multicast hello) > > > configuration the neighbors will come up and peer and pass label > information > > > which is the whole point... > > > > > > in a targeted session neighbor configuration (unicast hello) i guess > this > > > would not be the case as you would have to route to the LDP Id, but > then > > > again that doesnt mean you have to have an exact /32 host route to get > there > > > either > > > > > > the usual way i set this up is with a routing protocol running > advertising > > > a loopback interface which is usually a /32 also used for the BGP > sessions > > > so it just sort of falls into place... > > > > > > probably something i am missing and it is probably letting you know > that > > > information for some reason, but i cannot think of anything that is > breaking > > > the LDP neighbor-ship and passing of labels... > > > > > > i would love to hear more from more knowledgeable experts thought... > > > > > > and if you dont have any problems and your setup is "working" then not > sure > > > how you would even know until the problem did arise... > > > > > > > > > -- > > > Garry L. Baker > > > > > > "There is no 'patch' for stupidity." - www.sqlsecurity.com > > > > > > > > > On Sun, Aug 8, 2010 at 2:32 PM, Bernard Steven <buny.steven_at_gmail.com > >wrote: > > > > > >> Is it a must that peer LDP router IDs have an exact route in the > local > > >> routing table ? > > >> Even without an exact match , things work fine. > > >> > > >> LDP Id: 6.6.6.6:0; no host route to transport addr > > >> > > >> regards > > >> > > >> > > >> 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.netReceived on Sun Aug 08 2010 - 18:12:51 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:52 ART