Thread: Re: [mpls-linux-devel] LDP Configuation
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel
|
From: <gsr...@al...> - 2006-11-22 14:20:26
|
Hi!
Thanks for your information.
I decided to test the new configuration in the following scenario, only =
with
two routers to realized what LDP really does. =20
13.0.0.0/24 .1 .1 .2 .1 14.0.0.0/24
-------PE1-----------------PE3-------
eth2 eth1 eth0 eth2
12.0.0.0/24 =20
These are the .conf files I use for PE1:
ZEBRA
------------------------------------------------------------------
!
hostname PE1
password root
log file /var/log/quagga/zebra.log
debug zebra events
debug zebra kernel
!
!
interface lo
!
!
interface eth1
!
interface eth2
!
!
OSPFD
------------------------------------------------------------------
!
hostname PE1
password root
log file /var/log/quagga/ospfd.log
!
!
!
interface eth1
description 12.0.0.1 netmask 255.255.255.0 broadcast 12.0.0.255 ! =
interface
eth2 description 13.0.0.1 netmask 255.255.255.0 broadcast 13.0.0.255 !
interface lo ! router ospf ospf router-id 0.0.0.1 network 12.0.0.0/24 =
area
0 network 13.0.0.0/24 area 0 ! line vty !
LDPD
------------------------------------------------------------------
!
hostname PE1
password root
log file /var/log/quagga/ldpd.log
!
interface eth1
mpls ip
!
interface eth2
!
interface lo
!
!
line vty
!
VTYSH
------------------------------------------------------------------
!
service integrated-vtysh-config
hostname PE1
!
As you suggested, after running all those daemons (zebra -d, ospfd -d,
ldpd-d) I type "vtysh" to finally set the proper LDPD commands: "mpls =
ldp",
and in each interface of 12.0.0.0/24 subnet, "mpls ip" and "mpls =
labelspace
0".
I got some problems with mpls labelspace, cause sometimes when I type =
the
command occurs an I/O error and the daemon zebra is killed. In the end, =
when
it works, I capture the traffic and this is what happens:
1.Both PEs pass the stage of discovering with HELLO messages.
2.I can see INITIALIZATION messages in both ways, but the ones from 12.2 =
to
12.1 have a TCP checksum error. However, the LDP message seems to be
correct. With correct LSRs identifiers and these session parameters:
-Downstream unsolicited mode.
-Loop detection disabled.
-MPLS labelspace 0.
3.The KEEPALIVEs in the way PE1 also travel with checksum error as well =
as
all types of LDP messages but HELLOs. The ADDRESS messages are set with =
the
correct values of neighbor address.
4.The LABEL MAPPING messages carry the value of a label inside, which is =
the
same for both ways, 10000.
5.The problem is that after distributing the labels, 12.1 sends to 12.2 =
a
NOTIFICATION message with the status: fatal error, session rejected and =
then
the process starts again, now exchanging different values of labels =
(always
the same in both ways) 10001, 10002 and so on.
This is what I get in PE1 and the same in PE2 with other addresses:
PE1# sh ldp neig
Peer LDP Ident: 14.0.0.1:0; Local LDP Ident: 13.0.0.1:0
TCP connection: 0.0.0.0.646 - 12.0.0.2.45099
State: OPERATIONAL; Msgs sent/recv: 489/1459; UNSOLICITED
Up time: 02:00:24
LDP discovery sources:
eth1
Addresses bound to peer:
12.0.0.2 14.0.0.1
I try to do: ping -c3 14.0.0.1 from PE1, but the ICMP packets don't =
carry
any LDP label. Besides, MPLS NHLFE and MPLS ILM tables are empty.
Is this the expected behavior?
Thanks in advance,
Gonzalo
|
|
From: <gsr...@al...> - 2006-11-23 17:58:53
|
Hi!
Thanks for your information.
>Make sure you have the mpls4 module loaded into the kernel
>otherwise all attempts by LDP to install a ILM or NHLFE will fail, =
causing
>the LDP sessions to fail.
I have this module loaded into the kernel ever since system boots. I =
decided to make the file "mpls.modules" to have mpls4, mpls and =
mpls_tunnel always loaded to perform LSPs and tunnels experiments.=20
>You can also check what is happening at the kernel level by looking
>at the output of 'dmesg'. It will probably show all sorts of MPLS =
related
>debug.
When I type "dmesg" this is the output:
MPLS DEBUG net/mpls/mpls_tunnel.c:279:mpls_tunnel_ioctl: enter
MPLS DEBUG net/mpls/mpls_tunnel.c:298:mpls_tunnel_ioctl: enter
This two lines repeated lots of times, nothing else related to MPLS.
In those mpls_tunnel.c lines there're calls to MPLS_ENTER, that is =
defined in mpls.h as follows: #define MPLS_ENTER MPLS_DEBUG("enter\n"). =
Anyway, I suppose this module (I mean mpls_tunnel) has nothing to do =
with the config I tried for LDPD to open only simple LSPs.
>Finally, after a failed attempt by LDP, make sure you manually clean
>up the ILMs and NHLFEs.
I've tested ILMs and NHLFEs before and after running ZEBRA, OSPFD and =
LDPD and typing the additional commands by vtysh, and they kept empty.
So, do you know where I could look at, any clue...?
Thanks in advance,
Gonzalo.
|
|
From: James R. L. <jl...@mi...> - 2006-11-24 16:35:39
|
It looks like something is wrong with the communications with the
kernel.
=46rom the command line can you try creating and deleting ILM and NHLFE
then show me the results of a:
mpls ilm show
mpls nhlfe show
dmesg | grep -i MPLS
On Thu, Nov 23, 2006 at 06:59:23PM +0100, Sienes Rodr?guez Gonzalo wrote:
> Hi!
>=20
> Thanks for your information.
>=20
> >Make sure you have the mpls4 module loaded into the kernel
> >otherwise all attempts by LDP to install a ILM or NHLFE will fail, causi=
ng
> >the LDP sessions to fail.
>=20
> I have this module loaded into the kernel ever since system boots. I deci=
ded to make the file "mpls.modules" to have mpls4, mpls and mpls_tunnel alw=
ays loaded to perform LSPs and tunnels experiments.=20
>=20
> >You can also check what is happening at the kernel level by looking
> >at the output of 'dmesg'. It will probably show all sorts of MPLS relat=
ed
> >debug.
>=20
> When I type "dmesg" this is the output:
>=20
> MPLS DEBUG net/mpls/mpls_tunnel.c:279:mpls_tunnel_ioctl: enter
> MPLS DEBUG net/mpls/mpls_tunnel.c:298:mpls_tunnel_ioctl: enter
>=20
> This two lines repeated lots of times, nothing else related to MPLS.
> In those mpls_tunnel.c lines there're calls to MPLS_ENTER, that is define=
d in mpls.h as follows: #define MPLS_ENTER MPLS_DEBUG("enter\n"). Anyway, I=
suppose this module (I mean mpls_tunnel) has nothing to do with the config=
I tried for LDPD to open only simple LSPs.
>=20
> >Finally, after a failed attempt by LDP, make sure you manually clean
> >up the ILMs and NHLFEs.
>=20
> I've tested ILMs and NHLFEs before and after running ZEBRA, OSPFD and LDP=
D and typing the additional commands by vtysh, and they kept empty.
>=20
> So, do you know where I could look at, any clue...?
>=20
> Thanks in advance,
>=20
> Gonzalo.
>=20
--=20
James R. Leu
jl...@mi...
|
|
From: <gsr...@al...> - 2006-11-27 09:56:32
|
Hi, James:
This is what I get with "dmesg" related to mpls as soon as system boots. =
I
have also loaded the "mpls4" module that at the same time loads "mpls"
module:
[root@PE1 ~]# lsmod | grep mpls
mpls4 6081 0
mpls 78465 2 mpls4
Linux version 2.6.15-1.1831_FC4mpls_1.950 (jleu@jleu-laptop) (gcc =
version
4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Sun Feb 26 15:00:23 CST 2006
MPLS: version 1.950
MPLS: protocol driver interface - <jl...@mi...>
MPLS DEBUG net/mpls/mpls_sysfs.c:130:mpls_sysfs_init: enter MPLS DEBUG
net/mpls/mpls_sysfs.c:139:mpls_sysfs_init: exit
MPLS: IPv4 over MPLS support
MPLS DEBUG net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter MPLS DEBUG
net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit
These are the new lines output by dmesg when I type:
[root@PE1 ~]# mpls ilm show
[root@PE1 ~]# mpls nhlfe show
MPLS DEBUG net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry =
0
MPLS DEBUG net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 0
MPLS DEBUG net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: =
entry 0
MPLS DEBUG net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry =
0
The next I tried was to create a NHLFE entry and an ILM entry:
[root@PE1 ~]# mpls nhlfe add key 0
NHLFE entry key 0x00000002 mtu 0 propagate_ttl
(0 bytes, 0 pkts)
[root@PE1 ~]# mpls ilm add label gen 100 labelspace 0
[root@PE1 ~]# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 0 propagate_ttl
(0 bytes, 0 pkts)
[root@PE1 ~]# mpls ilm show
ILM entry label gen 100 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
...and their respective lines in dmesg output:
MPLS DEBUG net/mpls/mpls_netlink.c:298:genl_mpls_nhlfe_new: enter MPLS =
DEBUG
net/mpls/mpls_nhlfe.c:394:mpls_add_out_label: enter MPLS DEBUG
net/mpls/mpls_nhlfe.c:130:nhlfe_dst_alloc: enter MPLS DEBUG
net/mpls/mpls_nhlfe.c:151:nhlfe_dst_alloc: exit MPLS DEBUG
net/mpls/mpls_netlink.c:275:mpls_nhlfe_event: enter MPLS DEBUG
net/mpls/mpls_netlink.c:235:mpls_fill_nhlfe: enter MPLS DEBUG
net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
net/mpls/mpls_netlink.c:259:mpls_fill_nhlfe: exit MPLS DEBUG
net/mpls/mpls_netlink.c:289:mpls_nhlfe_event: exit MPLS DEBUG
net/mpls/mpls_nhlfe.c:451:mpls_add_out_label: exit MPLS DEBUG
net/mpls/mpls_netlink.c:335:genl_mpls_nhlfe_new: Exit: 0 MPLS DEBUG
net/mpls/mpls_netlink.c:115:genl_mpls_ilm_new: enter MPLS DEBUG
net/mpls/mpls_ilm.c:522:mpls_add_in_label: enter MPLS DEBUG
net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter MPLS DEBUG
net/mpls/mpls_ilm.c:109:ilm_dst_gc: enter MPLS DEBUG
net/mpls/mpls_ilm.c:110:ilm_dst_gc: exit MPLS DEBUG
net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit MPLS DEBUG
net/mpls/mpls_netlink.c:91:mpls_ilm_event: enter MPLS DEBUG
net/mpls/mpls_netlink.c:53:mpls_fill_ilm: enter MPLS DEBUG
net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
net/mpls/mpls_netlink.c:76:mpls_fill_ilm: exit MPLS DEBUG
net/mpls/mpls_netlink.c:106:mpls_ilm_event: exit MPLS DEBUG
net/mpls/mpls_ilm.c:582:mpls_add_in_label: exit MPLS DEBUG
net/mpls/mpls_netlink.c:145:genl_mpls_ilm_new: Exit: 0 MPLS DEBUG
net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: entry 0 MPLS =
DEBUG
net/mpls/mpls_netlink.c:397:genl_mpls_nhlfe_dump: Dump: entry 0 MPLS =
DEBUG
net/mpls/mpls_netlink.c:235:mpls_fill_nhlfe: enter MPLS DEBUG
net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
net/mpls/mpls_netlink.c:259:mpls_fill_nhlfe: exit MPLS DEBUG
net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry 1 MPLS =
DEBUG
net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: entry 1 MPLS =
DEBUG
net/mpls/mpls_netlink.c:397:genl_mpls_nhlfe_dump: Dump: entry 0 MPLS =
DEBUG
net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry 1 MPLS =
DEBUG
net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry 0 MPLS =
DEBUG
net/mpls/mpls_netlink.c:207:genl_mpls_ilm_dump: Dump: entry 0 MPLS DEBUG
net/mpls/mpls_netlink.c:53:mpls_fill_ilm: enter MPLS DEBUG
net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
net/mpls/mpls_netlink.c:76:mpls_fill_ilm: exit MPLS DEBUG
net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 1 MPLS DEBUG
net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry 1 MPLS =
DEBUG
net/mpls/mpls_netlink.c:207:genl_mpls_ilm_dump: Dump: entry 0 MPLS DEBUG
net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 1
I hope you'll have a look at it and you could tell me something about.
If it helps here are the RPMs installed related to MPLS:
[root@l12p07 ~]# rpm -qa | grep mpls iproute-2.6.11-1_mpls_90.1162552079
//In this version of iproute I have
//only modified the usage of
//mpls_tunnel command
iptables-1.3.0-2_mpls_1.950d
kernel-2.6.15-1.1831_FC4mpls_1.950
glibc-kernheaders-3.0-5.2_mpls0.1162999872
quagga-0.99.4-2006111701_mpls_0.1163780539
quagga-contrib-0.99.4-2006111701_mpls_0.1163780539
quagga-debuginfo-0.99.4-2006111701_mpls_0.1163780539
quagga-devel-0.99.4-2006111701_mpls_0.1163780539
kernel-devel-2.6.15-1.1831_FC4mpls_1.950
Thanks for your time,
regards:
Gonzalo
|
|
From: James R. L. <jl...@mi...> - 2006-12-01 01:29:20
|
It looks like you've got a working MPLS kernel. Try building a LSP
via the quagga interface, in vtysh try:
monkey1(config)# mpls static 0
monkey1(config-ls)# label-map gen 160 swap gen 170 nexthop eth2 192.168.4.2
monkey1(config-ls)# end
monkey1# show mpls forwarding
Insegments:
Lbl Spc Label Owner
0 160 static (inactive)
Total 1
Outsegments:
Interface Label Next Hop Owner
eth2 170 192.168.4.2 static (inactive)
Total 1
Cross Connects:
Lbl Spc In Label Out Label Interface Next Hop Owner
0 160 170 eth2 192.168.4.2 static (inac=
tive)Total 1
monkey1#
Make sure you're seeing the MPLS debug in 'dmesg'
BTW your should update your quagga-mpls and ldp-portable tree, I have submi=
tted
lots of changes since you built your RPM.
On Mon, Nov 27, 2006 at 10:56:37AM +0100, Sienes Rodr?guez Gonzalo wrote:
>=20
> Hi, James:
>=20
> This is what I get with "dmesg" related to mpls as soon as system boots. I
> have also loaded the "mpls4" module that at the same time loads "mpls"
> module:
>=20
> [root@PE1 ~]# lsmod | grep mpls
> mpls4 6081 0
> mpls 78465 2 mpls4
>=20
> Linux version 2.6.15-1.1831_FC4mpls_1.950 (jleu@jleu-laptop) (gcc version
> 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Sun Feb 26 15:00:23 CST 2006
>=20
> MPLS: version 1.950
> MPLS: protocol driver interface - <jl...@mi...>
> MPLS DEBUG net/mpls/mpls_sysfs.c:130:mpls_sysfs_init: enter MPLS DEBUG
> net/mpls/mpls_sysfs.c:139:mpls_sysfs_init: exit
> MPLS: IPv4 over MPLS support
> MPLS DEBUG net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter MPLS DEBUG
> net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit
>=20
> These are the new lines output by dmesg when I type:
>=20
> [root@PE1 ~]# mpls ilm show
> [root@PE1 ~]# mpls nhlfe show
>=20
> MPLS DEBUG net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry 0
> MPLS DEBUG net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 0
> MPLS DEBUG net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: entry=
0
> MPLS DEBUG net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry 0
>=20
> The next I tried was to create a NHLFE entry and an ILM entry:
>=20
> [root@PE1 ~]# mpls nhlfe add key 0
> NHLFE entry key 0x00000002 mtu 0 propagate_ttl
> (0 bytes, 0 pkts)
>=20
> [root@PE1 ~]# mpls ilm add label gen 100 labelspace 0
>=20
> [root@PE1 ~]# mpls nhlfe show
> NHLFE entry key 0x00000002 mtu 0 propagate_ttl
> (0 bytes, 0 pkts)
>=20
> [root@PE1 ~]# mpls ilm show
> ILM entry label gen 100 labelspace 0 proto ipv4
> pop peek (0 bytes, 0 pkts)
>=20
> ...and their respective lines in dmesg output:
>=20
> MPLS DEBUG net/mpls/mpls_netlink.c:298:genl_mpls_nhlfe_new: enter MPLS DE=
BUG
> net/mpls/mpls_nhlfe.c:394:mpls_add_out_label: enter MPLS DEBUG
> net/mpls/mpls_nhlfe.c:130:nhlfe_dst_alloc: enter MPLS DEBUG
> net/mpls/mpls_nhlfe.c:151:nhlfe_dst_alloc: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:275:mpls_nhlfe_event: enter MPLS DEBUG
> net/mpls/mpls_netlink.c:235:mpls_fill_nhlfe: enter MPLS DEBUG
> net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
> net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:259:mpls_fill_nhlfe: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:289:mpls_nhlfe_event: exit MPLS DEBUG
> net/mpls/mpls_nhlfe.c:451:mpls_add_out_label: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:335:genl_mpls_nhlfe_new: Exit: 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:115:genl_mpls_ilm_new: enter MPLS DEBUG
> net/mpls/mpls_ilm.c:522:mpls_add_in_label: enter MPLS DEBUG
> net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter MPLS DEBUG
> net/mpls/mpls_ilm.c:109:ilm_dst_gc: enter MPLS DEBUG
> net/mpls/mpls_ilm.c:110:ilm_dst_gc: exit MPLS DEBUG
> net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:91:mpls_ilm_event: enter MPLS DEBUG
> net/mpls/mpls_netlink.c:53:mpls_fill_ilm: enter MPLS DEBUG
> net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
> net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:76:mpls_fill_ilm: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:106:mpls_ilm_event: exit MPLS DEBUG
> net/mpls/mpls_ilm.c:582:mpls_add_in_label: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:145:genl_mpls_ilm_new: Exit: 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: entry 0 MPLS DEB=
UG
> net/mpls/mpls_netlink.c:397:genl_mpls_nhlfe_dump: Dump: entry 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:235:mpls_fill_nhlfe: enter MPLS DEBUG
> net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
> net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:259:mpls_fill_nhlfe: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry 1 MPLS DEBUG
> net/mpls/mpls_netlink.c:394:genl_mpls_nhlfe_dump: Enter: entry 1 MPLS DEB=
UG
> net/mpls/mpls_netlink.c:397:genl_mpls_nhlfe_dump: Dump: entry 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:411:genl_mpls_nhlfe_dump: Exit: entry 1 MPLS DEBUG
> net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:207:genl_mpls_ilm_dump: Dump: entry 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:53:mpls_fill_ilm: enter MPLS DEBUG
> net/mpls/mpls_instr.c:188:mpls_instrs_unbuild: enter MPLS DEBUG
> net/mpls/mpls_instr.c:201:mpls_instrs_unbuild: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:76:mpls_fill_ilm: exit MPLS DEBUG
> net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 1 MPLS DEBUG
> net/mpls/mpls_netlink.c:204:genl_mpls_ilm_dump: Enter: entry 1 MPLS DEBUG
> net/mpls/mpls_netlink.c:207:genl_mpls_ilm_dump: Dump: entry 0 MPLS DEBUG
> net/mpls/mpls_netlink.c:221:genl_mpls_ilm_dump: Exit: entry 1
>=20
> I hope you'll have a look at it and you could tell me something about.
>=20
> If it helps here are the RPMs installed related to MPLS:
>=20
> [root@l12p07 ~]# rpm -qa | grep mpls iproute-2.6.11-1_mpls_90.1162552079
> //In this version of iproute I have
> //only modified the usage of
> //mpls_tunnel command
> iptables-1.3.0-2_mpls_1.950d
> kernel-2.6.15-1.1831_FC4mpls_1.950
> glibc-kernheaders-3.0-5.2_mpls0.1162999872
> quagga-0.99.4-2006111701_mpls_0.1163780539
> quagga-contrib-0.99.4-2006111701_mpls_0.1163780539
> quagga-debuginfo-0.99.4-2006111701_mpls_0.1163780539
> quagga-devel-0.99.4-2006111701_mpls_0.1163780539
> kernel-devel-2.6.15-1.1831_FC4mpls_1.950
>=20
>=20
> Thanks for your time,
> regards:
>=20
> Gonzalo
>=20
--=20
James R. Leu
jl...@mi...
|
|
From: <gsr...@al...> - 2006-12-01 17:09:57
|
Hi, again:
This is the scenario I use:
13.0.0.0/24 .1 .1 .2 .1 11.0.0.0/24
-------PE1-----------------PE2-------
eth2 eth1 eth0 eth1
10.0.0.0/24 =20
I've compiled the latest quagga-mpls and ldp-portable from your =
repository:
=20
[root@l12p07 ~]# rpm -qa | grep quagga
quagga-contrib-0.99.5-2006120101_mpls_0.1164964523
quagga-0.99.5-2006120101_mpls_0.1164964523
quagga-debuginfo-0.99.5-2006120101_mpls_0.1164964523
quagga-devel-0.99.5-2006120101_mpls_0.1164964523
I tried what you suggested and this is what happens (on PE2), after =
launching zebra, ospfd and ldpd:
[root@l12p07 Scripts_Ord2]# vtysh
Hello, this is Quagga (version 0.99.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
PE2# con t
PE2(config)# mpls static 0
PE2(config-ls)# label-map gen 160 swap gen 170 nexthop eth1 =
10.0.0.1
Warning: closing connection to zebra because of an I/O error!
PE2(config-ls)#
This is what dmesg prints at this time:
[root@l12p07 ~]# dmesg | grep mpls
Linux version 2.6.15-1.1831_FC4mpls_1.950 (root@localhost.localdomain) =
(gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)) #1 Fri Oct 13 17:52:43 =
CEST 2006
MPLS DEBUG net/mpls/mpls_sysfs.c:130:mpls_sysfs_init: enter
MPLS DEBUG net/mpls/mpls_sysfs.c:139:mpls_sysfs_init: exit
MPLS DEBUG net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter
MPLS DEBUG net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit
Then I tried with another ip address that doesn't belong to the =
scenario:
Hello, this is Quagga (version 0.99.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
PE2# con t
PE2(config)# mpls static 0
PE2(config-ls)# label-map gen 160 swap gen 170 nexthop eth1 172.29.17.60
PE2(config-ls)# end
PE2# show mpls forwarding
Insegments:
Lbl Spc Label Owner
0 160 static
Total 1
Outsegments:
Interface Label Next Hop Owner
eth1 170 172.29.17.60 static (inactive)
Total 1
Cross Connects:
Lbl Spc In Label Out Label Interface Next Hop Owner
0 160 170 eth1 172.29.17.60 static =
(inactive)Total 1
PE2#
But the output of dmesg is always the same, although MPLS debug is =
running. This lines are the same that appear as I boot the system and =
load mpls4 and mpls modules. Furthermore, at any time NHLFEs and ILMs =
are empty:
[root@l12p07 Scripts_Ord2]# dmesg | grep mpls
Linux version 2.6.15-1.1831_FC4mpls_1.950 (root@localhost.localdomain) =
(gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)) #1 Fri Oct 13 17:52:43 =
CEST 2006
MPLS DEBUG net/mpls/mpls_sysfs.c:130:mpls_sysfs_init: enter
MPLS DEBUG net/mpls/mpls_sysfs.c:139:mpls_sysfs_init: exit
MPLS DEBUG net/mpls/mpls_ilm.c:126:mpls_ilm_dst_alloc: enter
MPLS DEBUG net/mpls/mpls_ilm.c:156:mpls_ilm_dst_alloc: exit
I expect your answer.
Thanks in advance,
Gonzalo
|
|
From: <gsr...@al...> - 2006-12-04 16:42:18
|
Hi once again:
>From your Perforce's repository I downloaded glibc-kernheaders-mpls and =
built the .rpm to install it:
[root@l12p07 ~]# rpm -q glibc-kernheaders
glibc-kernheaders-3.0-5.2_mpls0.1162999872
I have checked the file mpls.h in /usr/include/linux and =
/usr/src/kernels/2.6.15-1.1831_FC4mpls_1.950-i686/include/linux before =
compiling quagga-mpls with ldp-portable, and it's the same as the file =
in glibc-kernheaders-mpls.
I have also looked into the configure.ac file in quagga-mpls to make =
sure that the link to mpls.h was correct and it seems to be ok.
if grep MPLS_LINUX_VERSION /usr/include/linux/mpls.h >/dev/null =
2>&1; then
AC_DEFINE(HAVE_MPLS,1,Enable MPLS)
AC_DEFINE(LINUX_MPLS,1,Linux MPLS)
MPLS_METHOD=3D"mpls_netlink.o"
AC_MSG_RESULT(MPLS Linux)
Besides, I'm able to test static MPLS (without quagga) creating LSPs and =
TUNNELS succesfully even in the computer I use to build quagga.
I don't know where to look at, any help would be very useful,
thanks for your time,
Gonzalo
|
|
From: James R. L. <jl...@mi...> - 2006-12-04 19:01:42
|
Hello,
You'll have to fogive me, I do not remember what problem we're
working on. Please provide a ascii drawing or your network,
your full quagga config (from vtysh), and the output of:
sh ip route
sho ldp
show ldp discovery
show ldp neigh
show ldp data
show mpls forward
All from vtysh. In addition do a:
ip route show
mpls labelspace show
mpls ilm show
mpls nhlfe show
from the command line.
On Mon, Dec 04, 2006 at 05:41:18PM +0100, Sienes Rodr?guez Gonzalo wrote:
> Hi once again:
>=20
> >From your Perforce's repository I downloaded glibc-kernheaders-mpls and =
built the .rpm to install it:
>=20
> [root@l12p07 ~]# rpm -q glibc-kernheaders
> glibc-kernheaders-3.0-5.2_mpls0.1162999872
>=20
> I have checked the file mpls.h in /usr/include/linux and /usr/src/kernels=
/2.6.15-1.1831_FC4mpls_1.950-i686/include/linux before compiling quagga-mpl=
s with ldp-portable, and it's the same as the file in glibc-kernheaders-mpl=
s.
>=20
> I have also looked into the configure.ac file in quagga-mpls to make sure=
that the link to mpls.h was correct and it seems to be ok.
>=20
> if grep MPLS_LINUX_VERSION /usr/include/linux/mpls.h >/dev/null 2>&=
1; then
> AC_DEFINE(HAVE_MPLS,1,Enable MPLS)
> AC_DEFINE(LINUX_MPLS,1,Linux MPLS)
> MPLS_METHOD=3D"mpls_netlink.o"
> AC_MSG_RESULT(MPLS Linux)
>=20
> Besides, I'm able to test static MPLS (without quagga) creating LSPs and =
TUNNELS succesfully even in the computer I use to build quagga.
>=20
> I don't know where to look at, any help would be very useful,
> thanks for your time,
>=20
> Gonzalo
--=20
James R. Leu
jl...@mi...
|
|
From: James R. L. <jl...@mi...> - 2006-11-22 16:30:52
|
Make sure you have the mpls4 module loaded into the kernel otherwise all attempts by LDP to install a ILM or NHLFE will fail, causing the LDP sessions to fail. You can also check what is happening at the kernel level by looking at the output of 'dmesg'. It will probably show all sorts of MPLS related debug. Finally, after a failed attempt by LDP, make sure you manually clean up the ILMs and NHLFEs. On Wed, Nov 22, 2006 at 03:18:59PM +0100, Sienes Rodr?guez Gonzalo wrote: > Hi! >=20 > Thanks for your information. >=20 > I decided to test the new configuration in the following scenario, only w= ith > two routers to realized what LDP really does. =20 >=20 > 13.0.0.0/24 .1 .1 .2 .1 14.0.0.0/24 > -------PE1-----------------PE3------- > eth2 eth1 eth0 eth2 > 12.0.0.0/24 =20 >=20 > These are the .conf files I use for PE1: >=20 > ZEBRA > ------------------------------------------------------------------ > ! > hostname PE1 > password root > log file /var/log/quagga/zebra.log > debug zebra events > debug zebra kernel > ! > ! > interface lo > ! > ! > interface eth1 > ! > interface eth2 > ! > ! >=20 > OSPFD > ------------------------------------------------------------------ > ! > hostname PE1 > password root > log file /var/log/quagga/ospfd.log > ! > ! > ! > interface eth1 > description 12.0.0.1 netmask 255.255.255.0 broadcast 12.0.0.255 ! interf= ace > eth2 description 13.0.0.1 netmask 255.255.255.0 broadcast 13.0.0.255 ! > interface lo ! router ospf ospf router-id 0.0.0.1 network 12.0.0.0/24 a= rea > 0 network 13.0.0.0/24 area 0 ! line vty ! >=20 > LDPD > ------------------------------------------------------------------ > ! > hostname PE1 > password root > log file /var/log/quagga/ldpd.log > ! > interface eth1 > mpls ip > ! > interface eth2 > ! > interface lo > ! > ! > line vty > ! >=20 > VTYSH > ------------------------------------------------------------------ > ! > service integrated-vtysh-config > hostname PE1 > ! >=20 > As you suggested, after running all those daemons (zebra -d, ospfd -d, > ldpd-d) I type "vtysh" to finally set the proper LDPD commands: "mpls ldp= ", > and in each interface of 12.0.0.0/24 subnet, "mpls ip" and "mpls labelspa= ce > 0". >=20 > I got some problems with mpls labelspace, cause sometimes when I type the > command occurs an I/O error and the daemon zebra is killed. In the end, w= hen > it works, I capture the traffic and this is what happens: >=20 > 1.Both PEs pass the stage of discovering with HELLO messages. >=20 > 2.I can see INITIALIZATION messages in both ways, but the ones from 12.2 = to > 12.1 have a TCP checksum error. However, the LDP message seems to be > correct. With correct LSRs identifiers and these session parameters: >=20 > -Downstream unsolicited mode. > -Loop detection disabled. > -MPLS labelspace 0. >=20 > 3.The KEEPALIVEs in the way PE1 also travel with checksum error as well as > all types of LDP messages but HELLOs. The ADDRESS messages are set with t= he > correct values of neighbor address. >=20 > 4.The LABEL MAPPING messages carry the value of a label inside, which is = the > same for both ways, 10000. >=20 > 5.The problem is that after distributing the labels, 12.1 sends to 12.2 a > NOTIFICATION message with the status: fatal error, session rejected and t= hen > the process starts again, now exchanging different values of labels (alwa= ys > the same in both ways) 10001, 10002 and so on. >=20 > This is what I get in PE1 and the same in PE2 with other addresses: >=20 > PE1# sh ldp neig > Peer LDP Ident: 14.0.0.1:0; Local LDP Ident: 13.0.0.1:0 > TCP connection: 0.0.0.0.646 - 12.0.0.2.45099 > State: OPERATIONAL; Msgs sent/recv: 489/1459; UNSOLICITED > Up time: 02:00:24 > LDP discovery sources: > eth1 > Addresses bound to peer: > 12.0.0.2 14.0.0.1 >=20 > I try to do: ping -c3 14.0.0.1 from PE1, but the ICMP packets don't carry > any LDP label. Besides, MPLS NHLFE and MPLS ILM tables are empty. >=20 > Is this the expected behavior? >=20 > Thanks in advance, >=20 > Gonzalo >=20 > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel --=20 James R. Leu jl...@mi... |
×
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