mpls-linux-general Mailing List for MPLS for Linux (Page 176)
Status: Beta
Brought to you by:
jleu
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(26) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(22) |
Feb
(19) |
Mar
(19) |
Apr
(45) |
May
(52) |
Jun
(101) |
Jul
(79) |
Aug
(24) |
Sep
(43) |
Oct
(54) |
Nov
(71) |
Dec
(53) |
2002 |
Jan
(111) |
Feb
(123) |
Mar
(67) |
Apr
(61) |
May
(75) |
Jun
(26) |
Jul
(36) |
Aug
(41) |
Sep
(79) |
Oct
(85) |
Nov
(58) |
Dec
(39) |
2003 |
Jan
(26) |
Feb
(61) |
Mar
(80) |
Apr
(56) |
May
(39) |
Jun
(44) |
Jul
(28) |
Aug
(25) |
Sep
(4) |
Oct
(20) |
Nov
(38) |
Dec
(9) |
2004 |
Jan
(14) |
Feb
(14) |
Mar
(68) |
Apr
(17) |
May
(45) |
Jun
(42) |
Jul
(41) |
Aug
(23) |
Sep
(46) |
Oct
(89) |
Nov
(55) |
Dec
(33) |
2005 |
Jan
(74) |
Feb
(39) |
Mar
(105) |
Apr
(96) |
May
(43) |
Jun
(48) |
Jul
(21) |
Aug
(22) |
Sep
(33) |
Oct
(28) |
Nov
(29) |
Dec
(81) |
2006 |
Jan
(37) |
Feb
(32) |
Mar
(147) |
Apr
(37) |
May
(33) |
Jun
(28) |
Jul
(15) |
Aug
(20) |
Sep
(15) |
Oct
(23) |
Nov
(30) |
Dec
(40) |
2007 |
Jan
(20) |
Feb
(24) |
Mar
(65) |
Apr
(69) |
May
(41) |
Jun
(53) |
Jul
(39) |
Aug
(76) |
Sep
(53) |
Oct
(43) |
Nov
(26) |
Dec
(24) |
2008 |
Jan
(19) |
Feb
(67) |
Mar
(91) |
Apr
(75) |
May
(47) |
Jun
(63) |
Jul
(68) |
Aug
(39) |
Sep
(44) |
Oct
(33) |
Nov
(62) |
Dec
(84) |
2009 |
Jan
(14) |
Feb
(39) |
Mar
(55) |
Apr
(63) |
May
(16) |
Jun
(9) |
Jul
(4) |
Aug
(6) |
Sep
(1) |
Oct
(2) |
Nov
(10) |
Dec
(5) |
2010 |
Jan
(3) |
Feb
(1) |
Mar
(5) |
Apr
(13) |
May
(4) |
Jun
(5) |
Jul
(2) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
(2) |
Dec
(2) |
2011 |
Jan
(1) |
Feb
(21) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
(2) |
Dec
(6) |
2012 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(3) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Yon U. <uk...@rz...> - 2001-02-20 16:18:47
|
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 |
From: <ap...@av...> - 2001-02-20 14:51:59
|
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 |
From: S. <j....@gm...> - 2001-02-20 11:57:24
|
"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 |
From: James R. L. <jl...@mi...> - 2001-02-16 14:52:46
|
> > 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 |
From: Yon U. <uk...@rz...> - 2001-02-16 14:34:35
|
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 |
From: James R. L. <jl...@mi...> - 2001-02-16 14:03:34
|
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 |
From: S. <j....@gm...> - 2001-02-16 09:17:07
|
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 |
From: Steven V. d. B. <ste...@in...> - 2001-02-16 08:25:48
|
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 |
From: Jonathan E. <je...@no...> - 2001-02-15 19:42:43
|
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. |
From: James R. L. <jl...@mi...> - 2001-02-12 21:51:05
|
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 |
From: James T. <eu...@ca...> - 2001-02-08 21:27:04
|
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/ |
From: Francois D. <fd...@vi...> - 2001-02-02 18:50:02
|
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... |
From: James R. L. <jl...@mi...> - 2001-02-01 23:12:48
|
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 |
From: James R. L. <jl...@mi...> - 2001-02-01 15:21:37
|
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 |
From: James R. L. <jl...@mi...> - 2001-02-01 15:05:48
|
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 |
From: James R. L. <jl...@mi...> - 2001-01-31 15:06:52
|
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 |
From: Francois D. <fd...@vi...> - 2001-01-31 01:00:43
|
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 |
From: James R. L. <jl...@mi...> - 2001-01-30 23:48:55
|
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 |
From: Nanda, D. <DN...@ne...> - 2001-01-30 23:41:22
|
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 |
From: Martin K. <Mar...@KO...> - 2001-01-28 23:01:32
|
> - 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 |
From: James R. L. <jl...@mi...> - 2001-01-26 23:32:14
|
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 |
From: Francois D. <fd...@vi...> - 2001-01-26 23:19:21
|
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... |
From: James R. L. <jl...@mi...> - 2001-01-24 19:45:46
|
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 |
From: <ap...@av...> - 2001-01-24 16:01:27
|
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 |
From: James R. L. <jl...@mi...> - 2001-01-24 00:43:36
|
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 |