mpls-linux-general — Mailing list for general discussion about MPLS for Linux

Re: [mpls-linux-general] VPNs using MPLS-Linux/LDP-Portable

[Yon U. <uk...@rz...>]

On Tue, 20 Feb 2001, Arm=E9nio Pinto wrote:
> Hi there,

Hi hi,


>      Has anyone tried to implement any kind of VPN using
> MPLS-Linux/LDP-Portable packages? Thanks in advance.


There is (was?) support for BGP-MPLS in zebra.

 For LDP you need:

1) mpls support in zebra (zebra <-> kernel interface)
2) mpls support in zebra protocol (zebra <-> daemons)
3) port ldp-portable to zebra


 For 1&2 you could just split Mr. Leu's mpls API (portability
layer) in two, translating it to the zebra framework, mantaining
the general function calls (just serializing them over the
zebra protocol). For 1, you have to write some kind of
mpls LIB manager, too.

 I have started on 3, it is a mess, doesn't do anything useful
yet, as I have problems understanding ldp-portable (to be
precise: I don't want to learn how ldp-portable works,
need-to-know is my keyword here).

 So I have some cut'n'pasted code. It is quite basic, yet.
I might start (paid) work soon, so I guess I'll put it up
for grabs. I'll mail you.


 Now, you wanted VPN, if you want to emulate cisco's vpn
code, you need VRF, that is:
1) different packet forwarding tables in zebra
2) a way to attach such vrf to an interface
3) a way to route routes from such vrfs to/from routing processes


1 might be easy, maybe. Look at zebra/lib/table.h and
zebra/lib/rib.* (at least). I'm no zebra expert.

2 is kernel dependent, linux 2.[2|4] could do it.
For linux you'll have to clean the "local"
table, too, or you will have problems, and
anyway, I guess there are some other details. Just
abstract this into a portable api for zebra.

3 zebra internals, see 1. Extend zebra protocol?


Oh, and you want different routing processes (per VPN,
at least, if not per interface), which isn't trivial
with zebra at the moment, though it is possible,
i've been told.


 Afterward, mpls-linux will do all you want, no need to
patch it, I guess.


Disclaimer: I'm no expert at anything, this are just ideas
  from my "a little knowledge and curiosity" standpoint.


Have fun,
 yon

[mpls-linux-general] VPNs using MPLS-Linux/LDP-Portable

[<ap...@av...>]

Hi there,

     Has anyone tried to implement any kind of VPN using
MPLS-Linux/LDP-Portable packages? Thanks in advance.

Arménio Pinto
PT Inovação SA

Re: [mpls-linux-general] ipip and mpls

[S. <j....@gm...>]

"James R. Leu" schrieb:

> <...>

>
> Depending on the order of things the route cache maybe interfering.
>
> Specifically the old route cache entry (using normal routing) may still=
 be
> in use.  One thing to try to eliminate this, is to let the route cache
> expire, or reboot router 2, then re-setup the MPLS tunnel, making sure =
not
> to send traffic from router1 to router3 before the MPLS tunnel is setup.
> I will look thourgh the code this weekend to see if there if I am some =
how not
> flushing the route cache at the right time.
>
> Another thing to look for is RPF or spoof filters.  Debian and a couple=
 of
> distributions put these in place, and hamper the use of MPLS tunnels (b=
ecause
> they are by there nature uni-directional and are a-symetric, this
> is exactly what RPF and spoof filters try to prevent :-).
>
> One last thing to help us help you :-) is turn on MPLS debugging (mplsa=
dm -d)
> and run a couple of pings, then turn it off (mplsadm -d again) and look=
 at the
> kernel log (dmesg).  If the MPLS code is being triggered you'll see gob=
s of
> debug messages, if the IP stack is the culprit you won't see any debug
> messages.
>
> I hope this helps,
> Jim
>

ok, I might find the problem ... even if it is a bit strange:
I have to build up ipip-tunnels bidirectional, what means, router2 in my =
example
needs to be configured with a tunneldevice, too. (Thanks for the idea)
It's really difficult to find appropriate information about ipip-tunnelin=
g in the
web, so I have to find out on my own.

Greetings - J=F6rn

Re: [mpls-linux-general] ipip and mpls

[James R. L. <jl...@mi...>]

> 
> ip route flush cache

You're probably right.  I don't use iproute2

>  this is not NT, you know?
:-)

>  I thought route had such a feature too, but it seems my memory
> is either leaking or it was a bsd's route option.

It must have been a BSD option:

