pats dar prisiminiau kad tik 192.168.5.0 kreipiasi y 192.168.1.0, 
192.168.1.0 nelenda pats atgal, taj tiesiog galeciau 192.168.5.0 daryt 
Masquerade ant 10.0.1.2 y 192.168.1.0, tad serveris A matys paketus kajp 
is 10.0.1.2 ir todel atsakines per 10.0.1.1. O is serverio B tiesiog 
NAT'inti per MPLS'a y 192.168.6.253.

rabarbaras wrote:
> Ruoteriui nusispjaut is kur gavo paketa - jo reikalas zinoti 
> destination. Tai ka cia sugalvojai gal but imanoma isspresti su 
> marsrutizavimo protokolais.
> Kaip cia supratau MPLS'as pridetas avarijos atveju linkui backupuoti?
> Del to nutrukus 10.0.1.0 linkui turetum statiskai pakeisti routinima.
> Max ka as esu isgalvojes is tokiu scenariju - 192.168.5.0 ir 192.168.1.0 
> tinklus per skirtingus linkus galima apjungti su SourceRouting+NAT.
> Pradzia bus http://lartc.org/
> 
> rycius wrote:
>> sveiki, turiu toki galvosuki, atachmente yra prisegta tinklo struktura 
>> ( tik serveryje A turetu buti IP ne 10.0.1.2 o 10.0.1.1, tiesiog 
>> bepaisydamas klaida padariau). Is LAN 192.168.5.0/24 yra bendraujama 
>> su LAN 192.168.1.0/24 per linka 10.0.1.0/30. Bet db prisireike kad LAN 
>> 192.168.5.0/24 galetu bendrauti per MLPS VPN su 192.168.6.253.
>>
>> Serveryje B tiesiog padaryta:
>> route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.1
>> route add -net 192.168.6.0 netmask 255.255.255.0 gw 192.168.5.253
>>
>> Serveryje A:
>> route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.0.1.2
>>
>> kajp man cia issisukti serveryje A, kadangi jame gaunasi kad 
>> 192.168.5.0/24 potinkli jis gali pasiekti ir per 10.0.1.2 ir per 
>> 192.168.6.253. Cia as kajp suprantu, kazkokiu budu reiktu serveriui A 
>> susigaudyti per kuri linka serveris gavo uzklausa is 192.168.5.0/24 ir 
>> per ta linka jam atsakyti. Gal kas uzvestumete ant kelio kajp tai 
>> padaryti?
>>
>>
>> ------------------------------------------------------------------------
>>