README.md in packet_via_dmem-0.0.8 vs README.md in packet_via_dmem-0.0.10
- old
+ new
@@ -81,32 +81,27 @@
## Header format
### Received header
- * First byte is type of header?
- * 00 'lu packet' (i.e. whole packet was sent for lookup, i.e. small packet)
- * 10 'lu packet head' (i.e. only head of packet was sent for lookup, i.e. large packet)
+ * first four bits is message type
+ * 0 'lu packet' (i.e. whole packet was sent for lookup, i.e. small packet)
+ * 1 'lu packet head' (i.e. only head of packet was sent for lookup, i.e. large packet)
+ * next 13 bits is table entry (memory loc)
+ * next 11 bits is stream
+ * next 3 bits offset (for fabric cell sharing)
+ * next bit is size (17th bit, no way to test, would need >65k packets)
+ * next 16 bits is size (if message type is 1)
+ * next 8 bits is port
+ * next 8 bits is packet type
- * Second and third byte appear to tell nothing about where packet came from,
- but more when it came from. Timing? Counter? Randomness?
+ * packet type
+ * 0x00 real PITA, looks to be packets from control-plane, but amount of bytes that I need to pop I can't really figure out. I now rely on port# which likely isn't robust. This made me change my mind that 5th byte isn't port, but combined type, as it allowed, what seemed cleaner classification, but unfortunately it is not so.
+ * 0x08 is no-op, i don't need to pop anything, DMAC follows
+ * 0x20 this seems to be quite reliably mpls, i need to do some magic, as we're missing ethertype and my macs are wrong, there is also two extra bytes
+ * 0x80 is some short trash (payload 0xc013c6752759644ae0) no clue what it is
- * Fourth byte is 0xf0 on MX80, tendency for last nibble to be 0. Perhaps src fabric stream? If it is zero, we get what seems to be trash (internal stuff?)
-
- * Fifth byte appears to be source port?
-
- * Sixth byte is perhaps source NPU? If it is zero, we get what seems to be trash (internal stuff)
-
- * value of fift+sixth seems to sometime indicate special cases
- * 0x1fff - Packet missing everything before IPv4 TTL, yet has some extra. I saw BGP from control-plane with this and also TCP/SMB2 with Seq1, it was transit, but perhaps it was via ARP resolve/punt and thus coming from control-plane?
- * 0x2000 - BFD frames from control-plane or LACP IPv4, if next byte is 1 like below, if next byte is 0 missing MACs too (+5bytes)
- * 0x4220 - Was LACP MPLS traffic, missing ethertype, MACs changed, 2 mystery bytes
- * 0x8000 - I need to pop 14 bytes extra
-
- * 00 (22) (33) (44) \<src\> (66)
- * 10 (22) (33) (44) \<si\> \<ze\> \<src\> (66)
-
Example from MX960
00 00 c0 30 80 08
00 03 40 30 80 08
00 03 c0 70 81 08
@@ -182,20 +177,9 @@
00 06 00 f0 81 08
10 06 80 f0 05 b4 81 08
00 07 00 f0 80 08
10 07 80 f0 05 b4 81 08
10 0b 00 f0 02 28 81 08
-
-For this box, second to last byte, divmod 64, returns these ports, which are
-correct port for source.
-
- TAZ-TBB-0(X vty)# show ixchip ifd
- IFD IFD IX WAN Ing Queue Egr Queue
- Index Name Id Port Rt/Ct/Be H/L
- ====== ========== ====== ====== ============== ======
- 148 ge-1/0/0 2 0 0/32/64 0/32
- 149 ge-1/0/1 2 1 1/33/65 1/33
- 166 ge-1/1/8 2 18 18/50/82 18/50
### Sent header
I'm really not sure about sent headers, need more data to figure out what is
our type. For all my examples, when we sent frame without L2 headers for
fabric, it was MPLS, but almost certainly it can be IPv4, IPv6, ARP etc too.