[jleu jleu-laptop 9:51am]~-> route flush
Flushing `inet' routing table not supported

Jim

> 
> 
> HTH, HAND
>  yon
> 
> 
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu

Re: [mpls-linux-general] ipip and mpls

[Yon U. <uk...@rz...>]

Good morning,

 just a little detail (I hope my memory is still working,
check out the documentation):

On Fri, 16 Feb 2001, James R. Leu wrote:
>
> Depending on the order of things the route cache maybe interfering.
>
> Specifically the old route cache entry (using normal routing) may still be
> in use.  One thing to try to eliminate this, is to let the route cache
> expire, or reboot router 2, [...]


ip route flush cache

 this is not NT, you know?

 I thought route had such a feature too, but it seems my memory
is either leaking or it was a bsd's route option.


HTH, HAND
 yon

Re: [mpls-linux-general] ipip and mpls

[James R. L. <jl...@mi...>]

Hello,

On Fri, Feb 16, 2001 at 10:15:37AM +0000, J=F6rn Seger wrote:
> Hi everybody,
>=20
> I'm not sure, this is an mpls-problem, but somebody might have had the
> same problem:
>=20
> imagine the following simple environmet:
>=20
> router1 --- ipip-tunnel --- router2 --- mpls-tunnel --- router3
>=20
> now I just want an IP-packet to be send from router1 to router3.
> The ipip-tunnel works fine and so do the mpls-tunnel. But when I work
> with the mentioned environment, the packets (pings) disappeare at route=
r
> 2.
> If I change one of the connection into a "normal route" everything work
> fine again.

Depending on the order of things the route cache maybe interfering.=20

Specifically the old route cache entry (using normal routing) may still b=
e
in use.  One thing to try to eliminate this, is to let the route cache
expire, or reboot router 2, then re-setup the MPLS tunnel, making sure no=
t
to send traffic from router1 to router3 before the MPLS tunnel is setup.
I will look thourgh the code this weekend to see if there if I am some ho=
w not
flushing the route cache at the right time.

Another thing to look for is RPF or spoof filters.  Debian and a couple o=
f
distributions put these in place, and hamper the use of MPLS tunnels (bec=
ause
they are by there nature uni-directional and are a-symetric, this
is exactly what RPF and spoof filters try to prevent :-).

One last thing to help us help you :-) is turn on MPLS debugging (mplsadm=
 -d)
and run a couple of pings, then turn it off (mplsadm -d again) and look a=
t the
kernel log (dmesg).  If the MPLS code is being triggered you'll see gobs =
of
debug messages, if the IP stack is the culprit you won't see any debug
messages.

I hope this helps,
Jim

> Could anyone tell me what to do to get this work?
>=20
> Thanks - J=F6rn
>=20
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu

[mpls-linux-general] ipip and mpls

[S. <j....@gm...>]

Hi everybody,

I'm not sure, this is an mpls-problem, but somebody might have had the
same problem:

imagine the following simple environmet:

router1 --- ipip-tunnel --- router2 --- mpls-tunnel --- router3

now I just want an IP-packet to be send from router1 to router3.
The ipip-tunnel works fine and so do the mpls-tunnel. But when I work
with the mentioned environment, the packets (pings) disappeare at router
2.
If I change one of the connection into a "normal route" everything work
fine again.

Could anyone tell me what to do to get this work?

Thanks - J=F6rn

Re: [mpls-linux-general] Temporary TC Patch

[Steven V. d. B. <ste...@in...>]

Hi Jon et al.,

The ability for having multile tables for LSP generation is not removed, it
just isn't available yet (sorry). I'll produce this as a seperate patch (since
i believe it has a way more wider applicability then traffic control).
The reason why it takes so long to complete this is:
   a) i used a really dirty (and slow) hack to do this in the previous version
of the patch, and i'll try to find another way now.
   b) i'm currently investigating if i can combine some multipath possibilities
in the patch

To elaborate on the last point: current multipath implementation in linux uses
a hashing based selection of nexthops connected to the same FIB entry. Since
mpls redirects the output, it loses this information. So now i'm looking if i
can't do multipath over several FIB entries, enabling multipath over a hybrid
MPLS/pure IP network (e.g. multipath over a shortest path on IP and a not so
short path over MPLS).

The goal is to get something ready by the end of next week.

While i'm at it, I must warn you that i haven't really tested the TC patch
(only tried it with UML), so you must use it with care. To avoid you wondering
why things don't seem to be working, the biggest change now is that the
*incoming* label is used to select the DSCP. In case of the ingress LER, this
means that the incoming DSCP is used (so you need host-marked traffic, or a
marker before that).

Cheers,
Steven

Jonathan Earle wrote:

> Perhaps this is a tad premature - I've just got my lab back in shape after
> the move and was about to build myself the latest and greatest Linux + MPLS.
> In reading the docs with your latest patch, am I correct in noticing that
> the ability to employ multiple tables for LSP generation has been removed?
>
> Cheers!
> Jon
>
>
>  -----Original Message-----
> From: Steven Van den Berghe [mailto:ste...@in...]
> Sent: Thursday, February 08, 2001 6:19 AM
> To: mpl...@li...; James R. Leu
> Subject: [mpls-linux-general] Temporary TC Patch
>
> Hi MPLSers,
>
> I've used the sourceforge patch manager to uplad a new tc-patch. It seems
> that the interface needs a real raw patch, and not a .tgz file. So, since
> the patch manager isn't useful for this, i'll send it on the list.
>
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

RE: [mpls-linux-general] Temporary TC Patch

[Jonathan E. <je...@no...>]

Perhaps this is a tad premature - I've just got my lab back in shape after
the move and was about to build myself the latest and greatest Linux + MPLS.
In reading the docs with your latest patch, am I correct in noticing that
the ability to employ multiple tables for LSP generation has been removed?
 
Cheers!
Jon
 
 
 -----Original Message-----
From: Steven Van den Berghe [mailto:ste...@in...]
Sent: Thursday, February 08, 2001 6:19 AM
To: mpl...@li...; James R. Leu
Subject: [mpls-linux-general] Temporary TC Patch



Hi MPLSers, 

I've used the sourceforge patch manager to uplad a new tc-patch. It seems
that the interface needs a real raw patch, and not a .tgz file. So, since
the patch manager isn't useful for this, i'll send it on the list. 

Re: [mpls-linux-general] Performing quick multiple popping

[James R. L. <jl...@mi...>]

On Fri, Feb 02, 2001 at 01:18:55PM -0500, Francois Desloges wrote:
> Hello all.
>=20
> 	I have a question regarding the interpretation of LDP and its
> applicability in the _real_world_.
>=20
> 	MPLS architecture specifies that if the NextHop is the LSR itself
> (I'll say Myself from now on), you would pop the top label and then pro=
ceed with
> the next label.
>=20
> 	For obvious hardware acceleraton purpose I would like to distribute th=
e
> same label value for _all_ LSPs that terminate at a specific LSR and ne=
ed to
> distibute a label that means POP-and-send-to-myself.
>=20
> 	Do anybody knows a good reason not to do so ? Problems related to
> this practice in the real world ? How do this LDP implementation (and o=
thers if
> anybody has the experience :-) enables me to do so ?

Hello Francois,

Sorry for the delay in getting back to you about this question.
It is hard to give you a definite answer about this.  There are a couple =
of
things to consider when thinking about how to optimize multiple label pop=
ping.

1. Remember that any label an LSR or LER is switching on has been
allocated by the signalling protocols running on it.  If enough informati=
on
is known about why/how the label(s) were allocated, then yes, it is possi=
ble to
know that the LSR can pop X number of labels.  It would take intelligent
software to know all of the rules and conditions though.

2. When trying to pop X number of labels, it is possible that some of the
information about where the label came from, or treatment the packet shou=
ld
recieve (PHB QoS Cos etc), could be lost if the LSR doesn't inspect every
level.  For example, if the skipped labels are part of L-LSPs then, in th=
eory,
the info from #1 should catch it.  If the skipped labels are part of E-LS=
Ps
then I think the LSR has to inspect every label to achive the correct
treatment.  So by using the info from #1 the LSR can know whether optimiz=
ed
popping can be used or if "slow-fast" path must be used.

3.  When it doing individual labe processing t is only neccessary to hand=
le
a depth of 4 labels to be used at the edge of current MPLS domains, if yo=
u
want to play in the core you probably only need to support a depth of 3.

(the reason for choosing 4 at the edge and 3 in the core come from curren=
t
deployments and the limits of currently deployed implementations)

(when I say "support a depth of 3" that means that the LSR can manuipulat=
e
and operate on the top 3 labels, more may exist which were allocated
by other LSRs)

If you still have questions or want diagrams that show examples, I can tr=
y to
draw some for you.  It's too hard to explain them with just words
and ascii drawings :-)

Jim

> Thanks !
>=20
> --=20
> Fran=E7ois Desloges
> fd...@vi...
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu

[mpls-linux-general] VPNV4 VRF's and NAT

[James T. <eu...@ca...>]

Hi all.

The company I work for has been trying to find a firewall appliance that
can handle NAT on a per VRF basis (multiple customer VPN's that quite
possibly will have overlapping address-space).

I was just wondering if I can use MPLS-Linux and linux's IP_MASQ in a
Linux Router Project box.

Any help you guys can give me would be excellent.

---
Caudium Project.
The Other Fish.
http://caudium.net/

[mpls-linux-general] Performing quick multiple popping

[Francois D. <fd...@vi...>]

Hello all.

	I have a question regarding the interpretation of LDP and its
applicability in the _real_world_.

	MPLS architecture specifies that if the NextHop is the LSR itself
(I'll say Myself from now on), you would pop the top label and then proceed with
the next label.

	For obvious hardware acceleraton purpose I would like to distribute the
same label value for _all_ LSPs that terminate at a specific LSR and need to
distibute a label that means POP-and-send-to-myself.

	Do anybody knows a good reason not to do so ? Problems related to
this practice in the real world ? How do this LDP implementation (and others if
anybody has the experience :-) enables me to do so ?

Thanks !

-- 
François Desloges
fd...@vi...

[mpls-linux-general] mpls-linux 0.802

[James R. L. <jl...@mi...>]

I just release mpls-linux-0.802.  Head over to:

http://sourceforge.net/projects/mpls-linux/

to download it.

0.802
-updated to kernel 2.4.1
-fix route refresh bug, cause by zebra and gated



-- 
James R. Leu

[mpls-linux-general] Uses of MPLS LInux

[James R. L. <jl...@mi...>]

Hello everyone,

I'm trying to get an understanding of who and how MPLS for Linux is being
used.  If you're activtly using mpls-linux or ldp-portable please let me know.

A description of what you're doing with it would be appreciated but is not
required.

The feed back from this will help me decide where to concentrate my efforts.

Thanks,
Jim
-- 
James R. Leu

[mpls-linux-general] FYI

[James R. L. <jl...@mi...>]

I'm not sure if everyone knows this or not, but there is a project page
for "MPLS for Linux" at SourceForge.

http://sourceforge.net/projects/mpls-linux/

SourceForge has some tools that are useful. If people start using them, maybe
I'l be able o keep things a little more organized :-)

Bug Tracker
Mailing List
CVS Repository
FTP
Release Manager

Thanks,
Jim
-- 
James R. Leu

[mpls-linux-general] CVS access

[James R. L. <jl...@mi...>]

Hello all,

I just wanted to let people know that they can get the most up-to-date version
of mpls-linux and ldp-portable via CVS.  Goto:

http://sourceforge.net/projects/mpls-linux/

And follow the link to CVS.  The statistic about 0 commits is wrong :-)
The CVS tree has some stale modules.  For example zebra iproute2 and linux are
all stale and will be removed as soon as the sourceforge support team gets
around to answering my request   :-)

If you have any problems using CVS or run into any non-working features/bugs/
crashes, let me know, I'll try to get fixes into CVS ASAP.

Thanks,
Jim
-- 
James R. Leu

[mpls-linux-general] Integration with L3 routing protocol

[Francois D. <fd...@vi...>]

Hello Jim!

	I was wondering. Although the ldp deamon is not integrated with any L3
routing protocol right now, (let's say ospfd from zebra:-). Is it possible for
the ldp deamon to read the FIB, and start building LSPs based on that,
instead of being fed directly from ospfd ?

	JP had the feeling that ldp was using the static route to create LSPs and was
wondering if it was possible to do the same thing with routes fed in the FIB
with zebra...

	Are we totally out of our shirt or what ?

Thanks :-)

FD

[mpls-linux-general] Re: MPLS stack observed using Ethereal analyzer !!

[James R. L. <jl...@mi...>]

There is currently a bug wit the MPLS stack that results in programs
like tcpdump and ethereal to see invalid packet when they are run on an LER.

Try running then from a host observing the traffic, nat participating in it.

Jim

On Tue, Jan 30, 2001 at 05:40:21PM -0600, Nanda, Debasis wrote:
> Hi James,
> 
> I have setup a small MPLS domain in our lab for testing using your
> implementation of linux-mpls.
> 
> I have the following configuration
> 
> (Please use prefix 168.219. for all ip address below )
> 
>         79.44	79.2	80.1     80.2	81.1	  81.2	82.2   82.45
>    --------        -------         ------           -------         --------
>   | Host 1 |------| LER 1 |-------| LSR 1|---------| LER 2 |-------| Host 2
> |
>    --------        -------         ------           -------         --------
>          eth0    eth2   eth0     eth0  eth1       eth0   eth2     eth0
> 
> 
> 
> 
> I observer that when a MPLS packet gets switched ( label swaping) in a LSR ,
> at the out port (interface) in either direction I get MPLS label stack . For
> example when a packet traverses from Host1 to Host 2 , it's label gets
> swaped at LSR 1. When I run Ethereal at LER2-eth0, I observer three MPLS
> heaser on each packet directed from LSR1 to LER2 . 
> 
> Frame 1 (102 on wire, 102 captured)
> Ethernet II
> MultiProtocol Label Switching Header
> MultiProtocol Label Switching Header
> MultiProtocol Label Switching Header
> Internet Protocol
> 
> A detailed packet dump is shown below along with the hex dump.
> 
> 
> 
> 
> Frame 1 (102 on wire, 102 captured)
>     Arrival Time: Jan 30, 2001 16:14:01.3064
>     Time delta from previous packet: 0.000000 seconds
>     Time relative to first packet: 0.000000 seconds
>     Frame Number: 1
>     Packet Length: 102 bytes
>     Capture Length: 102 bytes
> Ethernet II
>     Destination: 00:01:02:85:35:d5 (00:01:02:85:35:d5)
>     Source: 00:01:02:85:36:81 (00:01:02:85:36:81)
>     Type: MPLS label switched packet (0x8847)
> MultiProtocol Label Switching Header
>     MPLS Label: Unknown (282624)
>     MPLS Experimental Bits: 0
>     MPLS Bottom Of Label Stack: 0
>     MPLS TTL: 84
> MultiProtocol Label Switching Header
>     MPLS Label: Unknown (80032)
>     MPLS Experimental Bits: 0
>     MPLS Bottom Of Label Stack: 0
>     MPLS TTL: 0
> MultiProtocol Label Switching Header
>     MPLS Label: Unknown (258071)
>     MPLS Experimental Bits: 2
>     MPLS Bottom Of Label Stack: 1
>     MPLS TTL: 15
> Internet Protocol
>     Version: 10
>     Header length: 32 bytes
>     Differentiated Services Field: 0xdb (DSCP 0x36: Unknown DSCP; ECN: 0x03)
>         1101 10.. = Differentiated Services Codepoint: Unknown (0x36)
>         .... ..1. = ECN-Capable Transport (ECT): 1
>         .... ...1 = ECN-CE: 1
>     Total Length: 20268
>     Identification: 0xa8db
>     Flags: 0x04
>         .1.. = Don't fragment: Set
>         ..0. = More fragments: Not set
>     Fragment offset: 37224
>     Time to live: 8
>     Protocol: IPv6 hop-by-hop option (0x00)
>     Header checksum: 0x9e7b (incorrect, should be 0x6a3d)
>     Source: 197.8.105.0 (197.8.105.0)
>     Destination: reserved-multicast-range-NOT-delegated.example.com
> (231.74.119.58)
>     Options: (12 bytes)
>         Unknown (0xe0) (option length = 242 bytes says option goes past end
> of options)
> Data (44 bytes)
> 
>    0  0001 0285 35d5 0001 0285 3681 8847 4500   ....5.....6..GE. 
>   10  0054 138a 0000 3f01 750f a8db 4f2c a8db   .T....?.u...O,.. 
>   20  522d 0800 9e7b c508 6900 e74a 773a e0f2   R-...{..i..Jw:.. 
>   30  0100 0809 0a0b 0c0d 0e0f 1011 1213 1415   ................ 
>   40  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425   .......... !"#$% 
>   50  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435   &'()*+,-./012345 
>   60  3637 3435 3637                            674567           
> 
> 
> Where as wnen a packet from an LER to LSR is captured at the input interface
> of LSR ( ex.  packet travelling from LER2 to LSR1, captured at LSR1-eth0 )
> the dump is consistent with expected results as shown below
> 
> Frame 2 (102 on wire, 102 captured)
> Ethernet II
> MultiProtocol Label Switching Header
> Internet Protocol
> Internet Control Message Protocol
> 
> A detailed packet analysis along with the hex dump is provided below.
> 
> 
> Frame 2 (102 on wire, 102 captured)
>     Arrival Time: Jan 30, 2001 16:14:01.3067
>     Time delta from previous packet: 0.000337 seconds
>     Time relative to first packet: 0.000337 seconds
>     Frame Number: 2
>     Packet Length: 102 bytes
>     Capture Length: 102 bytes
> Ethernet II
>     Destination: 00:01:02:85:36:81 (00:01:02:85:36:81)
>     Source: 00:01:02:85:35:d5 (00:01:02:85:35:d5)
>     Type: MPLS label switched packet (0x8847)
> MultiProtocol Label Switching Header
>     MPLS Label: Unknown (20)
>     MPLS Experimental Bits: 0
>     MPLS Bottom Of Label Stack: 1
>     MPLS TTL: 254
> Internet Protocol
>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>         0000 00.. = Differentiated Services Codepoint: Default (0x00)
>         .... ..0. = ECN-Capable Transport (ECT): 0
>         .... ...0 = ECN-CE: 0
>     Total Length: 84
>     Identification: 0x0000
>     Flags: 0x04
>         .1.. = Don't fragment: Set
>         ..0. = More fragments: Not set
>     Fragment offset: 0
>     Time to live: 254
>     Protocol: ICMP (0x01)
>     Header checksum: 0x8998 (correct)
>     Source: 168.219.82.45 (168.219.82.45)
>     Destination: 168.219.79.44 (168.219.79.44)
> Internet Control Message Protocol
>     Type: 0 (Echo (ping) reply)
>     Code: 0 
>     Checksum: 0xa67b (correct)
>     Identifier: 0xc508
>     Sequence number: 69:00
>     Data (56 bytes)
> 
>    0  0001 0285 3681 0001 0285 35d5 8847 0001   ....6.....5..G.. 
>   10  41fe 4500 0054 0000 4000 fe01 8998 a8db   A.E..T..@....... 
>   20  522d a8db 4f2c 0000 a67b c508 6900 e74a   R-..O,...{..i..J 
>   30  773a e0f2 0100 0809 0a0b 0c0d 0e0f 1011   w:.............. 
>   40  1213 1415 1617 1819 1a1b 1c1d 1e1f 2021   .............. ! 
>   50  2223 2425 2627 2829 2a2b 2c2d 2e2f 3031   "#$%&'()*+,-./01 
>   60  3233 3435 3637                            234567           
> 
> 
> 
> Could you please comment on this .
> 
> Regards
> 
> Debasis
> 
> 

-- 
James R. Leu

[mpls-linux-general] MPLS stack observed using Ethereal analyzer !!

[Nanda, D. <DN...@ne...>]

Hi James,

I have setup a small MPLS domain in our lab for testing using your
implementation of linux-mpls.

I have the following configuration

(Please use prefix 168.219. for all ip address below )

        79.44	79.2	80.1     80.2	81.1	  81.2	82.2   82.45
   --------        -------         ------           -------         --------
  | Host 1 |------| LER 1 |-------| LSR 1|---------| LER 2 |-------| Host 2
|
   --------        -------         ------           -------         --------
         eth0    eth2   eth0     eth0  eth1       eth0   eth2     eth0




I observer that when a MPLS packet gets switched ( label swaping) in a LSR ,
at the out port (interface) in either direction I get MPLS label stack . For
example when a packet traverses from Host1 to Host 2 , it's label gets
swaped at LSR 1. When I run Ethereal at LER2-eth0, I observer three MPLS
heaser on each packet directed from LSR1 to LER2 . 

Frame 1 (102 on wire, 102 captured)
Ethernet II
MultiProtocol Label Switching Header
MultiProtocol Label Switching Header
MultiProtocol Label Switching Header
Internet Protocol

A detailed packet dump is shown below along with the hex dump.




Frame 1 (102 on wire, 102 captured)
    Arrival Time: Jan 30, 2001 16:14:01.3064
    Time delta from previous packet: 0.000000 seconds
    Time relative to first packet: 0.000000 seconds
    Frame Number: 1
    Packet Length: 102 bytes
    Capture Length: 102 bytes
Ethernet II
    Destination: 00:01:02:85:35:d5 (00:01:02:85:35:d5)
    Source: 00:01:02:85:36:81 (00:01:02:85:36:81)
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
    MPLS Label: Unknown (282624)
    MPLS Experimental Bits: 0
    MPLS Bottom Of Label Stack: 0
    MPLS TTL: 84
MultiProtocol Label Switching Header
    MPLS Label: Unknown (80032)
    MPLS Experimental Bits: 0
    MPLS Bottom Of Label Stack: 0
    MPLS TTL: 0
MultiProtocol Label Switching Header
    MPLS Label: Unknown (258071)
    MPLS Experimental Bits: 2
    MPLS Bottom Of Label Stack: 1
    MPLS TTL: 15
Internet Protocol
    Version: 10
    Header length: 32 bytes
    Differentiated Services Field: 0xdb (DSCP 0x36: Unknown DSCP; ECN: 0x03)
        1101 10.. = Differentiated Services Codepoint: Unknown (0x36)
        .... ..1. = ECN-Capable Transport (ECT): 1
        .... ...1 = ECN-CE: 1
    Total Length: 20268
    Identification: 0xa8db
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 37224
    Time to live: 8
    Protocol: IPv6 hop-by-hop option (0x00)
    Header checksum: 0x9e7b (incorrect, should be 0x6a3d)
    Source: 197.8.105.0 (197.8.105.0)
    Destination: reserved-multicast-range-NOT-delegated.example.com
(231.74.119.58)
    Options: (12 bytes)
        Unknown (0xe0) (option length = 242 bytes says option goes past end
of options)
Data (44 bytes)

   0  0001 0285 35d5 0001 0285 3681 8847 4500   ....5.....6..GE. 
  10  0054 138a 0000 3f01 750f a8db 4f2c a8db   .T....?.u...O,.. 
  20  522d 0800 9e7b c508 6900 e74a 773a e0f2   R-...{..i..Jw:.. 
  30  0100 0809 0a0b 0c0d 0e0f 1011 1213 1415   ................ 
  40  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425   .......... !"#$% 
  50  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435   &'()*+,-./012345 
  60  3637 3435 3637                            674567           


Where as wnen a packet from an LER to LSR is captured at the input interface
of LSR ( ex.  packet travelling from LER2 to LSR1, captured at LSR1-eth0 )
the dump is consistent with expected results as shown below

Frame 2 (102 on wire, 102 captured)
Ethernet II
MultiProtocol Label Switching Header
Internet Protocol
Internet Control Message Protocol

A detailed packet analysis along with the hex dump is provided below.


Frame 2 (102 on wire, 102 captured)
    Arrival Time: Jan 30, 2001 16:14:01.3067
    Time delta from previous packet: 0.000337 seconds
    Time relative to first packet: 0.000337 seconds
    Frame Number: 2
    Packet Length: 102 bytes
    Capture Length: 102 bytes
Ethernet II
    Destination: 00:01:02:85:36:81 (00:01:02:85:36:81)
    Source: 00:01:02:85:35:d5 (00:01:02:85:35:d5)
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
    MPLS Label: Unknown (20)
    MPLS Experimental Bits: 0
    MPLS Bottom Of Label Stack: 1
    MPLS TTL: 254
Internet Protocol
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 84
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 254
    Protocol: ICMP (0x01)
    Header checksum: 0x8998 (correct)
    Source: 168.219.82.45 (168.219.82.45)
    Destination: 168.219.79.44 (168.219.79.44)
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 
    Checksum: 0xa67b (correct)
    Identifier: 0xc508
    Sequence number: 69:00
    Data (56 bytes)

   0  0001 0285 3681 0001 0285 35d5 8847 0001   ....6.....5..G.. 
  10  41fe 4500 0054 0000 4000 fe01 8998 a8db   A.E..T..@....... 
  20  522d a8db 4f2c 0000 a67b c508 6900 e74a   R-..O,...{..i..J 
  30  773a e0f2 0100 0809 0a0b 0c0d 0e0f 1011   w:.............. 
  40  1213 1415 1617 1819 1a1b 1c1d 1e1f 2021   .............. ! 
  50  2223 2425 2627 2829 2a2b 2c2d 2e2f 3031   "#$%&'()*+,-./01 
  60  3233 3435 3637                            234567           



Could you please comment on this .

Regards

Debasis

[mpls-linux-general] Re: RSVP-TE

[Martin K. <Mar...@KO...>]

> - http://www.kom.e-technik.tu-darmstadt.de/rsvp/, which is at least known to
> work on 2.2.x but don't seem to support RSVP-TE either.

Correct, it currently doesn't support RSVP-TE.

> None of these 2 appears to have an active mailing list where I can learn more
> about them.

The amount of questions has not exceeded the threshold to create such a
list, so far. ;-) I'm happy to answer any questions send to me directly, if
time permits.

Greetings,
Martin

Re: [mpls-linux-general] RSVP-TE

[James R. L. <jl...@mi...>]

Hello Fran=E7ois,

> - http://www.cs.columbia.edu/~yhwang/ftp/qos/rsvp/, which is for linux =
2.0.x
> - http://www.kom.e-technik.tu-darmstadt.de/rsvp/, which is at least kno=
wn to
> work on 2.2.x but don't seem to support RSVP-TE either.
>=20
> None of these 2 appears to have an active mailing list where I can lear=
n more
> about them.

I grabbed the lastest RSVP code from http://www.isi.edu/div7/rsvp/

It compiles on Linux (if you apply the linux-tc patch kit).  It still nee=
ds
TE extensions and a command line interface, but the core is there.

> You said that you've heard of somebody who was hacking a RSVP-TE extens=
ion to
> some already existing stack. Do you have any pointer ?

I do remeber hearing about someone on this list thinking about it.  I'm n=
ot
sure if anything ever came of it.  Anyone care to comment?

> Would you know anything about a CR-LDP (Nortel?) implementation somewhe=
re that
> we can incorporate to MPLS-Linux ?

You are probably refering to the Nortel CR-LDP encode and decode function=
s. =20
Their code is at the base of ldp-portable (lib/ldp_nortel.[ch]) ;-)

> Thanks a lot!

No problem.

Jim

> --=20
> Fran=E7ois Desloges
> fd...@vi...
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu

[mpls-linux-general] RSVP-TE

[Francois D. <fd...@vi...>]

Hi James !

	Hope I didn't traumatize you with my previous message. As you know, I'm
looking for RSVP-TE stacks for Linux.

I've found:
- http://www.cs.columbia.edu/~yhwang/ftp/qos/rsvp/, which is for linux 2.0.x
- http://www.kom.e-technik.tu-darmstadt.de/rsvp/, which is at least known to
work on 2.2.x but don't seem to support RSVP-TE either.

None of these 2 appears to have an active mailing list where I can learn more
about them.

You said that you've heard of somebody who was hacking a RSVP-TE extension to
some already existing stack. Do you have any pointer ?

Would you know anything about a CR-LDP (Nortel?) implementation somewhere that
we can incorporate to MPLS-Linux ?

Thanks a lot!

-- 
François Desloges
fd...@vi...

[mpls-linux-general] mpls-linux 0.800

[James R. L. <jl...@mi...>]

I have released mpls-linux-0.800.

0.800 is a bug fix release.  The hope is that many of the outstanding bugs
have been fixed.  The plan is to do only bug fixes until 1.0.  At that point
1.0 will only have patch releases.  Everything above 1.0 (ie 1.1) will
be used to add new features and re-organize the code a bit. 2.0 will be
the next stable major version after 1.0.

Please test 0.800 and let me know of any bugs/difficulties you have.
make sure to read the NOTES file about known issues.

Now that I think I have this sourceforge stuff figured out.  I hope to
be able to make quick bug fix releases.

Thanks for your patience.

Jim
-- 
James R. Leu

[mpls-linux-general] Interoperability with Cisco routers.

[<ap...@av...>]

Hi there,

     As anyone tried any interoperability scenarios between Linux boxes
(running MPLS-Linux kernel patch) and Cisco routers (running apropriate IOS
software)? Thanks in advance.

Arménio Pinto - PT Inovação SA, Portugal

Re: [mpls-linux-general] Utility compilation problem

[James R. L. <jl...@mi...>]

Did you apply the kernel patch?  If so, then most likely you are running
on a linux distribution that mucks with your include files.

What you should have:

/usr/src/linux-2.4.0/ is your kernel source with MPLS patch applied
/usr/src/linux is a symbolic link to /usr/src/linux-2.4.0/
/usr/include/linux is a symbolic link to /usr/src/linux/include/linux/
/usr/include/asm is a symbolic link to /usr/src/linux/include/asm

Once you have the correct symbolic links, then make sure to configure the
kernel with MPLS support.  THEN finally you can compile the utilities :-)

I know, it's a lot of work just to compile a utility....

Jim

On Tue, Jan 23, 2001 at 04:52:40PM -0600, Nanda, Debasis wrote:
> Hi James,
> I downloaded the latest version of mpls (mpls-linux-0.700.tar.gz ) .I am
> using Red Hat Linux 7.0 and Kernel 2.4.0 test11 .
> I patched linux kernel 2.4.0 test 11 with the patch file provided and
> compiled it . It compiled fine and I am able to boot with the mpls enabled
> kernel .
> But while compiling the user space application , the utilities, with the new
> kernel , I get a compilation error
> 
> cc -g -Wall   -c -o netlink.o netlink.c
> netlink.c:9:24: linux/mpls.h: No such file or directory
> make: *** [netlink.o] Error 1
> 
> Then I put a copy of "mpls.h" in the local directory and changed the
> inclusions accordingly in netlink.c and mplsadm.c .
> 
> The compiler shouted with the following errors ..
> 
> cc -g -Wall   -c -o mplsadm.o mplsadm.c
> mplsadm.c: In function `main':
> mplsadm.c:355: `RTM_DELILM' undeclared (first use in this function)
> mplsadm.c:355: (Each undeclared identifier is reported only once
> mplsadm.c:355: for each function it appears in.)
> mplsadm.c:358: `RTM_NEWILM' undeclared (first use in this function)
> mplsadm.c:374: `RTM_DELNHLFE' undeclared (first use in this function)
> mplsadm.c:381: `RTM_NEWNHLFE' undeclared (first use in this function)
> mplsadm.c:415: `RTM_NEWFTN' undeclared (first use in this function)
> mplsadm.c:418: `RTM_DELFTN' undeclared (first use in this function)
> mplsadm.c:432: `RTM_SETININSTR' undeclared (first use in this function)
> mplsadm.c:447: `RTM_SETOUTINSTR' undeclared (first use in this function)
> mplsadm.c:483: `RTM_NEWXC' undeclared (first use in this function)
> mplsadm.c:486: `RTM_DELXC' undeclared (first use in this function)
> make: *** [mplsadm.o] Error 1
> 
> 
> 
> Please help.
> 
> Regards
> Debasis
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> http://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu