[P4] L3

[Sandor Laki]

A lenti hiba eltűnik, ha kiszedem a parsolásból az elágazást. A packet 
bytok is helyre kerültek, azonban a lookupban használt kulcs nem az ip cím.

* Ez a konstrukció most nem megy:
parser parse_ethernet {
         extract(ethernet);
         return select(latest.etherType) {
             ETHERTYPE_IPV4 : parse_ipv4;
             default: ingress;
         }
     }

* Ezt írtam át erre, és így legalább nem hasal el:
parser parse_ethernet {
         extract(ethernet);
         return parse_ipv4;
}

Üdv.
Sanyi

2016.02.26. 13:35 keltezéssel, Sandor Laki írta:
> * Az Ethernet keret van a header 1-ben, ez megfelel a valóságnak
> * A header 2 esetén a len minden futatásnál más. A mellette szereplő 
> tartalomnak köze sincs a valósághoz. A lookupnak átadott kulcs nem az 
> ip mezők, azaz a parse-olás nagyon el van csúszva. Jelenleg van a p4 
> kódban egy elágazás az etherType alapján, ezt kiszedem aztán meglátjuk 
> mi lesz.
> * Írtam egy IP csomag generátort, ami nem próbál ARP-zni hanem 1 db IP 
> csomagot küld ki a megfelelő interfészen, ezzel most garantálható, 
> hogy mindig lesz IP csomag az Ethernet keretben, de ez általában nem 
> feltethető, azaz az ethertype szerinti elágazás kell majd.
>
> Ebéd után megírom, hogy mi lett  p4 kód módosítása után...
>
> Üdv.
> Sanyi
>
>
> 2016.02.25. 18:50 keltezéssel, Sandor Laki írta:
>> Sziasztok,
>>
>> Hátha valaki tudja, hogy mit is látunk itt. Egy IP csomagot küldök be 
>> kintről a DPDK L3 routernek, amire ez írja ki:
>> ### HANDLING PACKET ARRIVING AT PORT 0...
>>   :::: EXECUTING TABLE ipv4_fib_lpm
>>     :: NO RESULT, NO DEFAULT ACTION, IGNORING PACKET...
>>   :::: EGRESSING
>>     :: header 0 (type=0, len=20) = 00 00 00 00 00 00 00 00 00 00 00 
>> 00 00 00 00 00 00 00 00 00
>>     :: header 1 (type=1, len=14) = 00 00 00 00 01 01 96 37 23 79 2c 
>> 66 08 00
>>     :: header 2 (type=1, len=846177816) = 80 99 a0 df b8 7f 00 00 c0 
>> 1e 99 df b8 7f 00 00 80 15 99 df b8 7f 00 00 40 0c 99 df b8 7f 00 00 
>> 00 03 99 df b8 7f 00 00 c0 f9 98 df b8 7f 00 00 80 f0 98 df b8 7f 00 
>> 00 40 e7 98 df b8 7f 00 00 00 de 98 df b8 7f 00 00 c0 d4 98 df b8 7f 
>> 00 00 80 cb 98 df b8 7f 00 00 40 c2 98 df b8 7f 00 00 00 b9 98 df b8 
>> 7f 00 00 c0 af 98 df b8 7f 00 00 80 a6 98 df b8 7f 00 00 40 9...
>>
>> Mi akar itt lenni a header 2???
>>
>> Továbbá a csomag valós tartalmaz ez:
>> 18:43:51.744885 IP (tos 0x0, ttl 255, id 0, offset 0, flags [none], 
>> proto Options (0), length 40, bad cksum 6f27 (->a7d3)!)
>>     10.0.0.2 > 10.0.0.1:  ip 20
>>         0x0000:  4500 0028 0000 0000 ff00 6f27 0a00 0002 
>> E..(......o'....
>>         0x0010:  0a00 0001 0000 0000 0000 0000 0000 0000 
>> ................
>>         0x0020:  0000 0000 0000 0000 0000 0000 ............
>>
>> Eltekintve a bad chksumtól, amit a packet generátorom okoz, a lenti 
>> minta nem ismerhető fel a fentiben...
>>
>> Ha van ötlet, akkor írjatok! Holnap folytatom...
>>
>> Üdv.
>> Sanyi
>>
>
>


-- 
Sándor Laki, PhD
Assistant professor
Department of Information Systems
Eötvös Loránd University
Pázmány Péter stny. 1/C
H-1117, Budapest, Hungary
Room 2.506
Web: http://lakis.web.elte.hu
Phone: +36 1 372 2869 / 8477
Cell: +36 70 374 2646