Thread: [mpls-linux-general] how much of LDP is actually working?
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-general
|
From: Razvan D. <raz...@gm...> - 2005-08-10 00:13:05
|
Hi James, i have managed to acces your P4 development tree, compile and install the latest quagga-mpls suite (ldp included); however i ran in the same problems that are mentioned here http://sourceforge.net/mailarchive/message.php?msg_id=3D11547051 you have that demand unsolicited is well tested (and that is what i used); did you mean to say that it doesn't crash, or it really works (i mean label distribution, LSP generation, MPLS forwarding)? what i want to know is how much of LDP is actually working? this way i can find out whether i haven't made a mistake in my install/configuration; is the entire protocol implemented (some parts may need adjusting of course) or are the parts of the communication protocol that are still missing (in which case i will probably head on to the development team :-) )? if the former is true, where should i start with "getting my hands dirty": the ldp-portable-0.800 source code, or the quagga-zebra interraction with ldp? regards, Razvan |
|
From: James R. L. <jl...@mi...> - 2005-08-10 02:11:58
|
On Tue, Aug 09, 2005 at 03:02:22PM +0300, Razvan Deaconescu wrote: > Hi James, >=20 > i have managed to acces your P4 development tree, compile and install > the latest quagga-mpls suite (ldp included); >=20 > however i ran in the same problems that are mentioned here > http://sourceforge.net/mailarchive/message.php?msg_id=3D11547051 The have been significant changes since then. I wouldn't trust anything with regards to LDP before 2005. > you have that demand unsolicited is well tested (and that is what i > used); did you mean to say that it doesn't crash, or it really works > (i mean label distribution, LSP generation, MPLS forwarding)? I should remove that statement. The internals of LDP have been well tested on other platforms. The quagga-mpls infrastructure is immature and is the source of most of the problems. The other source of problems that is I overhauled the FEC handling code to accommodate non-IPv4 FECs (martini FECs are what I had in mind when making the changes). > what i want to know is how much of LDP is actually working? this way i > can find out whether i haven't made a mistake in my > install/configuration; is the entire protocol implemented (some parts > may need adjusting of course) or are the parts of the communication > protocol that are still missing (in which case i will probably head on > to the development team :-) )? if the former is true, where should i > start with "getting my hands dirty": the ldp-portable-0.800 source > code, or the quagga-zebra interraction with ldp? I would say 95% of the protocol is implemented. The parts that are missing are related to Notification messages. In addition I haven't looked over 3036bis yet to see what other changes are needed. If you're serious about trying to help the first thing to understand is that the quagga porting layer is modeled after juniper's use of LDP. In other words don't expect label distribution for every route in the routing table, only for those which are directly connected to a LDP speaker. Also I think there is a bug in the MPLS infrastructure for FTN bindings. Give me some output of show commands and an explanation of what you would expect to see and we can decide where to focus a bug hunt. > regards, > Razvan >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general --=20 James R. Leu jl...@mi... |
|
From: Razvan D. <raz...@gm...> - 2005-08-10 10:53:49
|
On 8/10/05, James R. Leu <jl...@mi...> wrote:
>=20
> I would say 95% of the protocol is implemented. The parts that are
> missing are related to Notification messages. In addition I haven't
> looked over 3036bis yet to see what other changes are needed.
>=20
> If you're serious about trying to help the first thing to understand
> is that the quagga porting layer is modeled after juniper's use of LDP.
> In other words don't expect label distribution for every route in the
> routing table, only for those which are directly connected to a LDP speak=
er.
> Also I think there is a bug in the MPLS infrastructure for FTN bindings.
>=20
> Give me some output of show commands and an explanation of what you
> would expect to see and we can decide where to focus a bug hunt.
>=20
> --
> James R. Leu
> jl...@mi...
>=20
>=20
>=20
i am pretty serious about getting involved;
i have managed to access your repository, compiled quagga-mpls but it
did'n work (as a matter of fact ospfd didn't work); i patched a fresh
quagga-0.98.0 with the quagga patch from the mpls-linux-1.946a package
and got much better results;
however, when configuring quagga-mpls, my patched version and EVEN the
original quagga-0.98.0 version some configuration error messages
showed up (when running autoreconf or ./update-autotools):
root@MPLS4:/usr/src/quagga-test/test/quagga-0.98.0# autoreconf
aclocal.m4: 13336: `automake requires `AM_CONFIG_HEADER', not
`AC_CONFIG_HEADER'configure.ac: 13336: required file
`./[config.h])].in' not found
zebra/Makefile.am:51: invalid variable `dist_examples_DATA'
ripd/Makefile.am:23: invalid variable `dist_examples_DATA'
ripngd/Makefile.am:23: invalid variable `dist_examples_DATA'
bgpd/Makefile.am:30: invalid variable `dist_examples_DATA'
ospfd/Makefile.am:37: invalid variable `dist_examples_DATA'
ospf6d/Makefile.am:30: invalid variable `dist_examples_DATA'
isisd/Makefile.am:31: invalid variable `dist_examples_DATA'
vtysh/Makefile.am:17: invalid variable `dist_examples_DATA'
vtysh/Makefile.am:11: invalid unused variable name: `nodist_vtysh_SOURCES'
doc/Makefile.am:21: invalid unused variable name: `figures_SOURCES'
autoreconf: automake failed with exit status: 1
i have sent a message to the quagga-users list;
is this normal? (does it happen to you - or am i missing some tool)
nevertheless, i compiled it and launched all the necessary daemons
(zebra, ospfd, ldpd)
this is the network topology i used; the link below contains various
show commands for the ldpd daemon
+------- SWITCH ------------=
+
/ | =20
\
/ | =20
\
/ | =20
\
/ | =20
\
(....54) E0 / | E0
(141.85.37.169) \ E0 (...36)
/ E1(11.0.3.1) | =20
\ E1(11.0.1.2)
---------------mpls1-----------------------mpls2------------------------=
-----mpls3----------
E1(11.0.4.1) E2(11.0.3.2) E2(11.0.2.2) =20
E2(11.0.2.1) |
=20
|
=20
| E3(11.0.5.1)
E0, E1, E2 - stands for eth0, eth1, eth2
i used the switch for Internet access and for easy ssh access from one
machine to the other (i only have one monitor)
only the mpls1-E1, mpls-E1, mpls2-E2, mpls3-E2 are running ldpd
mpls3-E1 is also running ospfd (there's another router with the
11.0.1.1 address - but i was afraid to run ldpd on it because of a
crash :D )
this is the link with the output of the show commands for the ldpd
daemon (they use a bit of space and i didn't want to overfill this
message - it's pretty verbose the way it is)
http://atlantis.cs.pub.ro/~razvand/ldpd-output.txt
as you can see the problem is similar to that presented in the link
from the previous mail; there are NO OUTGOING LABELS
i am looking forward for comments and suggestions where to start
"digging" for bugs
Razvan
|
|
From: Razvan D. <raz...@gm...> - 2005-08-10 14:00:22
|
On 8/10/05, Razvan Deaconescu <raz...@gm...> wrote: > On 8/10/05, James R. Leu <jl...@mi...> wrote: > > > > I would say 95% of the protocol is implemented. The parts that are > > missing are related to Notification messages. In addition I haven't > > looked over 3036bis yet to see what other changes are needed. > > > > If you're serious about trying to help the first thing to understand > > is that the quagga porting layer is modeled after juniper's use of LDP. > > In other words don't expect label distribution for every route in the > > routing table, only for those which are directly connected to a LDP spe= aker. > > Also I think there is a bug in the MPLS infrastructure for FTN bindings= . > > > > Give me some output of show commands and an explanation of what you > > would expect to see and we can decide where to focus a bug hunt. > > > > -- > > James R. Leu > > jl...@mi... > > > > > > > hi, i've managed to remove the errors that showed up at the configuration (it had to do with an outdated version of automake); i've recompiled my patched quagga-0.98.0 but the ouput is still the same (no outlabels); i've also recompiled quagga-mpls, but, just as before, ospf isn't working (the routers keep sending hello messages but without reply) i've also put my topology figure at http://atlantis.cs.pub.ro/~razvand/ldpd-output.txt as i saw it was pretty messed up Razvan |
|
From: James R. L. <jl...@mi...> - 2005-08-10 15:32:22
|
> hi, >=20 > i've managed to remove the errors that showed up at the configuration > (it had to do with an outdated version of automake); i've recompiled > my patched quagga-0.98.0 but the ouput is still the same (no > outlabels); i've also recompiled quagga-mpls, but, just as before, > ospf isn't working (the routers keep sending hello messages but > without reply) You will need OSPF to be working before you will get valid data show in the out-labels. If you see an entry in the database it means that you've sent or received a label for that FEC (depending on whether it is local or remote binding). If the LDP speaker is not the next hop for the FEC then I do not show the label sent for the remove binding. I should probably change this and just put (inactive) after the entry. > i've also put my topology figure at > http://atlantis.cs.pub.ro/~razvand/ldpd-output.txt > as i saw it was pretty messed up I will try and look at your data tonight and see if I can find anything. But the first thing is you need to get OSPF running. > Razvan >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general --=20 James R. Leu jl...@mi... |
|
From: Razvan D. <raz...@gm...> - 2005-08-12 11:18:55
|
On 8/10/05, James R. Leu <jl...@mi...> wrote:
> I will try and look at your data tonight and see if I can find anything.
> But the first thing is you need to get OSPF running.
>=20
i have finally managed to get ospfd and ldpd working using quagga-mpls
from your development tree; the problem was a piece of code that had
to be removed (i just wrapped it inside a comment)
line 2433:
else if (oi->state =3D=3D ISM_InterfaceDown)
{
zlog_warn ("Ignoring packet from [%s] received on interface that is "
"down [%s]",
inet_ntoa (iph->ip_src), ifp->name);
stream_free (ibuf);
return 0;
}
ospfd can't run properly because it is informed (probably by the zebra
daemon) that the interface is down; however, if i do something to that
interface outside of ospfd (for example, i added a static route using
ip route) the interface comes up and ospfd starts running
i don't know if this bug is a quagga bug; i haven't' dug into the code
yet (I'll probably do that soon)
I've looked in the original quagga-0.98.0 version and saw that this
piece of code is absent; it makes sense to add it, but why did you do
it?
i don't know if that piece of code was supposed to keep things on
track; removing it made LDP work, although "work" is not a very good
way to express the way it acts; i know it's a dynamic protocol but it
seems to be too dynamic; in less than 3 minutes it continuously
changed label values (I've been using 4 machines in a linear topology)
and a ping didn't work (it managed to reach the other end but got lost
on its way back); here is the output of two sequential commands on the
ldpd CLI:
ldpd_mpls2# show ldp database
11.0.3.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.2.0/30 local binding: label: gen 10000
11.0.3.0/30 local binding: label: gen 10001
11.0.4.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.2.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.1.0/30 local binding: label: gen 10002
11.0.1.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.2.0/30 local binding: label: gen 10102
11.0.3.0/30 local binding: label: gen 10103
11.0.1.0/30 remote binding: label: gen 10090 lsr: 11.0.1.2:0 ingress
11.0.1.0/30 local binding: label: gen 10105
11.0.2.0/30 remote binding: no outlabel lsr: 11.0.1.2:0
11.0.3.0/30 remote binding: no outlabel lsr: 11.0.1.2:0
ldpd_mpls2# show ld
ldpd_mpls2# show ldp da
ldpd_mpls2# show ldp database
11.0.3.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.2.0/30 local binding: label: gen 10000
11.0.3.0/30 local binding: label: gen 10001
11.0.4.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.2.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
11.0.1.0/30 local binding: label: gen 10002
11.0.1.0/30 remote binding: no outlabel lsr: 11.0.3.2:0
as you can see some labels start disappearing (a little later ldpd crashes =
:) )
somewhere between those those two commands i used the mpls command to
look at some of the kernel MPLS objects that ldpd created; here's the
output
root@MPLS-2:/home/mpls2# mpls ilm show
ILM entry label gen 10117 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts, 0 dropped)
ILM entry label gen 10115 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts, 0 dropped)
ILM entry label gen 10114 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts, 0 dropped)
ILM entry label gen 10002 labelspace 0 proto ipv4
pop peek (59928 bytes, 681 pkts, 0 dropped)
ILM entry label gen 10001 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts, 0 dropped)
ILM entry label gen 10000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts, 0 dropped)
root@MPLS-2:/home/mpls2# mpls nhlfe show
NHLFE entry key 0x0000001f mtu 1496 propagate_ttl
push gen 10106 set eth1 ipv4 11.0.2.1 (1024 bytes, 14 pkts, 0 drop=
ped)
NHLFE entry key 0x0000001e mtu 1496 propagate_ttl
push gen 10102 set eth1 ipv4 11.0.2.1 (5150 bytes, 65 pkts, 0 drop=
ped)
NHLFE entry key 0x0000001d mtu 1496 propagate_ttl
push gen 10098 set eth1 ipv4 11.0.2.1 (5150 bytes, 65 pkts, 0 drop=
ped)
NHLFE entry key 0x0000001c mtu 1496 propagate_ttl
push gen 10094 set eth1 ipv4 11.0.2.1 (5150 bytes, 65 pkts, 0 drop=
ped)
NHLFE entry key 0x0000001b mtu 1496 propagate_ttl
push gen 10090 set eth1 ipv4 11.0.2.1 (5150 bytes, 65 pkts, 0 drop=
ped)
NHLFE entry key 0x0000001a mtu 1496 propagate_ttl
push gen 10086 set eth1 ipv4 11.0.2.1 (5062 bytes, 64 pkts, 0 drop=
ped)
NHLFE entry key 0x00000019 mtu 1496 propagate_ttl
push gen 10082 set eth1 ipv4 11.0.2.1 (4998 bytes, 63 pkts, 0 drop=
ped)
NHLFE entry key 0x00000018 mtu 1496 propagate_ttl
push gen 10078 set eth1 ipv4 11.0.2.1 (4718 bytes, 59 pkts, 0 drop=
ped)
NHLFE entry key 0x00000017 mtu 1496 propagate_ttl
push gen 10074 set eth1 ipv4 11.0.2.1 (4884 bytes, 61 pkts, 0 drop=
ped)
NHLFE entry key 0x00000016 mtu 1496 propagate_ttl
push gen 10070 set eth1 ipv4 11.0.2.1 (5094 bytes, 62 pkts, 0 drop=
ped)
NHLFE entry key 0x00000015 mtu 1496 propagate_ttl
push gen 10066 set eth1 ipv4 11.0.2.1 (4902 bytes, 61 pkts, 0 drop=
ped)
NHLFE entry key 0x00000014 mtu 1496 propagate_ttl
push gen 10064 set eth1 ipv4 11.0.2.1 (4990 bytes, 60 pkts, 0 drop=
ped)
NHLFE entry key 0x00000013 mtu 1496 propagate_ttl
push gen 10060 set eth1 ipv4 11.0.2.1 (4864 bytes, 61 pkts, 0 drop=
ped)
NHLFE entry key 0x00000012 mtu 1496 propagate_ttl
push gen 10056 set eth1 ipv4 11.0.2.1 (4846 bytes, 61 pkts, 0 drop=
ped)
NHLFE entry key 0x00000011 mtu 1496 propagate_ttl
push gen 10052 set eth1 ipv4 11.0.2.1 (3960 bytes, 50 pkts, 0 drop=
ped)
NHLFE entry key 0x00000010 mtu 1496 propagate_ttl
push gen 10050 set eth1 ipv4 11.0.2.1 (1650 bytes, 20 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000f mtu 1496 propagate_ttl
push gen 10046 set eth1 ipv4 11.0.2.1 (1384 bytes, 17 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000e mtu 1496 propagate_ttl
push gen 10044 set eth1 ipv4 11.0.2.1 (1496 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000d mtu 1496 propagate_ttl
push gen 10040 set eth1 ipv4 11.0.2.1 (1066 bytes, 16 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000c mtu 1496 propagate_ttl
push gen 10036 set eth1 ipv4 11.0.2.1 (1102 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000b mtu 1496 propagate_ttl
push gen 10034 set eth1 ipv4 11.0.2.1 (1546 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x0000000a mtu 1496 propagate_ttl
push gen 10030 set eth1 ipv4 11.0.2.1 (1308 bytes, 17 pkts, 0 drop=
ped)
NHLFE entry key 0x00000009 mtu 1496 propagate_ttl
push gen 10026 set eth1 ipv4 11.0.2.1 (1104 bytes, 16 pkts, 0 drop=
ped)
NHLFE entry key 0x00000008 mtu 1496 propagate_ttl
push gen 10024 set eth1 ipv4 11.0.2.1 (1192 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x00000007 mtu 1496 propagate_ttl
push gen 10020 set eth1 ipv4 11.0.2.1 (1066 bytes, 16 pkts, 0 drop=
ped)
NHLFE entry key 0x00000006 mtu 1496 propagate_ttl
push gen 10016 set eth1 ipv4 11.0.2.1 (1066 bytes, 16 pkts, 0 drop=
ped)
NHLFE entry key 0x00000005 mtu 1496 propagate_ttl
push gen 10012 set eth1 ipv4 11.0.2.1 (1014 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x00000004 mtu 1496 propagate_ttl
push gen 10008 set eth1 ipv4 11.0.2.1 (1026 bytes, 15 pkts, 0 drop=
ped)
NHLFE entry key 0x00000003 mtu 1496 propagate_ttl
push gen 10004 set eth1 ipv4 11.0.2.1 (1142 bytes, 16 pkts, 0 drop=
ped)
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 10000 set eth1 ipv4 11.0.2.1 (1408 bytes, 14 pkts, 0 drop=
ped)
root@MPLS-2:/home/mpls2# mpls xc show
root@MPLS-2:/home/mpls2#=20
i don't know why the ldpd keeps creating nhlfe (which is the main
reason or effect why so many labels are generated)?
do you have any ideas why these things happen? and if you do, some
pointers about where to start looking for bugs the code would be
appreciated
Razvan
|
|
From: Hasso T. <ha...@es...> - 2005-08-12 12:43:24
|
Razvan Deaconescu wrote:
> i have finally managed to get ospfd and ldpd working using quagga-mpls
> from your development tree; the problem was a piece of code that had
> to be removed (i just wrapped it inside a comment)
>
> line 2433:
>
> else if (oi->state == ISM_InterfaceDown)
> {
> zlog_warn ("Ignoring packet from [%s] received on interface that is "
> "down [%s]",
> inet_ntoa (iph->ip_src), ifp->name);
> stream_free (ibuf);
> return 0;
> }
- else if (oi->state == ISM_InterfaceDown)
+ else if (oi->state == ISM_Down)
> ospfd can't run properly because it is informed (probably by the zebra
> daemon) that the interface is down; however, if i do something to that
> interface outside of ospfd (for example, i added a static route using
> ip route) the interface comes up and ospfd starts running
>
> i don't know if this bug is a quagga bug; i haven't' dug into the code
> yet (I'll probably do that soon)
>
> I've looked in the original quagga-0.98.0 version and saw that this
> piece of code is absent; it makes sense to add it, but why did you do
> it?
Probably because quagga-mpls isn't exactly 0.98.0, but quagga_0_98_stable
branch from CVS. This particular problem was regression introduced later
in development process and is already fixed in Quagga.
James, I volunteer to put together patch to update quagga-mpls to latest
quagga_0_98_stable code. Would it be OK? I will release Quagga 0.98.5 in
the beginning of the next week probably and would look it right after
that.
--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator
|
|
From: James R. L. <jl...@mi...> - 2005-08-14 23:01:32
|
Hasso,
That would be great. Let me know if you find any conflicts that need
explanation.
Jim
On Fri, Aug 12, 2005 at 03:43:08PM +0300, Hasso Tepper wrote:
> Razvan Deaconescu wrote:
> > i have finally managed to get ospfd and ldpd working using quagga-mpls
> > from your development tree; the problem was a piece of code that had
> > to be removed (i just wrapped it inside a comment)
> >=20
> > line 2433:
> >=20
> > else if (oi->state =3D=3D ISM_InterfaceDown)
> > {
> > zlog_warn ("Ignoring packet from [%s] received on interface that i=
s "
> > "down [%s]",
> > inet_ntoa (iph->ip_src), ifp->name);
> > stream_free (ibuf);
> > return 0;
> > }
>=20
> - else if (oi->state =3D=3D ISM_InterfaceDown)
> + else if (oi->state =3D=3D ISM_Down)
> =20
> > ospfd can't run properly because it is informed (probably by the zebra
> > daemon) that the interface is down; however, if i do something to that
> > interface outside of ospfd (for example, i added a static route using
> > ip route) the interface comes up and ospfd starts running
> >=20
> > i don't know if this bug is a quagga bug; i haven't' dug into the code
> > yet (I'll probably do that soon)
> >=20
> > I've looked in the original quagga-0.98.0 version and saw that this
> > piece of code is absent; it makes sense to add it, but why did you do
> > it?
>=20
> Probably because quagga-mpls isn't exactly 0.98.0, but quagga_0_98_stable
> branch from CVS. This particular problem was regression introduced later
> in development process and is already fixed in Quagga.
>=20
> James, I volunteer to put together patch to update quagga-mpls to latest
> quagga_0_98_stable code. Would it be OK? I will release Quagga 0.98.5 in
> the beginning of the next week probably and would look it right after
> that.
>=20
>=20
> --=20
> Hasso Tepper
> Elion Enterprises Ltd.
> WAN administrator
--=20
James R. Leu
jl...@mi...
|
Thanks for helping keep SourceForge clean.
X