Thread: [mpls-linux-devel] mpls-linux on 64 bit kernel
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel
|
From: Ahsan T. <ahs...@gm...> - 2010-05-17 16:01:43
|
Hi, I just wanted to ask that if anybody has successfully tested MPLS label switching on a 64 bit architecture, specifically x86_64 ? Thanks Ahsan |
|
From: Chris R. <Chr...@nr...> - 2010-05-17 22:16:03
|
Ashan
I'm currently trying to test this but having lock up problems. However,
I have cornered the problem to the following code snip. Note the
conditional compile statement. This maybe the cause of the x86_64
system locking up, but (and a big but) it also locks up with my x86_32
systems as well. Will be collecting more data tomorrow but if anyone
has any ideas I'm all ears. FYI, the lock up occurs when
mpls_opcode_peek is called from mpls_skb_recv().
int mpls_opcode_peek(struct sk_buff *skb)
{
u32 shim;
#define CAN_WE_ASSUME_32BIT_ALIGNED 0
#if CAN_WE_ASSUME_32BIT_ALIGNED
shim = ntohl(*((u32*)&skb->network_header));
#else
memcpy(&shim,skb->network_header,sizeof(u32));
shim = ntohl(shim);
#endif
if (!(MPLSCB(skb)->flag)) {
MPLSCB(skb)->ttl = shim & 0xFF;
MPLSCB(skb)->flag = 1;
}
MPLSCB(skb)->bos = (shim >> 8 ) & 0x1;
MPLSCB(skb)->exp = (shim >> 9 ) & 0x7;
MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF;
return MPLS_RESULT_RECURSE;
}
On 05/17/2010 12:01 PM, Ahsan Tariq wrote:
> Hi,
>
> I just wanted to ask that if anybody has successfully tested MPLS
> label switching on a 64 bit architecture, specifically x86_64 ?
>
> Thanks
>
> Ahsan
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
>
|
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 09:09:48
|
El 18/05/2010 0:15, Chris Robson escribió:
>
> Ashan
>
> I'm currently trying to test this but having lock up problems. However,
> I have cornered the problem to the following code snip. Note the
> conditional compile statement. This maybe the cause of the x86_64
> system locking up, but (and a big but) it also locks up with my x86_32
> systems as well. Will be collecting more data tomorrow but if anyone
> has any ideas I'm all ears. FYI, the lock up occurs when
> mpls_opcode_peek is called from mpls_skb_recv().
>
> int mpls_opcode_peek(struct sk_buff *skb)
> {
> u32 shim;
>
> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
> #if CAN_WE_ASSUME_32BIT_ALIGNED
> shim = ntohl(*((u32*)&skb->network_header));
> #else
> memcpy(&shim,skb->network_header,sizeof(u32));
> shim = ntohl(shim);
> #endif
>
> if (!(MPLSCB(skb)->flag)) {
> MPLSCB(skb)->ttl = shim & 0xFF;
> MPLSCB(skb)->flag = 1;
> }
> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1;
> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7;
> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF;
>
> return MPLS_RESULT_RECURSE;
> }
Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32,
some of the members of the skbuff are not pointers (network_header,
transport_header, ...) but offsets.
I'll cook a patch and send it to you to test.
Regards,
Jorge
--
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.
==============================================================
|
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 10:01:04
Attachments:
mpls-linux-64bits.patch
|
El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió:
> El 18/05/2010 0:15, Chris Robson escribió:
>>
>> Ashan
>>
>> I'm currently trying to test this but having lock up problems. However,
>> I have cornered the problem to the following code snip. Note the
>> conditional compile statement. This maybe the cause of the x86_64
>> system locking up, but (and a big but) it also locks up with my x86_32
>> systems as well. Will be collecting more data tomorrow but if anyone
>> has any ideas I'm all ears. FYI, the lock up occurs when
>> mpls_opcode_peek is called from mpls_skb_recv().
>>
>> int mpls_opcode_peek(struct sk_buff *skb)
>> {
>> u32 shim;
>>
>> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
>> #if CAN_WE_ASSUME_32BIT_ALIGNED
>> shim = ntohl(*((u32*)&skb->network_header));
>> #else
>> memcpy(&shim,skb->network_header,sizeof(u32));
>> shim = ntohl(shim);
>> #endif
>>
>> if (!(MPLSCB(skb)->flag)) {
>> MPLSCB(skb)->ttl = shim & 0xFF;
>> MPLSCB(skb)->flag = 1;
>> }
>> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1;
>> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7;
>> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF;
>>
>> return MPLS_RESULT_RECURSE;
>> }
>
> Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32,
> some of the members of the skbuff are not pointers (network_header,
> transport_header, ...) but offsets.
>
> I'll cook a patch and send it to you to test.
>
Try this. Maybe it does not apply to your tree because it is against the
codebase i am cleaning off but it should be simple to resolve.
--
==============================================================
Jorge Boncompte - Ingenieria y Gestion de RED
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be made.
==============================================================
|
|
From: Chris R. <Chr...@nr...> - 2010-05-18 14:49:14
|
Hi Jorge
Good and bad news.
Good news is the lock up is fixed. I can see, via wireshark and debug,
ping packets being received without the system locking.
Bad news is, the reply is not going out. Although, I'm not sure the
back-to-back host configuration is correct so that maybe the reason.
ergo here is what is configured:
Host A: eth1 - 10.50.1.1/24
eth0:1 - 10.50.210.1/24
/sbin/mpls labelspace set dev eth1 labelspace 0
LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26`
/sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey
/sbin/mpls ilm add label gen 2000 labelspace 0
Host B: eth1 - 10.50.1.2/24
eth0:1 - 10.50.110.1/24
/sbin/mpls labelspace set dev eth1 labelspace 0
LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26`
/sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey
/sbin/mpls ilm add label gen 1000 labelspace 0
+++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++
Host A configuration info:
eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:512 errors:0 dropped:0 overruns:0 frame:0
TX packets:666 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB)
Memory:fa200000-fa220000
eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fa200000-fa220000
eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB)
# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts)
# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
# ip route show
10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++
Host B configuration dump:
eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:947 errors:0 dropped:0 overruns:0 frame:0
TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB)
Memory:fa200000-fa220000
eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fa200000-fa220000
eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB)
# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts)
[root@FARP ~]# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
...................Chris
On 05/18/2010 06:00 AM, Jorge Boncompte [DTI2] wrote:
> El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió:
>
>> El 18/05/2010 0:15, Chris Robson escribió:
>>
>>> Ashan
>>>
>>> I'm currently trying to test this but having lock up problems. However,
>>> I have cornered the problem to the following code snip. Note the
>>> conditional compile statement. This maybe the cause of the x86_64
>>> system locking up, but (and a big but) it also locks up with my x86_32
>>> systems as well. Will be collecting more data tomorrow but if anyone
>>> has any ideas I'm all ears. FYI, the lock up occurs when
>>> mpls_opcode_peek is called from mpls_skb_recv().
>>>
>>> int mpls_opcode_peek(struct sk_buff *skb)
>>> {
>>> u32 shim;
>>>
>>> #define CAN_WE_ASSUME_32BIT_ALIGNED 0
>>> #if CAN_WE_ASSUME_32BIT_ALIGNED
>>> shim = ntohl(*((u32*)&skb->network_header));
>>> #else
>>> memcpy(&shim,skb->network_header,sizeof(u32));
>>> shim = ntohl(shim);
>>> #endif
>>>
>>> if (!(MPLSCB(skb)->flag)) {
>>> MPLSCB(skb)->ttl = shim& 0xFF;
>>> MPLSCB(skb)->flag = 1;
>>> }
>>> MPLSCB(skb)->bos = (shim>> 8 )& 0x1;
>>> MPLSCB(skb)->exp = (shim>> 9 )& 0x7;
>>> MPLSCB(skb)->label = (shim>> 12)& 0xFFFFF;
>>>
>>> return MPLS_RESULT_RECURSE;
>>> }
>>>
>> Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG> 32,
>> some of the members of the skbuff are not pointers (network_header,
>> transport_header, ...) but offsets.
>>
>> I'll cook a patch and send it to you to test.
>>
>>
> Try this. Maybe it does not apply to your tree because it is against the
> codebase i am cleaning off but it should be simple to resolve.
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
>
|
|
From: <jl...@mi...> - 2010-05-18 15:18:25
|
Good stuff. I will apply to the main tree. You can see the latest code at: git://repo.or.cz/mpls-linux.git That tree contains a kernel patch for core changes (shim and exports) and then a src dir for compiling mpls modules outside the kernel. I've found this to be a much quicker development/testing cycle. On Tue, May 18, 2010 at 12:00:50PM +0200, Jorge Boncompte [DTI2] wrote: > El 18/05/2010 11:09, Jorge Boncompte [DTI2] escribió: > > El 18/05/2010 0:15, Chris Robson escribió: > >> > >> Ashan > >> > >> I'm currently trying to test this but having lock up problems. However, > >> I have cornered the problem to the following code snip. Note the > >> conditional compile statement. This maybe the cause of the x86_64 > >> system locking up, but (and a big but) it also locks up with my x86_32 > >> systems as well. Will be collecting more data tomorrow but if anyone > >> has any ideas I'm all ears. FYI, the lock up occurs when > >> mpls_opcode_peek is called from mpls_skb_recv(). > >> > >> int mpls_opcode_peek(struct sk_buff *skb) > >> { > >> u32 shim; > >> > >> #define CAN_WE_ASSUME_32BIT_ALIGNED 0 > >> #if CAN_WE_ASSUME_32BIT_ALIGNED > >> shim = ntohl(*((u32*)&skb->network_header)); > >> #else > >> memcpy(&shim,skb->network_header,sizeof(u32)); > >> shim = ntohl(shim); > >> #endif > >> > >> if (!(MPLSCB(skb)->flag)) { > >> MPLSCB(skb)->ttl = shim & 0xFF; > >> MPLSCB(skb)->flag = 1; > >> } > >> MPLSCB(skb)->bos = (shim >> 8 ) & 0x1; > >> MPLSCB(skb)->exp = (shim >> 9 ) & 0x7; > >> MPLSCB(skb)->label = (shim >> 12) & 0xFFFFF; > >> > >> return MPLS_RESULT_RECURSE; > >> } > > > > Ok, that rang a bell. The problem is that in arches with BITS_PER_LONG > 32, > > some of the members of the skbuff are not pointers (network_header, > > transport_header, ...) but offsets. > > > > I'll cook a patch and send it to you to test. > > > > Try this. Maybe it does not apply to your tree because it is against the > codebase i am cleaning off but it should be simple to resolve. > > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > diff --git a/net/bridge/netfilter/ebt_mpls.c b/net/bridge/netfilter/ebt_mpls.c > index 109cf16..541c4be 100644 > --- a/net/bridge/netfilter/ebt_mpls.c > +++ b/net/bridge/netfilter/ebt_mpls.c > @@ -30,8 +30,8 @@ static int target(struct sk_buff *skb, unsigned int hooknr, > * set skb->network_header = skb->data, skb->network_header > * is where we put the MPLS shim > */ > - skb_push(skb, skb->data - skb->mac_header); > - skb->network_header = skb->data; > + skb_push(skb, skb->data - skb_mac_header(skb)); > + skb_reset_network_header(skb); > mpls_output_shim(skb, nhlfe); > > /* don't let anyone else use this frame */ > diff --git a/net/ipv4/mpls4.c b/net/ipv4/mpls4.c > index bff2c70..5e9c6a8 100644 > --- a/net/ipv4/mpls4.c > +++ b/net/ipv4/mpls4.c > @@ -104,7 +104,7 @@ static struct sk_buff *mpls4_build_icmp(struct sk_buff *skb, int type, > /* now where at the payload, for now we're > * assuming this is IPv4 > */ > - skb->network_header = skb->data; > + skb_reset_network_header(skb); > > /* buid a new skb, that will be big enough to hold > * a maximum of 576 bytes (RFC792) > diff --git a/net/mpls/mpls_opcode.c b/net/mpls/mpls_opcode.c > index a5e663f..369e458 100644 > --- a/net/mpls/mpls_opcode.c > +++ b/net/mpls/mpls_opcode.c > @@ -78,9 +78,9 @@ int mpls_opcode_peek(struct sk_buff *skb) > > #define CAN_WE_ASSUME_32BIT_ALIGNED 0 > #if CAN_WE_ASSUME_32BIT_ALIGNED > - shim = ntohl(*((u32 *)&skb->network_header)); > + shim = ntohl(*((u32 *)&skb_network_header(skb))); > #else > - memcpy(&shim, skb->network_header, sizeof(u32)); > + memcpy(&shim, skb_network_header(skb), sizeof(u32)); > shim = ntohl(shim); > #endif > > diff --git a/net/mpls/mpls_utils.c b/net/mpls/mpls_utils.c > index 9204d1d..f5d58be 100644 > --- a/net/mpls/mpls_utils.c > +++ b/net/mpls/mpls_utils.c > @@ -142,7 +142,7 @@ EXPORT_SYMBOL(mpls_label2key); > * @skb - the packet to work on > * > * assumes valid data in MPLSCB(skb)->popped_bos and that > - * that skb->network_header is pointing to a label in the MPLS shim > + * that skb_network_header(skb) is pointing to a label in the MPLS shim > * returns a unsigned char* which point to the first byte after the MPLS > * shim. > * > @@ -194,7 +194,7 @@ EXPORT_SYMBOL(mpls_find_payload); > > void mpls_skb_dump(struct sk_buff *sk) > { > - unsigned int i; > + unsigned long i; > > printk(KERN_DEBUG "MPLS mpls_skb_dump: from %s with len %d (%d)" > "headroom=%d tailroom=%d\n", > @@ -204,17 +204,17 @@ void mpls_skb_dump(struct sk_buff *sk) > skb_headroom(sk), > skb_tailroom(sk)); > > - for (i = (unsigned int)sk->head; i <= (unsigned int)sk->tail; i++) { > - if (i == (unsigned int)sk->data) > + for (i = (unsigned long)sk->head; i <= (unsigned long)sk->tail; i++) { > + if (i == (unsigned long)sk->data) > printk("{"); > - if (i == (unsigned int)sk->transport_header) > + if (i == (unsigned long)skb_transport_header(sk)) > printk("#"); > - if (i == (unsigned int)sk->network_header) > + if (i == (unsigned long)skb_network_header(sk)) > printk("|"); > - if (i == (unsigned int)sk->mac_header) > + if (i == (unsigned long)skb_mac_header(sk)) > printk("*"); > printk("%02x", *((unsigned char *)i)); > - if (i == (unsigned int)sk->tail) > + if (i == (unsigned long)sk->tail) > printk("}"); > } > printk("\n"); > ------------------------------------------------------------------------------ > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel -- James R. Leu jl...@mi... |
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 15:04:06
|
El 18/05/2010 16:48, Chris Robson escribió: > > Hi Jorge > > Good and bad news. > > Good news is the lock up is fixed. I can see, via wireshark and debug, > ping packets being received without the system locking. > > Bad news is, the reply is not going out. Although, I'm not sure the > back-to-back host configuration is correct so that maybe the reason. > ergo here is what is configured: > > > Host A: eth1 - 10.50.1.1/24 > eth0:1 - 10.50.210.1/24 > /sbin/mpls labelspace set dev eth1 labelspace 0 > LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen > 1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26` > /sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey > /sbin/mpls ilm add label gen 2000 labelspace 0 > > Host B: eth1 - 10.50.1.2/24 > eth0:1 - 10.50.110.1/24 > /sbin/mpls labelspace set dev eth1 labelspace 0 > LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen > 2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26` > /sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey > /sbin/mpls ilm add label gen 1000 labelspace 0 > > +++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++ > Host A configuration info: > > eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0 > inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:512 errors:0 dropped:0 overruns:0 frame:0 > TX packets:666 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB) > Memory:fa200000-fa220000 > > eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fa200000-fa220000 > > eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E > inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0 > inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:19 errors:0 dropped:0 overruns:0 frame:0 > TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB) > > # mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts) > # mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) > # ip route show > 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2 This is wrong... shouldn't it be 10.50.1.2? > > ++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++++++++++++++++++++++++++++++++ > > Host B configuration dump: > > eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:947 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB) > Memory:fa200000-fa220000 > > eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4 > inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fa200000-fa220000 > > eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E > inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:20 errors:0 dropped:0 overruns:0 frame:0 > TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB) > > # mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts) > [root@FARP ~]# mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) Have you copy&pasted the configuration because it looks the same. -- ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== |
|
From: Chris R. <Chr...@nr...> - 2010-05-18 15:29:16
|
Jorge
Oops.... cut&pasted wrong show statement it should have been:
# ip route show
10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2
Also here is a debug dump, doesnt seem to show anything related......
kernel: MPLS mpls_skb_dump: from eth1 with len 88 (1832)headroom=48
tailroom=1464
Further, the ping from Host B is "ping -I 10.50.110.1 10.50.210.1"
Note also, with "ping 10.50.210.1" from Host B the results are the same
- no reply. Iptables is turned off so it isn't filters. Its like the
packet labels are getting popped and then the packet is dropped? More
hunting to do yet......
HERE is a wireshark dump from Host A of the receiving packet from Host
B's ping
No. Time Source Destination Protocol
Info
46 486.578136 10.50.110.1 10.50.210.1
ICMP Echo (ping) request
Frame 46 (102 bytes on wire, 102 bytes captured)
Ethernet II, Src: MagicCon_00:47:5e (00:05:1b:00:47:5e), Dst:
MagicCon_70:e9:37 (00:05:1b:70:e9:37)
MultiProtocol Label Switching Header, Label: 2000, Exp: 0, S: 1, TTL: 64
MPLS Label: 2000
MPLS Experimental Bits: 0
MPLS Bottom Of Label Stack: 1
MPLS TTL: 64
Internet Protocol, Src: 10.50.110.1 (10.50.110.1), Dst: 10.50.210.1
(10.50.210.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x05d9 [correct]
Identifier: 0xa516
Sequence number: 12 (0x000c)
Data (56 bytes)
0000 a7 b0 f2 4b 00 00 00 00 ee 34 06 00 00 00 00 00 ...K.....4......
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37
...Chris
On 05/18/2010 11:03 AM, Jorge Boncompte [DTI2] wrote:
> El 18/05/2010 16:48, Chris Robson escribió:
>
>> Hi Jorge
>>
>> Good and bad news.
>>
>> Good news is the lock up is fixed. I can see, via wireshark and debug,
>> ping packets being received without the system locking.
>>
>> Bad news is, the reply is not going out. Although, I'm not sure the
>> back-to-back host configuration is correct so that maybe the reason.
>> ergo here is what is configured:
>>
>>
>> Host A: eth1 - 10.50.1.1/24
>> eth0:1 - 10.50.210.1/24
>> /sbin/mpls labelspace set dev eth1 labelspace 0
>> LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
>> 1000 nexthop eth1 ipv4 10.50.1.2 | grep key | cut -c 17-26`
>> /sbin/ip route add 10.50.110.0/24 via 10.50.1.2 mpls $LSPKey
>> /sbin/mpls ilm add label gen 2000 labelspace 0
>>
>> Host B: eth1 - 10.50.1.2/24
>> eth0:1 - 10.50.110.1/24
>> /sbin/mpls labelspace set dev eth1 labelspace 0
>> LSPKey=`/sbin/mpls nhlfe add key 0 instructions push gen
>> 2000 nexthop eth1 ipv4 10.50.1.1 | grep key | cut -c 17-26`
>> /sbin/ip route add 10.50.210.0/24 via 10.50.1.1 mpls $LSPKey
>> /sbin/mpls ilm add label gen 1000 labelspace 0
>>
>> +++++++++++++++++++++++++++++++++++++++++++
>> +++++++++++++++++++++++++++++++++++++++++++
>> Host A configuration info:
>>
>> eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
>> inet6 addr: fe80::221:86ff:fe52:8de4/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:512 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:666 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:70643 (68.9 KiB) TX bytes:84260 (82.2 KiB)
>> Memory:fa200000-fa220000
>>
>> eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Memory:fa200000-fa220000
>>
>> eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
>> inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
>> inet6 addr: fe80::205:1bff:fe00:475e/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:19 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3469 (3.3 KiB) TX bytes:5209 (5.0 KiB)
>>
>> # mpls nhlfe show
>> NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
>> push gen 2000 set eth1 ipv4 10.50.1.1 (0 bytes, 0 pkts)
>> # mpls ilm show
>> ILM entry label gen 1000 labelspace 0 proto ipv4
>> pop peek (0 bytes, 0 pkts)
>> # ip route show
>> 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
>>
> This is wrong... shouldn't it be 10.50.1.2?
>
>
>> ++++++++++++++++++++++++++++++++++++++++++++
>> ++++++++++++++++++++++++++++++++++++++++++++
>>
>> Host B configuration dump:
>>
>> eth0 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.128.112.6 Bcast:10.128.112.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:947 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:1293 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:141125 (137.8 KiB) TX bytes:156121 (152.4 KiB)
>> Memory:fa200000-fa220000
>>
>> eth0:1 Link encap:Ethernet HWaddr 00:21:86:52:8D:E4
>> inet addr:10.50.110.1 Bcast:10.50.110.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Memory:fa200000-fa220000
>>
>> eth1 Link encap:Ethernet HWaddr 00:05:1B:00:47:5E
>> inet addr:10.50.1.2 Bcast:10.50.1.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3551 (3.4 KiB) TX bytes:5209 (5.0 KiB)
>>
>> # mpls nhlfe show
>> NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
>> push gen 2000 set eth1 ipv4 10.50.1.1 (1260 bytes, 15 pkts)
>> [root@FARP ~]# mpls ilm show
>> ILM entry label gen 1000 labelspace 0 proto ipv4
>> pop peek (0 bytes, 0 pkts)
>>
> Have you copy&pasted the configuration because it looks the same.
>
>
|
|
From: Chris R. <Chr...@nr...> - 2010-05-18 15:39:48
|
Jorge
A resending of the show commands used also retested just to make sure
this configuration fails, results still fail:
HOST A..................
[root@FEON ~]# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 1000 set eth1 ipv4 10.50.1.2 (0 bytes, 0 pkts)
[root@FEON ~]# mpls ilm show
ILM entry label gen 2000 labelspace 0 proto ipv4
pop peek (3784 bytes, 43 pkts)
[root@FEON ~]# mpls labelspace show
LABELSPACE entry dev lo labelspace -1
LABELSPACE entry dev mpls0 labelspace -1
LABELSPACE entry dev eth0 labelspace -1
LABELSPACE entry dev eth1 labelspace 0
LABELSPACE entry dev wlan0 labelspace -1
LABELSPACE entry dev pan0 labelspace -1
LABELSPACE entry dev virbr0 labelspace -1
LABELSPACE entry dev tun1 labelspace -1
LABELSPACE entry dev tun2 labelspace -1
[root@FEON ~]# mpls xc show
[root@FEON ~]# ip route show
10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2
HOST B......................
[root@FARP ~]# mpls nhlfe show
NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
push gen 2000 set eth1 ipv4 10.50.1.1 (3612 bytes, 43 pkts)
[root@FARP ~]# mpls ilm show
ILM entry label gen 1000 labelspace 0 proto ipv4
pop peek (0 bytes, 0 pkts)
[root@FARP ~]# mpls xc show
[root@FARP ~]# mpls labelspace show
LABELSPACE entry dev lo labelspace -1
LABELSPACE entry dev mpls0 labelspace -1
LABELSPACE entry dev eth0 labelspace -1
LABELSPACE entry dev wlan0 labelspace -1
LABELSPACE entry dev eth1 labelspace 0
LABELSPACE entry dev pan0 labelspace -1
LABELSPACE entry dev virbr0 labelspace -1
LABELSPACE entry dev tun1 labelspace -1
[root@FARP ~]# ip route show
10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2
.................Chris
> Have you copy&pasted the configuration because it looks the same.
>
>
|
|
From: Ahsan T. <ahs...@gm...> - 2010-05-18 15:50:27
|
Hi, I have also tested the new patch and there are no lock up problems but the ip packet gets dropped after the label is popped The debug trace is below : [ 19.721739] MPLS: version 1.963 [ 19.759418] MPLS: protocol driver interface - <jl...@mi...> [ 19.835020] MPLS: IPv4 over MPLS support [ 20.406281] MPLS: IPv6 over MPLS support [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=48 tailroom=56 [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: exit(DROP) I am also testing by sending a ping. Ahsan On Tue, May 18, 2010 at 5:39 PM, Chris Robson <Chr...@nr...>wrote: > > Jorge > > A resending of the show commands used also retested just to make sure > this configuration fails, results still fail: > > HOST A.................. > > [root@FEON ~]# mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 1000 set eth1 ipv4 10.50.1.2 (0 bytes, 0 pkts) > > [root@FEON ~]# mpls ilm show > ILM entry label gen 2000 labelspace 0 proto ipv4 > pop peek (3784 bytes, 43 pkts) > > [root@FEON ~]# mpls labelspace show > LABELSPACE entry dev lo labelspace -1 > LABELSPACE entry dev mpls0 labelspace -1 > LABELSPACE entry dev eth0 labelspace -1 > LABELSPACE entry dev eth1 labelspace 0 > LABELSPACE entry dev wlan0 labelspace -1 > LABELSPACE entry dev pan0 labelspace -1 > LABELSPACE entry dev virbr0 labelspace -1 > LABELSPACE entry dev tun1 labelspace -1 > LABELSPACE entry dev tun2 labelspace -1 > > [root@FEON ~]# mpls xc show > > [root@FEON ~]# ip route show > 10.50.110.0/24 via 10.50.1.2 dev eth1 mpls 0x2 > > > HOST B...................... > > [root@FARP ~]# mpls nhlfe show > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > push gen 2000 set eth1 ipv4 10.50.1.1 (3612 bytes, 43 pkts) > > [root@FARP ~]# mpls ilm show > ILM entry label gen 1000 labelspace 0 proto ipv4 > pop peek (0 bytes, 0 pkts) > > [root@FARP ~]# mpls xc show > > [root@FARP ~]# mpls labelspace show > LABELSPACE entry dev lo labelspace -1 > LABELSPACE entry dev mpls0 labelspace -1 > LABELSPACE entry dev eth0 labelspace -1 > LABELSPACE entry dev wlan0 labelspace -1 > LABELSPACE entry dev eth1 labelspace 0 > LABELSPACE entry dev pan0 labelspace -1 > LABELSPACE entry dev virbr0 labelspace -1 > LABELSPACE entry dev tun1 labelspace -1 > > [root@FARP ~]# ip route show > 10.50.210.0/24 via 10.50.1.1 dev eth1 mpls 0x2 > > > .................Chris > > > > Have you copy&pasted the configuration because it looks the same. > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Jorge B. [DTI2] <jo...@dt...> - 2010-05-18 16:31:18
Attachments:
mpls-linux-64bits-2.patch
|
El 18/05/2010 17:50, Ahsan Tariq escribió: > Hi, > > I have also tested the new patch and there are no lock up problems but > the ip packet gets dropped after the label is popped > The debug trace is below : > > [ 19.721739] MPLS: version 1.963 > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... > <mailto:jl...@mi...>> > [ 19.835020] MPLS: IPv4 over MPLS support > [ 20.406281] MPLS: IPv6 over MPLS support > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > (424)headroom=48 tailroom=56 > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > exit(DROP) > Ok, with this patch in top of the other I think it should work. -- ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== |
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 08:22:51
|
Hi, Thanks, its working now. Ahsan On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote: > El 18/05/2010 17:50, Ahsan Tariq escribió: > > Hi, > > > > I have also tested the new patch and there are no lock up problems but > > the ip packet gets dropped after the label is popped > > The debug trace is below : > > > > [ 19.721739] MPLS: version 1.963 > > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... > > <mailto:jl...@mi...>> > > [ 19.835020] MPLS: IPv4 over MPLS support > > [ 20.406281] MPLS: IPv6 over MPLS support > > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter > > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > > (424)headroom=48 tailroom=56 > > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP > > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped > > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > > exit(DROP) > > > > Ok, with this patch in top of the other I think it should work. > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > |
|
From: Chris R. <Chr...@nr...> - 2010-05-19 10:35:38
|
Jorge, Ashan Was another patch sent out to fix the dropped packet problem? If so what? thanks Chris On 05/19/2010 04:22 AM, Ahsan Tariq wrote: > Hi, > > > Thanks, its working now. > > Ahsan > > On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] > <jo...@dt... <mailto:jo...@dt...>> wrote: > > El 18/05/2010 17:50, Ahsan Tariq escribió: > > Hi, > > > > I have also tested the new patch and there are no lock up > problems but > > the ip packet gets dropped after the label is popped > > The debug trace is below : > > > > [ 19.721739] MPLS: version 1.963 > > [ 19.759418] MPLS: protocol driver interface - > <jl...@mi... <mailto:jl...@mi...> > > <mailto:jl...@mi... <mailto:jl...@mi...>>> > > [ 19.835020] MPLS: IPv4 over MPLS support > > [ 20.406281] MPLS: IPv6 over MPLS support > > [ 494.929061] MPLS DEBUG > net/mpls/mpls_input.c:229:mpls_skb_recv: enter > > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 > > (424)headroom=48 tailroom=56 > > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter > > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: > > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 > > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: > opcode POP > > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: > dropped > > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: > > exit(DROP) > > > > Ok, with this patch in top of the other I think it should work. > > -- > ============================================================== > Jorge Boncompte - Ingenieria y Gestion de RED > DTI2 - Desarrollo de la Tecnologia de las Comunicaciones > -------------------------------------------------------------- > C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) > Tlf: +34 957 761395 / FAX: +34 957 450380 > ============================================================== > - Sin pistachos no hay Rock & Roll... > - Without wicker a basket cannot be made. > ============================================================== > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > <mailto:mpl...@li...> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Chris R. <Chr...@nr...> - 2010-05-19 10:46:16
|
Never mind, darn junk mail filter broke again! On 05/19/2010 06:35 AM, Chris Robson wrote: > > Jorge, Ashan > > Was another patch sent out to fix the dropped packet problem? If so what? > > thanks > Chris > > On 05/19/2010 04:22 AM, Ahsan Tariq wrote: >> Hi, >> >> >> Thanks, its working now. >> >> Ahsan >> >> On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] >> <jo...@dt... <mailto:jo...@dt...>> wrote: >> >> El 18/05/2010 17:50, Ahsan Tariq escribió: >> > Hi, >> > >> > I have also tested the new patch and there are no lock up >> problems but >> > the ip packet gets dropped after the label is popped >> > The debug trace is below : >> > >> > [ 19.721739] MPLS: version 1.963 >> > [ 19.759418] MPLS: protocol driver interface - >> <jl...@mi... <mailto:jl...@mi...> >> > <mailto:jl...@mi... <mailto:jl...@mi...>>> >> > [ 19.835020] MPLS: IPv4 over MPLS support >> > [ 20.406281] MPLS: IPv6 over MPLS support >> > [ 494.929061] MPLS DEBUG >> net/mpls/mpls_input.c:229:mpls_skb_recv: enter >> > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 >> > (424)headroom=48 tailroom=56 >> > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: >> enter >> > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: >> > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 >> > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: >> opcode POP >> > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: >> dropped >> > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: >> > exit(DROP) >> > >> >> Ok, with this patch in top of the other I think it should >> work. >> >> -- >> ============================================================== >> Jorge Boncompte - Ingenieria y Gestion de RED >> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones >> -------------------------------------------------------------- >> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) >> Tlf: +34 957 761395 / FAX: +34 957 450380 >> ============================================================== >> - Sin pistachos no hay Rock & Roll... >> - Without wicker a basket cannot be made. >> ============================================================== >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> <mailto:mpl...@li...> >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > |
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 13:28:06
|
Hi, Just a quick question: with the latest patches from jorge things work fine but the ping round trip time takes 800 ms via MPLS while without MPLS it takes around 0.8 ms. Is this the expected behaviour ? Thanks, Ahsan On Wed, May 19, 2010 at 12:45 PM, Chris Robson <Chr...@nr...>wrote: > > Never mind, darn junk mail filter broke again! > > > On 05/19/2010 06:35 AM, Chris Robson wrote: > > > Jorge, Ashan > > Was another patch sent out to fix the dropped packet problem? If so what? > > thanks > Chris > > On 05/19/2010 04:22 AM, Ahsan Tariq wrote: > > Hi, > > > Thanks, its working now. > > Ahsan > > On Tue, May 18, 2010 at 6:31 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote: > >> El 18/05/2010 17:50, Ahsan Tariq escribió: >> > Hi, >> > >> > I have also tested the new patch and there are no lock up problems but >> > the ip packet gets dropped after the label is popped >> > The debug trace is below : >> > >> > [ 19.721739] MPLS: version 1.963 >> > [ 19.759418] MPLS: protocol driver interface - <jl...@mi... >> > <mailto:jl...@mi...>> >> > [ 19.835020] MPLS: IPv4 over MPLS support >> > [ 20.406281] MPLS: IPv6 over MPLS support >> > [ 494.929061] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter >> > [ 494.929065] MPLS mpls_skb_dump: from eth1 with len 88 >> > (424)headroom=48 tailroom=56 >> > [ 495.037702] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter >> > [ 495.037703] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input: >> > labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63 >> > [ 495.037708] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode >> POP >> > [ 495.037710] MPLS DEBUG net/mpls/mpls_input.c:130:mpls_input: dropped >> > [ 495.037712] MPLS DEBUG net/mpls/mpls_input.c:283:mpls_skb_recv: >> > exit(DROP) >> > >> >> Ok, with this patch in top of the other I think it should work. >> >> -- >> ============================================================== >> Jorge Boncompte - Ingenieria y Gestion de RED >> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones >> -------------------------------------------------------------- >> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) >> Tlf: +34 957 761395 / FAX: +34 957 450380 >> ============================================================== >> - Sin pistachos no hay Rock & Roll... >> - Without wicker a basket cannot be made. >> ============================================================== >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> mpls-linux-devel mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel >> >> > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > mpls-linux-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel > > |
|
From: Ahsan T. <ahs...@gm...> - 2010-05-19 14:35:48
|
Hi,
So disabling debug everything is ok :). So i have another question: Below is
a debug trace
for one ping as seen on an MPLS enabled router. While sending an MPLS packet
the
MAC header (bold lettering) is incomplete, but while recieving an MPLS
packet the
MAC header is complete. Is this expected behaviour or am I interpreting it
wrongly ?
Thanks
Ahsan
[ 8276.558954] MPLS DEBUG net/mpls/mpls_output.c:289:mpls_output: enter
[ 8276.558957] MPLS DEBUG net/mpls/mpls_output.c:328:mpls_output: exit
[ 8276.558960] MPLS DEBUG net/mpls/mpls_output.c:153:mpls_output2: enter
[ 8276.558962] MPLS DEBUG net/mpls/mpls_output.c:171:mpls_output2: opcode
PUSH
[ 8276.558964] MPLS DEBUG net/mpls/mpls_opcode.c:118:mpls_push: enter
[ 8276.558966] MPLS DEBUG net/mpls/mpls_opcode.c:132:mpls_push: using gap
[ 8276.558968] MPLS DEBUG net/mpls/mpls_opcode.c:188:mpls_push: exit
[ 8276.558970] MPLS DEBUG net/mpls/mpls_output.c:171:mpls_output2: opcode
SET
[ 8276.558972] MPLS DEBUG net/mpls/mpls_opcode.c:992:mpls_out_op_set: enter
[ 8276.558974] MPLS DEBUG net/mpls/mpls_opcode.c:1008:mpls_out_op_set: exit
[ 8276.558976] MPLS DEBUG net/mpls/mpls_output.c:77:mpls_send: output device
= eth1
[ 8276.558978] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=44
tailroom=60
[ 8276.649709]
179b0b000000000000000000000000003f160000000000002d6f000000000000fc66**
00093d12df0e00093d12*
{#|003e813f45000054000040003f01dc50c0a86e02c0a8700508004361742a000120ecf34b000000006468090000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
[ 8276.963969] MPLS DEBUG net/mpls/mpls_output.c:124:mpls_send: using
neighbour (ffff8800c9047380)
[ 8276.963977] MPLS DEBUG net/mpls/mpls_output.c:131:mpls_send: mpls_send
result 0
[ 8276.963979] MPLS DEBUG net/mpls/mpls_output.c:205:mpls_output2: exit
[ 8277.782838] MPLS DEBUG net/mpls/mpls_input.c:229:mpls_skb_recv: enter
[ 8277.782841] MPLS mpls_skb_dump: from eth1 with len 88 (424)headroom=48
tailroom=56
[ 8277.873549]
000000000c07ac0000093d12df0d080045000089b28840004011d8ac8b1396038b13*
*00093d12df0e00093d125ffe8847*
{#|007d013f450000542ac000003f01f190c0a87005c0a86e0200004b61742a000120ecf34b000000006468090000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536376c}
[ 8278.196542] MPLS DEBUG net/mpls/mpls_input.c:60:mpls_input: enter
[ 8278.196543] MPLS DEBUG net/mpls/mpls_input.c:74:mpls_input:
labelspace=0,label=2000,exp=0,B.O.S=1,TTL=63
[ 8278.196548] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode POP
[ 8278.196550] MPLS DEBUG net/mpls/mpls_input.c:96:mpls_input: opcode PEEK
[ 8278.196552] MPLS DEBUG net/mpls/mpls_input.c:172:mpls_input: delivering
[ 8278.196559] MPLS DEBUG net/mpls/mpls_input.c:275:mpls_skb_recv: exit(0)
On Wed, May 19, 2010 at 3:30 PM, Jorge Boncompte [DTI2] <jo...@dt...>wrote:
> El 19/05/2010 15:27, Ahsan Tariq escribió:
> > Hi,
> >
> > Just a quick question: with the latest patches from jorge things work
> > fine but the ping
> > round trip time takes 800 ms via MPLS while without MPLS it takes around
> > 0.8 ms.
> > Is this the expected behaviour ?
>
> If you have the debug information enabled yes else no :)
>
> --
> ==============================================================
> Jorge Boncompte - Ingenieria y Gestion de RED
> DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
> --------------------------------------------------------------
> C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
> Tlf: +34 957 761395 / FAX: +34 957 450380
> ==============================================================
> - Sin pistachos no hay Rock & Roll...
> - Without wicker a basket cannot be made.
> ==============================================================
>
>
|
|
From: Chris R. <Chr...@nr...> - 2010-05-22 11:01:53
|
James, Jorge
Finally have a good (I think) Fedora 12 rpmbuild kernel as pings thru a
LSP between LERs works. However, netperf is failing with "Interrupted
system call" on the netperf side (aka netperf --> netserver). Below is
the mpls debug ping and netperf output as seen from the netserver side).
I need to test using a file seed possible all the zeros is causing mpls
some heart burn, I did test doing using FTP which of course ended up
only using one LSP but it still worked. I will do that later today
using netperf seeded with a file. Is there anything here you observe as
strange?
One thing that does bother me is some debug output is missing, even with
"echo "1" > /proc/sys/net/mpls/debug". Possibly I'm missing something
from "sysctl.log" settings?
Also, James, many moons ago I reported issues with 10GE running horribly
slow. At the time it was assumed when building MPLS-Linux, debug was
turned off by default. Ashan's discover suggested another look at the
build files when of course I discovered its on by default. So I will
retest 10GE LSPs next week. But might I suggest that debug be turned
off by default?
...Chris
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
PING
TESTS--------------------------------------------------------------------------------------
May 22 06:25:05 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 88
(1832)headroom=48 tailroom=1464
May 22 06:25:05 FEON kernel:
0000000000000000505ca30000000005ffff1f00000100000e00ffff010700002020*00051b70e93700051b00475e8847{#
|007d014045000054000040004001e6420a326e010a32d2010800302bd60d000101b1f74b0000000033f6060000000000101112131415161718191a1b
1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363799}
May 22 06:25:05 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 88
(360)headroom=76 tailroom=28
May 22 06:25:05 FEON kernel:
003877360188ffff081077360188ffff081077360188ffff00000000010000004032540200eaffff00000000000000000000000001000000010000000000000000
1077360188ffff08207736{|003e814045000054b3300000400173120a32d201#0a326e010000382bd60d000101b1f74b0000000033f60600000000001011
12131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
NETPERF SERVERSIDE
TESTS-------------------------------------------------------------------------------
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 64
(1832)headroom=48 tailroom=1488
May 22 06:25:33 FEON kernel:
0080a6340188ffff505ca30000000005ffff1f00000100000e00ffff010700002020*00051b
70e93700051b00475e8847{#|007d01404500003c045240004006e2030a326e010a32d201c14032411226796400000000a00216d
0e0800000020405b40402080a00067d36000000000103030732}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 64
(552)headroom=240 tailroom=16
May 22 06:25:33 FEON kernel:
00b0f9340188ffff050200001f00000012020000061d0b00000000000100000058b1540200eaf
fff00000000000000000000000001000000010000000000000001000000000000000000000000000000000000000000000000b1540
200eaffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000008010000000625b8{|003e81404500003c000
040004006e6550a32d201#0a326e013241c1401154b13412267965a01216a093550000020405b40402080a00068abb00067d360103030700}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 56
(1832)headroom=48 tailroom=1496
May 22 06:25:33 FEON kernel:
00a0a6340188ffff505ca30000000005ffff1f00000100000e00ffff010700002020*00051b70e9370
0051b00475e8847{#|007d014045000034045340004006e20a0a326e010a32d201c1403241122679651154b1358010002ed88f00000101
080a00067d3a00068abbcb}
May 22 06:25:33 FEON kernel: MPLS mpls_skb_dump: from eth1 with len 312
(1832)headroom=48 tailroom=1240
May 22 06:25:33 FEON kernel:
0080a6340188ffff30007374000062736f6e2f2e636f6e6669672f6d656e75732f73*00051b70e9370
0051b00475e8847{#|007d014045000134045440004006e1090a326e010a32d201c1403241122679651154b1358018002ed765000001010
80a00067d3c00068abb0000000affffffffffffffffffffffff0000000000000008000000000000000000000000000000000000000a0000
000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000016}
|
|
From: Chris R. <Chr...@nr...> - 2010-05-23 09:43:21
|
James, Jorge Hold the fire hoses. I thought someone had stated mpls-linux had roots in VLAN code so I tested netperf using VLAN tags. It turns out netperf has issues with VLAN tagged packets as well. aka the source system terminates the send with the same "Interrupted system call" error message when sending vlan tagged packets to a target. This is very disappointing, as netperf has been a valuable perf tool. I guess exploration into netperf more is warranted. ....Chris On 05/22/2010 07:01 AM, Chris Robson wrote: > James, Jorge > > Finally have a good (I think) Fedora 12 rpmbuild kernel as pings thru a > LSP between LERs works. However, netperf is failing with "Interrupted > system call" on the netperf side (aka netperf --> netserver). Below is > the mpls debug ping and netperf output as seen from the netserver side). > I need to test using a file seed possible all the zeros is causing mpls > some heart burn, I did test doing using FTP which of course ended up > only using one LSP but it still worked. I will do that later today > using netperf seeded with a file. Is there anything here you observe as > strange? > > > > |
×
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