kumanomiさん、こんばんは
返信ありがとうございます。

最初にソースコードは基本的に変えていません。
(routing_olsr-inria.cppの
#define DEBUG_OUTPUT 1に変更したことはあります。
これはrouting tableを表示するためのもので、特に変更しても統計結果が変わるようなことはありません。
添付したconfigとは別の環境ですが、同様にCBRを↑→↓←のように上下左右の何れかにリンクを張った際は、その張ったライン上を通ってパケットを中継していたことをrouting tableから確認しました。
ソースを誤って修正してしまったことによる統計値の変化がないことは断言します。)

長文のため、重要な文の前には★★をつけてあります。

kumanomiさんのPCでは、パケットドロップを確認できたとのことですが
添付したconfigファイルは本文の

「特に考え無しに,３項目ある【IP output Queue Size】の値を150000から全て1にした場合の結果も確認してみました。
すると、【Total Packets Dropped】にて5番ノードのみでパケット落ちが確認できてしまいましたが（metric value 75）」

上記の引用部分にあたりますので、確かにパケット落ちが確認できたと思います。
此方のＰＣでも確認できています。

【IP output Queue Size】
このような結果を確認して頂けたかと思います。【Total Packets Recieved】

★★おそらく、この結果を見たkumanomiさんは「何だ5番ノードでパケットドロップを確認できてるから問題解決。」
と思われての回答だと思うのですが、私はこの結果に納得できません。

初めは、【IP input Queue Size】を小さくすれば、中継されてくるパケットをキューに格納できずに、パケット落ちしてしまうと考えていたため、IP input Queue Sizeを1にしてシミュレーションを実行したが、結果は150000の時と変わらなかった。
つまり、中継されてくるパケットを格納するキューはinput queueではなかったことが分かりました。私が誤認していたわけです。

では、【IP output Queue Size】を小さくしたらどうなるかということを調べたのが添付したconfigファイル。
【IP output Queue Size】は３つあるインターフェース全て1byteです。

結果は挙げた通り、5番ノードで75[1]落ち。(今ままでインターフェスは[0]しか使われていなかったのに突然[1]が使われたことは若干謎である。インターフェースを[0]の１つだけにしたら[0]で75パケット落ち)

真っ先に思ったことは、【IP output Queue Size】を下げたら、5番ノードでパケット落ちが確認できたので、中継されてきたパケットを格納するのは、input Queueではなくoutput Queueのほうだったということです。

★★しかし、改めて考えてみると納得できない点があります。
この時の【Total Packets Sent】に対する【Total Packets Recieved】の変化です。
本文の通り
Item　Size(byte)　800byte（１パケットのサイズです）
（送信250,250パケットに対して、受信245,248）

しかし、5番ノードの【IP output Queue Size】は全てのインターフェースで１(byte)にしたはずです。
先ほど中継されてきたパケットはoutput Queueのほうに格納されると結論づけましたが、最低でも800byte(1パケットの単位)あるのに1byteしか格納できないはずのキューに格納されていることになってしまいます。
つまり私としては、１パケットですら５番ノードで格納できないので、全てのパケットが５番ノードで落ち、宛先端末ノードにはパケットが届くわけがないと考えているわけです。
（送信250,250パケットに対して、受信0,0）なら納得できます。

★★そのような結果にならないことから、そもそも「output Queue」「input Queue」とは何なのか理解できず、結果として、キューとパケット落ち、Total Packets Recievedの関連が分かりません。


なるべく詳細に現状をお伝えしたかったので、かなりの長文となってしまいました。
以下に最終的にやりたいこと、本トピックを立てた目的をまとめておきました。

これでも伝わらない点などあるかと思いますがご指摘いただければ捕捉をいれますので、よろしくお願いします。
ここまで読んで頂いてありがとうございました。


【最終的にやりたいこと】
3*3ではなく10*10のネットワークで、同様に2本のＣＢＲ通信を中央のノードで交差するように通信させ、中央のノードでパケットドロップを故意に起こします。
送信端末ノードは2つあるわけですが、片方のノードの全てのトラフィックを1列/2列隣りのノードを経由した時のトTotal Packets Recievedとパケットドロップの値を確認する。
（伝わりづらいかもしれないので図を下に書いておきました。）

さらに、下の送信端末ノードが4000パケットを送信していたと仮定し、
例えば、2列隣りの経路を使って3000パケット送信、残りの1000パケットを元の経路で送信したら、4000パケット全てを２列隣りの経路を使うより、良い結果（Total Packets Recievedが増える）になるネットワーク環境が必ずあるはず。
なぜなら、全て２列隣りの経路を通ってしまうと、結局トラフィックが交差するノードで同様にパケットドロップが起こるから。
ある程度のトラフィックを分散させることで、交差するノードでのパケットドロップを抑えることで、Total Packets Recievedがトータル的に見て増加するはず。

このように、トラフィックを分散させることで良い結果が得られるようなネットワーク環境を故意につくりたいと考えています。
それを知るために、まずはパケットドロップとキュー、Total Packets Recievedの関係を3*3のネットワーク環境で調べています。
分散方法については、後の課題です。（Static routing tableを考えていましたが、１つのノードは１つのstatic routing ファイルしか持てず、分散させることができないという課題が残っていますが...）

通常
　　↑
　　↑
→→→→→
　　↑
　　↑

2列隣り
　　←←↑
　　　　↑
→→→→→
　　　　↑
　　→→

【本トピックスのテーマ】
3*3の簡易なネットワークでキューとパケット落ち、Total Packets Recievedの関連について詳しく知る。
・どのような条件で初めて中継ノードでパケット落ちが発生するのか
・パケット落ちが発生することで、パケット受信量は結果的にどうなるのか
・input queue　とoutput queueはそもそも何なのか