Thread: [mpls-linux-general] ldp_linux don't work for README.sample environment!
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-general
|
From: Morvan D. <mo...@so...> - 2002-06-11 04:18:40
|
Hello all!
I want to make ldp-linux work for this simple testbed:
My testbed configuration is:
hostA LERA CORE LERB hostB
10.1.0.2/24----10.1.0.1/24 10.2.1.1/24----10.2.1.2/24
10.1.1.2/24-----10.1.1.1/24 10.2.0.1/24----10.2.0.2/24
I'am using only host static routes to make hostA and hostB are reacheable to each other.
Static Routes added at:
LERA:
route add 10.2.1.2/32 gw 10.1.0.1
LERB:
route add 10.1.1.2/32 gw 10.2.0.1
CORE:
route add 10.1.1.2/32 gw 10.1.0.2
route add 10.2.1.2/32 gw 10.2.0.2
For tests I use the command "traceroute" with:
IP_only (ip_forwarding)
LDP: "mpls-adm" and "ldp-linux".
I were Waiting this Results:
traceroute -n from hostA to host B: may show 4 hops with standard IP, an 3 hops with LDP (mpls_adm or ldp_linux).
For IP (ip_forwarding only) it's ok - 4 hops.
For LDP using "mpls_adm" it's ok - 3 hops
For LDP using "ldp_linux" IT NEVER WORK!!!!!!!!!!
I see that "ldp_linux" only create the LSP for one direction (from A to B)!
Like documentation "ldp_linux" create LSPs basead on the L3 information (so, static routes created above should result in LSPs created in two directions)!
I follow README.sample commands, but for the sample environment it too don't work!
If some one in this mailing list had sucessfull configured "ldp_linux" in such environment
or like README.sample and the LSPs are dinamically create for two directions, please let me know!
Morvan.
|
|
From: James R. L. <jl...@mi...> - 2002-06-11 15:31:56
|
The problem you are seeing (LSP setup in one direction) is a know problem. I'm working on a fix in the zebra<->ldp-portable version (grab it from CVS to see the progress thus far) Jim On Tue, Jun 11, 2002 at 01:20:42AM -0300, Morvan Daniel M=FCller wrote: > Hello all! >=20 > I want to make ldp-linux work for this simple testbed: >=20 > My testbed configuration is: > hostA LERA CORE LERB hostB > 10.1.0.2/24----10.1.0.1/24 10.2.1.1/24----10.2.1.2/2= 4 > 10.1.1.2/24-----10.1.1.1/24 10.2.0.1/24----10.2.0.2/24 =20 >=20 > I'am using only host static routes to make hostA and hostB are reacheab= le to each other. > Static Routes added at: > LERA: > route add 10.2.1.2/32 gw 10.1.0.1 > LERB: > route add 10.1.1.2/32 gw 10.2.0.1 > CORE: > route add 10.1.1.2/32 gw 10.1.0.2 > route add 10.2.1.2/32 gw 10.2.0.2 > =20 > For tests I use the command "traceroute" with: > IP_only (ip_forwarding) > LDP: "mpls-adm" and "ldp-linux". >=20 > I were Waiting this Results: > traceroute -n from hostA to host B: may show 4 hops with standard IP, a= n 3 hops with LDP (mpls_adm or ldp_linux). >=20 > For IP (ip_forwarding only) it's ok - 4 hops. > For LDP using "mpls_adm" it's ok - 3 hops > For LDP using "ldp_linux" IT NEVER WORK!!!!!!!!!!=20 > =20 > I see that "ldp_linux" only create the LSP for one direction (from A to= B)! > Like documentation "ldp_linux" create LSPs basead on the L3 information= (so, static routes created above should result in LSPs created in two di= rections)! >=20 > I follow README.sample commands, but for the sample environment it too = don't work!=20 >=20 > If some one in this mailing list had sucessfull configured "ldp_linux" = in such environment > or like README.sample and the LSPs are dinamically create for two direc= tions, please let me know! >=20 > Morvan. >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?s= ource=3Dosdntextlink >=20 > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general --=20 James R. Leu |
|
From: Igor V. <ch...@fl...> - 2002-06-11 18:51:18
|
Hello,
I've tried out several modes of operation for ldp-linux and I'm having some
rather problematic results.
The setup I used was:
LER1---------------------LSR1---------------------LER2
192.168.20.200 192.168.20.201 192.168.19.206
192.168.19.204
All machines mpls-linux 0.996 patched kernel 2.4.12, ldp-portable CVS (a few
weeks ago)
Firstly, when I changed from Downstream Unsolicited to Downstream on Demand
mode, after adding global and interface, ldp crashes. I browsed through
mailing list archives and found Amish Verna's message from 2002-04-11, the
same thing happened to him but there was no reply. Is there a solution to
this problem?
Another thing I tried was testing whether ldp really works in Ordered
control mode, as the default is Ordered, but I found that it is not so. It
behaves as if it works in Independent mode! Let me explain my test:
In the setup above, the routing was:
LER1:
route add -host 192.168.20.201 gw 192.168.20.201
route add -host 192.168.19.203 gw 192.168.20.201
LSR1:
route add 192.168.20.200 gw 192.168.20.200
route add 192.168.19.206 gw 192.168.19.206
route add 192.168.19.203 gw 192.168.19.206
LER2:
route add 192.168.19.204 gw 192.168.19.204
The LDP session was first setup between LSR1 and LER2. After that the LDP
session was setup between LSR1 and LER1.
Note that 192.168.19.203 is a *fictional* FEC for which the LER1, when
working in the Independent mode, should get a label for, from the LSR1.
But when working in the Ordered mode, the LSR1 *must not* send any labels to
LER1 for a FEC 192.168.19.203 since LER2, the next hop LSR for that FEC
(from LSR1's point of view) didn't yet send labels for that FEC. (It didn't
send and it won't send because I never added that route in the routing
table, on purpose).
But, I noticed a label mapping message originated from LSR1 to LER1 with a
label for a FEC 192.168.19.203.
(I grabbed it with Ethereal, and can present it if neccessary).
The result on LER1:
voip5:/home/igor# cat /proc/net/mpls_fec
40005403 192.168.19.203/32
40006003 192.168.20.201/32
voip5:/home/igor# cat /proc/net/mpls_out
40005403 0/0/0 PUSH(gen 21) SET(lec0,192.168.20.201)
40006003 102/6222/0 PUSH(gen 24) SET(lec0,192.168.20.201)
According to RFC3036:
" When using LSP ordered control, an LSR may initiate the transmission
of a label mapping only for a FEC for which it has a label mapping
for the FEC next hop, or for which the LSR is the egress. For each
FEC for which the LSR is not the egress and no mapping exists, the
LSR MUST wait until a label from a downstream LSR is received before
mapping the FEC and passing corresponding labels to upstream LSRs."
Is LSR1 the Egress for a FEC 192.168.19.203?
According to RFC3036:
" An LSR may act as an egress LSR, with respect to a particular FEC,
under any of the following conditions:
1. The FEC refers to the LSR itself (including one of its directly
attached interfaces).
2. The next hop router for the FEC is outside of the Label
Switching Network.
3. FEC elements are reachable by crossing a routing domain
boundary, such as another area for OSPF summary networks, or
another autonomous system for OSPF AS externals and BGP routes"
Obviously none of the 1,2, or 3 applies. Therefore the LSR1 is not the
egress for that particular FEC, and it didn't yet receive the mapping from
the FEC next hop. It shouldn't have sent the label mapping message.
According to the RFC, the fact that LSR1 works in Unsolicited label
distribution mode, doesn't change above facts; It only means the LSR1 is
responsible for sending labels upstream to the LER1, (doesn't wait for the
label request from LER1); In Downstream on Demand mode, the LER1 would be
responsible for those labels (by sending label request messages to LSR1).
Sincerely,
Igor Vukomanovic
P.S.
Some additional info :
On LSR1, the result was also OK :
voip4:/# cat /proc/net/mpls_out
40004402 72/4560/0 PUSH(gen 17) SET(eth0,192.168.19.206)
40004803 38/2681/0 PUSH(gen 18) SET(lec0,192.168.20.200)
voip4:/# cat /proc/net/mpls_fec
40004402 192.168.19.206/32
40004803 192.168.20.200/32
However, on LER2 there were no out labels or fec's. I guess this is the
known problem of one-way LSP Morvan Daniel Muller and some other people
encountered. However, if I add:
route add -host 192.168.20.200 gw 192.168.19.204
on LER2, it would create an out label for the FEC 192.168.20.200 ! (still no
labels for 192.168.19.204 though).
(Just a piece of curious information).
|
|
From: James R. L. <jl...@mi...> - 2002-06-19 05:18:30
|
Interesting. After I have chance to finish the ldp-portable/zebra integration I will work on debugging the differnt modes of operation. Jim On Tue, Jun 11, 2002 at 08:51:48PM +0200, Igor Vukomanovic wrote: > Hello, > > I've tried out several modes of operation for ldp-linux and I'm having some > rather problematic results. > The setup I used was: > > LER1---------------------LSR1---------------------LER2 > 192.168.20.200 192.168.20.201 192.168.19.206 > 192.168.19.204 > > All machines mpls-linux 0.996 patched kernel 2.4.12, ldp-portable CVS (a few > weeks ago) > > Firstly, when I changed from Downstream Unsolicited to Downstream on Demand > mode, after adding global and interface, ldp crashes. I browsed through > mailing list archives and found Amish Verna's message from 2002-04-11, the > same thing happened to him but there was no reply. Is there a solution to > this problem? > > Another thing I tried was testing whether ldp really works in Ordered > control mode, as the default is Ordered, but I found that it is not so. It > behaves as if it works in Independent mode! Let me explain my test: > In the setup above, the routing was: > LER1: > route add -host 192.168.20.201 gw 192.168.20.201 > route add -host 192.168.19.203 gw 192.168.20.201 > > LSR1: > route add 192.168.20.200 gw 192.168.20.200 > route add 192.168.19.206 gw 192.168.19.206 > route add 192.168.19.203 gw 192.168.19.206 > > LER2: > route add 192.168.19.204 gw 192.168.19.204 > > The LDP session was first setup between LSR1 and LER2. After that the LDP > session was setup between LSR1 and LER1. > > Note that 192.168.19.203 is a *fictional* FEC for which the LER1, when > working in the Independent mode, should get a label for, from the LSR1. > But when working in the Ordered mode, the LSR1 *must not* send any labels to > LER1 for a FEC 192.168.19.203 since LER2, the next hop LSR for that FEC > (from LSR1's point of view) didn't yet send labels for that FEC. (It didn't > send and it won't send because I never added that route in the routing > table, on purpose). > But, I noticed a label mapping message originated from LSR1 to LER1 with a > label for a FEC 192.168.19.203. > (I grabbed it with Ethereal, and can present it if neccessary). > > The result on LER1: > > voip5:/home/igor# cat /proc/net/mpls_fec > 40005403 192.168.19.203/32 > 40006003 192.168.20.201/32 > > voip5:/home/igor# cat /proc/net/mpls_out > 40005403 0/0/0 PUSH(gen 21) SET(lec0,192.168.20.201) > 40006003 102/6222/0 PUSH(gen 24) SET(lec0,192.168.20.201) > > According to RFC3036: > > " When using LSP ordered control, an LSR may initiate the transmission > of a label mapping only for a FEC for which it has a label mapping > for the FEC next hop, or for which the LSR is the egress. For each > FEC for which the LSR is not the egress and no mapping exists, the > LSR MUST wait until a label from a downstream LSR is received before > mapping the FEC and passing corresponding labels to upstream LSRs." > > Is LSR1 the Egress for a FEC 192.168.19.203? > > According to RFC3036: > > " An LSR may act as an egress LSR, with respect to a particular FEC, > under any of the following conditions: > 1. The FEC refers to the LSR itself (including one of its directly > attached interfaces). > 2. The next hop router for the FEC is outside of the Label > Switching Network. > 3. FEC elements are reachable by crossing a routing domain > boundary, such as another area for OSPF summary networks, or > another autonomous system for OSPF AS externals and BGP routes" > > Obviously none of the 1,2, or 3 applies. Therefore the LSR1 is not the > egress for that particular FEC, and it didn't yet receive the mapping from > the FEC next hop. It shouldn't have sent the label mapping message. > > According to the RFC, the fact that LSR1 works in Unsolicited label > distribution mode, doesn't change above facts; It only means the LSR1 is > responsible for sending labels upstream to the LER1, (doesn't wait for the > label request from LER1); In Downstream on Demand mode, the LER1 would be > responsible for those labels (by sending label request messages to LSR1). > > Sincerely, > > Igor Vukomanovic > > P.S. > Some additional info : > On LSR1, the result was also OK : > > voip4:/# cat /proc/net/mpls_out > 40004402 72/4560/0 PUSH(gen 17) SET(eth0,192.168.19.206) > 40004803 38/2681/0 PUSH(gen 18) SET(lec0,192.168.20.200) > > voip4:/# cat /proc/net/mpls_fec > 40004402 192.168.19.206/32 > 40004803 192.168.20.200/32 > > However, on LER2 there were no out labels or fec's. I guess this is the > known problem of one-way LSP Morvan Daniel Muller and some other people > encountered. However, if I add: > > route add -host 192.168.20.200 gw 192.168.19.204 > > on LER2, it would create an out label for the FEC 192.168.20.200 ! (still no > labels for 192.168.19.204 though). > > (Just a piece of curious information). > > > _______________________________________________________________ > > Multimillion Dollar Computer Inventory > Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar > > > > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general -- James R. Leu |
|
From: Morvan D. <mo...@so...> - 2002-06-14 14:15:39
|
Hi Jim!
I try to compile zebra today 14/06/2002, 8:30am, with ldp-portable=
zebra_ldp.diff patch without successful!
# history
1001 cd ~morvan/
1002 cd cvs/
1007 pwd
1008 CVSROOT=3D":pserver:an...@an...:/cvsroot"
1009 export CVSROOT
1010 cvs login
1011 cvs login
1012 cvs -z3 -d:pserver:an...@an...:/cvsroot co zebra
1013 cvs -z3=
-d:pserver:ano...@cv...:/cvsroot/mpls-linux co=
ldp-portable
1014 cp -pR zebra ldp-portable /usr/src
1015 cd /usr/src/zebra/
1016 patch -p1 < ../ldp-portable/zebra-ldp.diff > patch.log 2>&1
1018 cat patch.log | more
* LAST cvs zebra version show some problems with this patch!
* I have one cvs zebra version from 25-mai-2002 that's ok for this=
patch!
1019 cd mplsd/
1020 vi ./create-links=20
* SRC=3D/usr/src/ldp-portable/lib
1021 chmod 755 ./create-links
1022 ./create-links=20
1023 cd ..
1024 ./configure
1025 cd mplsd/
1026 make all > make_1.log 2>&1
1027 cat make_1.log=20
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_fib.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_ifmgr.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_lock.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_mm.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_mpls.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_policy.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_socket.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_timer.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_tree.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c in-instr.c
In file included from in-instr.c:8:
out-segment.h:4:24: linux/mpls.h: No such file or directory
In file included from in-instr.c:9:
in-segment.h:4:24: linux/mpls.h: No such file or directory
In file included from in-instr.c:10:
in-instr.h:4:24: linux/mpls.h: No such file or directory
in-instr.c:16:24: linux/mpls.h: No such file or directory
make: *** [in-instr.o] Error 1
I TRY this bellow solution without successfull!
1031 mkdir /usr/src/zebra/linux
1032 cp -p /usr/src/linux/include/linux/mpls.h /usr/src/zebra/linux
1033 make clean
1034 make all > make_2.log 2>&1
1035 cat make_2.log=20
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_fib.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_ifmgr.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_lock.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_mm.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_mpls.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_policy.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_socket.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_timer.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c impl_tree.c
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../lib =
-g -O2 -Wall -c in-instr.c
in-instr.c: In function `do_mplsd_in_instr':
in-instr.c:102: warning: passing arg 2 of `mos2ml' from incompatible pointer=
type
in-instr.c:117: `SIOCSMPLSININSTR' undeclared (first use in this function)
in-instr.c:117: (Each undeclared identifier is reported only once
in-instr.c:117: for each function it appears in.)
make: *** [in-instr.o] Error 1
Do you know what's the problem?
Cheers,=20
Morvan.
At 11:33 11/06/2002 -0500, James R. Leu wrote:
>The problem you are seeing (LSP setup in one direction) is a know
>problem. I'm working on a fix in the zebra<->ldp-portable version
>(grab it from CVS to see the progress thus far)
>
>Jim
>
>On Tue, Jun 11, 2002 at 01:20:42AM -0300, Morvan Daniel M=FCller wrote:
>> Hello all!
>>=20
>> I want to make ldp-linux work for this simple testbed:
>>=20
>> My testbed configuration is:
>> hostA LERA CORE LERB hostB
>> 10.1.0.2/24----10.1.0.1/24 10.2.1.1/24----10.2.1.2/24
>> 10.1.1.2/24-----10.1.1.1/24 10.2.0.1/24----10.2.0.2/24 =20
>>=20
>> I'am using only host static routes to make hostA and hostB are reacheable=
to each other.
>> Static Routes added at:
>> LERA:
>> route add 10.2.1.2/32 gw 10.1.0.1
>> LERB:
>> route add 10.1.1.2/32 gw 10.2.0.1
>> CORE:
>> route add 10.1.1.2/32 gw 10.1.0.2
>> route add 10.2.1.2/32 gw 10.2.0.2
>> =20
>> For tests I use the command "traceroute" with:
>> IP_only (ip_forwarding)
>> LDP: "mpls-adm" and "ldp-linux".
>>=20
>> I were Waiting this Results:
>> traceroute -n from hostA to host B: may show 4 hops with standard IP, an=
3 hops with LDP (mpls_adm or ldp_linux).
>>=20
>> For IP (ip_forwarding only) it's ok - 4 hops.
>> For LDP using "mpls_adm" it's ok - 3 hops
>> For LDP using "ldp_linux" IT NEVER WORK!!!!!!!!!!=20
>> =20
>> I see that "ldp_linux" only create the LSP for one direction (from A to=
B)!
>> Like documentation "ldp_linux" create LSPs basead on the L3 information=
(so, static routes created above should result in LSPs created in two=
directions)!
>>=20
>> I follow README.sample commands, but for the sample environment it too=
don't work!=20
>>=20
>> If some one in this mailing list had sucessfull configured "ldp_linux" in=
such environment
>> or like README.sample and the LSPs are dinamically create for two=
directions, please let me know!
>>=20
>> Morvan.
>>=20
>> _______________________________________________________________
>>=20
>> Don't miss the 2002 Sprint PCS Application Developer's Conference
>> August 25-28 in Las Vegas -=
http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink
>>=20
>> _______________________________________________
>> mpls-linux-general mailing list
>> mpl...@li...
>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>
>--=20
>James R. Leu
>
|
|
From: James R. L. <jl...@mi...> - 2002-06-19 05:10:17
|
It is looking for the kernel header file <linux/mpls.h> which is located in /usr/src/linux/include/linux. Try adding -I /usr/src/linux/include/li= nux to the CFLAGs (where /usr/src/linux is where your patched version of the kernel resides). Jim On Fri, Jun 14, 2002 at 11:17:43AM -0300, Morvan Daniel M=FCller wrote: > Hi Jim! >=20 > I try to compile zebra today 14/06/2002, 8:30am, with ldp-portable zebr= a_ldp.diff patch without successful! >=20 > # history > 1001 cd ~morvan/ > 1002 cd cvs/ > 1007 pwd > 1008 CVSROOT=3D":pserver:an...@an...:/cvsroot" > 1009 export CVSROOT > 1010 cvs login > 1011 cvs login > 1012 cvs -z3 -d:pserver:an...@an...:/cvsroot co zebra > 1013 cvs -z3 -d:pserver:ano...@cv...:/cvs= root/mpls-linux co ldp-portable > 1014 cp -pR zebra ldp-portable /usr/src > 1015 cd /usr/src/zebra/ > 1016 patch -p1 < ../ldp-portable/zebra-ldp.diff > patch.log 2>&1 > 1018 cat patch.log | more > * LAST cvs zebra version show some problems with this patch! > * I have one cvs zebra version from 25-mai-2002 that's ok for th= is patch! > 1019 cd mplsd/ > 1020 vi ./create-links=20 > * SRC=3D/usr/src/ldp-portable/lib > 1021 chmod 755 ./create-links > 1022 ./create-links=20 > 1023 cd .. > 1024 ./configure > 1025 cd mplsd/ > 1026 make all > make_1.log 2>&1 > 1027 cat make_1.log=20 >=20 > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_fib.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_ifmgr.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_lock.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_mm.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_mpls.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_policy.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_socket.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_timer.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_tree.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c in-instr.c > In file included from in-instr.c:8: > out-segment.h:4:24: linux/mpls.h: No such file or directory > In file included from in-instr.c:9: > in-segment.h:4:24: linux/mpls.h: No such file or directory > In file included from in-instr.c:10: > in-instr.h:4:24: linux/mpls.h: No such file or directory > in-instr.c:16:24: linux/mpls.h: No such file or directory > make: *** [in-instr.o] Error 1 >=20 > I TRY this bellow solution without successfull! >=20 > 1031 mkdir /usr/src/zebra/linux > 1032 cp -p /usr/src/linux/include/linux/mpls.h /usr/src/zebra/linux > 1033 make clean > 1034 make all > make_2.log 2>&1 > 1035 cat make_2.log=20 >=20 > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_fib.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_ifmgr.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_lock.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_mm.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_mpls.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_policy.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_socket.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_timer.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c impl_tree.c > gcc -DHAVE_CONFIG_H -DSYSCONFDIR=3D\"/usr/local/etc/\" -I.. -I.. -I../l= ib -g -O2 -Wall -c in-instr.c > in-instr.c: In function `do_mplsd_in_instr': > in-instr.c:102: warning: passing arg 2 of `mos2ml' from incompatible po= inter type > in-instr.c:117: `SIOCSMPLSININSTR' undeclared (first use in this functi= on) > in-instr.c:117: (Each undeclared identifier is reported only once > in-instr.c:117: for each function it appears in.) > make: *** [in-instr.o] Error 1 >=20 > Do you know what's the problem? >=20 > Cheers,=20 >=20 > Morvan. >=20 >=20 > At 11:33 11/06/2002 -0500, James R. Leu wrote: > >The problem you are seeing (LSP setup in one direction) is a know > >problem. I'm working on a fix in the zebra<->ldp-portable version > >(grab it from CVS to see the progress thus far) > > > >Jim > > > >On Tue, Jun 11, 2002 at 01:20:42AM -0300, Morvan Daniel M=FCller wrote= : > >> Hello all! > >>=20 > >> I want to make ldp-linux work for this simple testbed: > >>=20 > >> My testbed configuration is: > >> hostA LERA CORE LERB hostB > >> 10.1.0.2/24----10.1.0.1/24 10.2.1.1/24----10.2.1.= 2/24 > >> 10.1.1.2/24-----10.1.1.1/24 10.2.0.1/24----10.2.0.2/24 =20 > >>=20 > >> I'am using only host static routes to make hostA and hostB are reach= eable to each other. > >> Static Routes added at: > >> LERA: > >> route add 10.2.1.2/32 gw 10.1.0.1 > >> LERB: > >> route add 10.1.1.2/32 gw 10.2.0.1 > >> CORE: > >> route add 10.1.1.2/32 gw 10.1.0.2 > >> route add 10.2.1.2/32 gw 10.2.0.2 > >> =20 > >> For tests I use the command "traceroute" with: > >> IP_only (ip_forwarding) > >> LDP: "mpls-adm" and "ldp-linux". > >>=20 > >> I were Waiting this Results: > >> traceroute -n from hostA to host B: may show 4 hops with standard IP= , an 3 hops with LDP (mpls_adm or ldp_linux). > >>=20 > >> For IP (ip_forwarding only) it's ok - 4 hops. > >> For LDP using "mpls_adm" it's ok - 3 hops > >> For LDP using "ldp_linux" IT NEVER WORK!!!!!!!!!!=20 > >> =20 > >> I see that "ldp_linux" only create the LSP for one direction (from A= to B)! > >> Like documentation "ldp_linux" create LSPs basead on the L3 informat= ion (so, static routes created above should result in LSPs created in two= directions)! > >>=20 > >> I follow README.sample commands, but for the sample environment it t= oo don't work!=20 > >>=20 > >> If some one in this mailing list had sucessfull configured "ldp_linu= x" in such environment > >> or like README.sample and the LSPs are dinamically create for two di= rections, please let me know! > >>=20 > >> Morvan. > >>=20 > >> _______________________________________________________________ > >>=20 > >> Don't miss the 2002 Sprint PCS Application Developer's Conference > >> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cf= m?source=3Dosdntextlink > >>=20 > >> _______________________________________________ > >> mpls-linux-general mailing list > >> mpl...@li... > >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > > >--=20 > >James R. Leu > > --=20 James R. Leu |
|
From: Morvan D. <mo...@so...> - 2002-06-19 20:21:04
|
Hi Jim!
I'am using kernel 2.4.12 patched with the last mpls-linux cvs version!
I too get ldp-portable today from cvs.
About zebra I'm using an cvs version from 26/mai/2002, because the today version on zebra cvs show erros applying the ldp-portable/zebra-ldp.diff patch.
I try your suggestion (include in CFLAGS) but zebra compilation show other errors (as bellow):
make[2]: Leaving directory `/usr/src/zebra/ospfd'
Making all in mplsd
make[2]: Entering directory `/usr/src/zebra/mplsd'
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc/\" -I.. -I.. -I../lib -I/usr/src/linux/include/linux -g -O2 -Wall -c impl_fib.c
In file included from /usr/include/bits/types.h:143,
from /usr/include/stdio.h:35,
from ../lib/zebra.h:34,
from ../mplsd/impl_socket.h:4,
from ../mplsd/ldp_handle_type.h:13,
from ../mplsd/ldp_struct.h:277,
from ../mplsd/ldp.h:4,
from impl_fib.c:1:
/usr/include/bits/pthreadtypes.h:48: parse error before `size_t'
/usr/include/bits/pthreadtypes.h:48: warning: no semicolon at end of struct or union
/usr/include/bits/pthreadtypes.h:51: parse error before `__stacksize'
/usr/include/bits/pthreadtypes.h:51: warning: data definition has no type or storage class
/usr/include/bits/pthreadtypes.h:52: warning: data definition has no type or storage class
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:30,
from /usr/include/stdio.h:64,
from ../lib/zebra.h:34,
from ../mplsd/impl_socket.h:4,
from ../mplsd/ldp_handle_type.h:13,
from ../mplsd/ldp_struct.h:277,
from ../mplsd/ldp.h:4,
from impl_fib.c:1:
/usr/include/gconv.h:71: parse error before `size_t'
/usr/include/gconv.h:84: parse error before `size_t'
/usr/include/gconv.h:93: parse error before `size_t'
/usr/include/gconv.h:169: parse error before `size_t'
/usr/include/gconv.h:169: warning: no semicolon at end of struct or union
/usr/include/gconv.h:172: parse error before `}'
/usr/include/gconv.h:172: warning: data definition has no type or storage class
In file included from /usr/include/libio.h:30,
from /usr/include/stdio.h:64,
from ../lib/zebra.h:34,
from ../mplsd/impl_socket.h:4,
from ../mplsd/ldp_handle_type.h:13,
from ../mplsd/ldp_struct.h:277,
from ../mplsd/ldp.h:4,
from impl_fib.c:1:
/usr/include/_G_config.h:47: field `__cd' has incomplete type
/usr/include/_G_config.h:50: field `__cd' has incomplete type
/usr/include/_G_config.h:53: confused by earlier errors, bailing out
make[2]: *** [impl_fib.o] Error 1
make[2]: Leaving directory `/usr/src/zebra/mplsd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/zebra'
make: *** [all-recursive-am] Error 2
cheers,
Morvan.
At 01:11 19/06/2002 -0500, you wrote:
>It is looking for the kernel header file <linux/mpls.h> which is located
>in /usr/src/linux/include/linux. Try adding -I /usr/src/linux/include/linux
>to the CFLAGs (where /usr/src/linux is where your patched version of the
>kernel resides).
>
>Jim
>
|
|
From: Igor V. <ch...@fl...> - 2002-06-19 20:35:06
|
Hello all, Consider this setup: LER2------LSR1-------LER1 Let's assume LER2 is the egress for FEC1. LSR1's IP routing table contains FEC1, (with LER2 as a gw). LDP session establishes between LER2 and LSR1, and LER2 transmits a label for FEC1 to LSR1. Now, inside ldp_linux daemon on LSR1, I type prompt>add route FEC1/32 LER1 How does LDP consider this now: a) LER2 is no longer next hop for FEC1, LER1 is the new next hop for FEC1 b) LER1 and LER2 are both valid next hops for FEC1 ? I tested this setup. If LER1 is also the egress for FEC1, and LDP session establishes between LER1 and LSR1, I get 2 labels for the same FEC on LSR1. I tested this in conservative retention mode, but I'm uncertain how ldp understands the "add route" inside the daemon. If a) is the case, then LSR1 should issue a label release message for the FEC, which it does not. Thanks in advance, Igor Vukomanovic |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X