для Cisco Cisco Packet Data Gateway (PDG)

Скачать
Страница из 180
  Reverse Route Injection 
How It Works  ▀   
 
SecGW Administration Guide, StarOS Release 17  ▄  
 
   
51 
How It Works 
The Connected Apps Linux Process (CALP) receives single or batched route insertion/deletion request, validates the 
message received is complete, and initiates the update of the route request. A route update API then injects the routes 
contained in the Routing Information Base (RIB) table of the ASR 9000 Route Processor (RP). 
A re-inject (replay) is an asynchronous event message from the ASR 9000 RP asking the StarOS CA client to replay all 
the route entries in its database from scratch. This message is usually generated in a drastic failure case where the RP 
has lost all the previously injected RRI routes in its Forwarding Information Base (FIB) table. 
Status Handler processes all incoming responses from CALP to batch requests. Each response has a batch_id which will 
be correlated to the corresponding batch request. Route entries that are not acknowledged are regrouped and 
retransmitted. Those that are successful are moved to the route database hash table and removed from this batch. State 
diagram provided below shows the various states that a RRI route entry can be based on the responses for its batch 
request. 
Figure 9. 
RRI Requests – State Diagram 
 
A StarOS proclet (cactrl) manages the creation and maintenance of the session with CALP. This session is the only 
communication channel between each StarOS VM and the ASR 9000 RSP. This oneP communication session must be 
established before any form of communication can occur between the two entities. See the oneP Communication chapter 
for detailed information.