„Aszimmetrikus route/en” változatai közötti eltérés

Innen: IT documentation
(Új oldal, tartalma: „bélyegkép|Asymmetric route Assimetric route is formed tipically, when in a network more router works. These can be in HA mode or connn…”)
(Frissítés, hogy megegyezzen a forráslap új változatával)
Címke: Kézi visszaállítás
 
(40 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva)
1. sor: 1. sor:
<languages>hu en</languages>
<languages/>


==Summary==
==Summary==


[[Fájl:Asymmetric route1.PNG|bélyegkép|Asymmetric route]]
[[Fájl:Asymmetric route1.PNG|bélyegkép|Asymmetric route]]
Assimetric route is formed tipically, when in a network more router works. These can be in HA mode or connnect different networks. We are talking about an asymmetric route if an host start a session via one router - typically via default router - , but the answer arrive via the other router.
Assimetric route is formed typically, when in a network more router works. These can be in HA mode or connect different networks. We are talking about an asymmetric route if an host start a session via one router - typically via default router - , but the answer arrive via the other router.


WAN környezetben ez nem probléma, sőt előny, hiszen az IP hálózat egyik alap tulajdonsága, hogy több útvonal létezik A és B pont között, amit dinamikusan választanak ki a routerek.
There is no problem in WAN environment, in fact this is an advantage, because the one of base feature of IP network that there are several route between A and B point, what the routers choose dynamically.


LAN környezetben az okozza a problémát, hogy L2 szinten a válasz más címtől (mac address) érkezik, mint ami felé indult a kommunikáció. Amit egyébként okozhat közbeékelődés is (man in the middle), ezért az eszközök, illetve a protokollok egy része biztonsági okokból nem támogatják az aszimmetrikus route-ot. Továbbá IP stack implementáció kérdése is az aszimmetrikus route érzékenysége egy eszköznek.
In LAN environment the problem is that on L2 the answer arrives from other mac address, the communication was heading for. The man in the middle attack may cause this anyway, therefore the devices and protocols do not support the asymmetric route. Furthermore the asymmetric route sensitivity of an device depend on level of IP stack implementation too.


Egy eszköz route táblájában csak egy (működő) alapértelmezett átjáró lehet, ezért az aszimmetrikus route okozta problémák és anomáliák elkerülése miatt a hálózati topológiát logikailag és / vagy fizikailag mindig úgy kell szervezni, hogy egy alapértelmezett átjárón keresztül elérhető legyen az összes egyéb hálózat és szolgáltatás.
In a route table of a device can be only one (active) default route, therefore to avoid the problems and anomalies caused by asymmetric route the network topology must be logically and / or physically organized to the all network and services can be accessible via one default gateway.
 
Az alább cikk az aszimmetrikus route eseteit és a lehetséges elkerülő módszereket mutatja be.


The below article shows cases of the asymmetric route and possible methods of avoidance.


==Multiple gateways==
==Multiple gateways==


[[Special:MyLanguage/Fájl:Asymmetric route2.png|bélyegkép|Multiple gateways & asymmetric route ]]
[[Fájl:Asymmetric route2.png|bélyegkép|Multiple gateways & asymmetric route ]]
Ez esetben a router-ek mögött különböző hálózatok érhetőek el.  
In this case difference networks are available behind the routers.  


Az aszimmetrikus route a következő módszerekkel küszöbölhető ki ilyen esetben.
The asymmetric route can be eliminated with next methods in such a case.


===Static route===
===Static route===


[[Special:MyLanguage/Fájl:Asymmetric route3.png|bélyegkép|Multiple gateways & static route]]
[[Fájl:Asymmetric route3.png|bélyegkép|Multiple gateways & static route]]
Az alapértelmezett átjáró mellett az operációs rendszereken lehetőség van statikus route-ok felvételére. A pédában az 1. router az alapértelmezett átjáró, a 2. router felé pedig statikus route-ot veszünk fel. Így a tárgyi host tudni fogja, hogy bizonyos hálózatok felé más irányba kell küldeni a csomagokat, mint az alapértelmezett átjáró.
There is possibility set static route in operating systems next to default gateway. In the example the default route is the router 1., and we set a static route to router 2. So the current host will know some networks need to send packets in a different direction than the default gateway.


Statikus route hozzáadása windowson:<syntaxhighlight lang="dos">
Add static route in Windows:<syntaxhighlight lang="dos">
route -p add 192.168.2.0 MASK 255.255.255.0 192.168.0.2
route -p add 192.168.2.0 MASK 255.255.255.0 192.168.0.2
</syntaxhighlight>Statikus route hozzáadása linuxon:<syntaxhighlight lang="bash">
</syntaxhighlight>Add static route in linux:<syntaxhighlight lang="bash">
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.2 dev eth0
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.2 dev eth0
</syntaxhighlight>vagy<syntaxhighlight lang="bash">
</syntaxhighlight>or<syntaxhighlight lang="bash">
ip route add 192.168.2.0/24 via 192.168.0.2 dev eth0
ip route add 192.168.2.0/24 via 192.168.0.2 dev eth0


</syntaxhighlight>A módszer hátránya nyilvánvaló, sok host esetében sok manuális beállítás, illetve ha változik a hálózati konfiguráció, manuálisan kell lekövetni a változást is. Csak egy-két host esetében érdemes használni, például ha egy szervert el kell érni a 2. router mögötti hálózatból.
</syntaxhighlight>The disadvantage of this method is obvious, in many host case there are many manually setting and if the network configuration is changed we have to also follow manually the changes. Only in few hosts case worth use this, for example one server must be accessible from the network behind router 2.
 
 
===Statikus route terjesztése DHCP<ref>[https://hu.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP protokoll]</ref> -vel===


A módszer lényege ugyanaz, mint a statikus route-nál, azzal a különbséggel, hogy a DHCP-n keresztül kapják meg a statikus route beállításokat a hostok. Így a konfiguráció rugalmassá és egyszerűvé válik.
===Distribute static route with DHCP<ref>[https://hu.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP protokoll]</ref>===


A DHCP 33 (host), 121 (network) és 249 (Microsoft) opciója szolgáltatja a statikus route-okat, de hogy a host értelmezi e azokat, az már DHCP kliens implementáció kérdése. A magasabb szintű IP eszközök jellemzően kezelik (pl.: operációs rendszerek), de az egyszerűbbek már nem feltétlen (pl.: nyomtatók). Ezért ha a hálózat minden elemének minden esetben tudni kell kommunikálni a 2. hálózattal, akkor ez a módszer sem megfelelő.
The essence of the method is the same like at the static route with the difference that the hosts get the the static route over DHCP. So the configuration becomes simple and flexible.


===Policy based routing===
The 33 (host), 121 (network) and  249 (Microsoft)options of DHCP provide the static routes, however the host can understand these are already a matter of DHCP client implementation. The IP devices with higher level typically operate (e.g. operating systems), but the simpler ones not necessarily (e.g. printers). Therefore if our all devices have to communicate with the network 2. then this method is not appropriate either.


[[Special:hu/Fájl:Asymmetric route4.png|bélyegkép|Multiple gateways & policy based route]]
===Policy based routing <ref>[[wikipedia:Policy-based_routing|Policy based routing]]</ref>===
Nincs más hátra, mint megváltoztatni a hálózati topológiát.


Az 1. routeren van egy statikus route a 2. router felé. Ez adott, hiszen az aszimmetrikus route létrejöttéhez is kell.
[[Fájl:Asymmetric route4.png|bélyegkép|Multiple gateways & policy based route]]
All you have to do is change the network topology.


A 2. routernek viszont megmondjuk, hogy minden esetben az 1. routernek küldje a tárgyi hálózatba irányuló forgalmat, annak ellenére, hogy az eszköznek van interfésze (connected route) ebben a hálózatban. Ez ellenkezik az alap routing logikával, ezét kell felvenni rá egy szabályt.
There is a static route to router 2. in router 1. It is given, because also required to create an asymmetric route.


Hogy egy router milyen beállításokkal képes ilyen működésre, illetve hogy képes e, az gyártó és típus kérdése, új eszköz integráció előtt mindenképpen tájékozódni kell róla.
However we set to router 2., that in every case it send to router 1.  the traffic to the current network, even though, router 2. have an interface in this network (connected route). This is opposite the base routing logic that is why we have to set this rule.


Hátránya, hogy minden kereszt-hálózati forgalom (LAN 1 <-> LAN 2) megjelenik a LAN hálózatban. Sok hálózat összekötésére nem alkalmas. Jellemzően kényszerűségből választják ezt a módszert, ha valamely okból az egyéb megoldások nem használhatóak.
What settings a router can use to do this, or how it works at all is a matter for the vendor and type. Before new device integration be sure to find out about it.


===Helyes L3 topológia===
The disadvantage of this is all cross network traffic (LAN 1 <-> LAN 2) appears in the LAN network. it is not suitable for many network connection. Typically chosen out of compulsion this method, if other methods cannot be used.


[[Special:MyLanguage/Fájl:Asymmetric route5.png|bélyegkép|Right topology, one gateway in a network]]A végső megoldás az, ha úgy szervezzük a hálózatot, hogy valóban csak egy átjáró (router) legyen egy alhálózatban. Az alhálózatok routerekkel, a routerek pedig dedikált interfészekkel és technikai alhálózatokkal kommunikáljanak egymással. Mindig erre kell törekedni, amennyiben nincs kizáró ok. 
===Right L3 topology===


[[Fájl:Asymmetric route5.png|bélyegkép|Right topology, one gateway in a network]]The finally solution is we organize the network that really only one gateway (router)  be in a subnet. Let the subnets communicate via routers and the routers communicate via deficated interfaces and technical subnets to each other. Always have to strive for this, if there is no reason for exclusion.


==HA<ref>[[wikipedia:High_availability|High availability]]</ref> router==
==HA<ref>[[wikipedia:High_availability|High availability]]</ref> router==


[[Special:MyLanguage/Fájl:Asymmetric route6.png|bélyegkép|HA routers]]
[[Fájl:Asymmetric route6.png|bélyegkép|HA routers]]
Ekkor a router-ek mögött ugyanazok a hálózatok érhetőek el. (vagy különbözőek, de ugyanaz a céljuk. pl.: redundáns ISP) Ez esetben azért helyezünk két routert a hálózatba, mert azt szeretnénk, hogy ha az egyik meghibásodik vagy egyéb más ok miatt nem tudja ellátni a feladatát, akkor a másik végezze el azt.
At this time there are the same networks (or different ones, but its purposes are the same, e.g. redundance ISP) behind the routers. In this case we put two routers into the network, because we would like that  if one router get out of order or it cannot do its job for other reason, then the another router carry out it.


Egy alhálózatban nem lehet két eszköznek ugyanaz az IP címe. Tehát a két routernek különböző IP címe lesz, amiből csak az egyik lehet az alapértelmezett átjáró. Ezért HA átálláskor, ha a passzív router még elérhető a kliensek számára, akkor létrejön az aszimmetrikus route, ha pedig nem elérhető, akkor hiába működik a másik, a kliensek erről nem tudnak, így funkcionálisan nem fog működni a HA router cluster.
No two devices can have the same IP address in one network. So the two routers will have different IP addresses from which only one can be the default gateway. Terefore at the time of HA change-over if the passive router's address is available for the hosts then the asymmetric route is created, of if is not available then - in vain the other router is available - the hosts cannot communicate to other networks because they do not have knowledge about this. So the HA router cluster will no operate.


A megoldás valamely FHRP<ref>[[wikipedia:Category:First-hop_redundancy_protocols|FHRP protokollok]]</ref> protokoll, amit arra fejlesztettek ki, hogy két eszköz eldöntse éppen melyik használjon egy közös IP címet. Ha az egyik kiesik, a másik automatikusan felveszi azt, és folytatja a munkát vele.
The solution is to use one of FHRP<ref>[[wikipedia:Category:First-hop_redundancy_protocols|FHRP protokollok]]</ref> protocol, in order to the two devices can decide which uses the common address. If the one get out of order the another pick up the address automatically and it continues the operate.


A kliensek L2 szinten ARP<ref>[https://hu.wikipedia.org/wiki/ARP ARP protokoll]</ref> protokollon értesülnek a változásról, L3 szinten (számukra) nem történik változás a hálózatban.
The hosts are informed at level 2 by ARP<ref>[https://hu.wikipedia.org/wiki/ARP ARP protokoll]</ref> protocol, at level 3 there is no change (for them) in the network.


Hogy a router milyen FHRP protokollt támogat, illetve hogy támogat e, az szintén gyártó és típus függő.
What kind of FHRP protocol is supported by the router or is supported at all is also a matter for the vendor and type.
[[Kategória:Hálózat|Kategória:Hálózat]]
[[Kategória:Hálózat|Kategória:Hálózat]]
<references />
<references />

A lap jelenlegi, 2023. február 9., 15:01-kori változata

Más nyelvek:

Summary

Asymmetric route

Assimetric route is formed typically, when in a network more router works. These can be in HA mode or connect different networks. We are talking about an asymmetric route if an host start a session via one router - typically via default router - , but the answer arrive via the other router.

There is no problem in WAN environment, in fact this is an advantage, because the one of base feature of IP network that there are several route between A and B point, what the routers choose dynamically.

In LAN environment the problem is that on L2 the answer arrives from other mac address, the communication was heading for. The man in the middle attack may cause this anyway, therefore the devices and protocols do not support the asymmetric route. Furthermore the asymmetric route sensitivity of an device depend on level of IP stack implementation too.

In a route table of a device can be only one (active) default route, therefore to avoid the problems and anomalies caused by asymmetric route the network topology must be logically and / or physically organized to the all network and services can be accessible via one default gateway.

The below article shows cases of the asymmetric route and possible methods of avoidance.

Multiple gateways

Multiple gateways & asymmetric route

In this case difference networks are available behind the routers.

The asymmetric route can be eliminated with next methods in such a case.

Static route

Multiple gateways & static route

There is possibility set static route in operating systems next to default gateway. In the example the default route is the router 1., and we set a static route to router 2. So the current host will know some networks need to send packets in a different direction than the default gateway.

Add static route in Windows:

route -p add 192.168.2.0 MASK 255.255.255.0 192.168.0.2

Add static route in linux:

route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.2 dev eth0

or

ip route add 192.168.2.0/24 via 192.168.0.2 dev eth0

The disadvantage of this method is obvious, in many host case there are many manually setting and if the network configuration is changed we have to also follow manually the changes. Only in few hosts case worth use this, for example one server must be accessible from the network behind router 2.

Distribute static route with DHCP[1]

The essence of the method is the same like at the static route with the difference that the hosts get the the static route over DHCP. So the configuration becomes simple and flexible.

The 33 (host), 121 (network) and 249 (Microsoft)options of DHCP provide the static routes, however the host can understand these are already a matter of DHCP client implementation. The IP devices with higher level typically operate (e.g. operating systems), but the simpler ones not necessarily (e.g. printers). Therefore if our all devices have to communicate with the network 2. then this method is not appropriate either.

Policy based routing [2]

Multiple gateways & policy based route

All you have to do is change the network topology.

There is a static route to router 2. in router 1. It is given, because also required to create an asymmetric route.

However we set to router 2., that in every case it send to router 1. the traffic to the current network, even though, router 2. have an interface in this network (connected route). This is opposite the base routing logic that is why we have to set this rule.

What settings a router can use to do this, or how it works at all is a matter for the vendor and type. Before new device integration be sure to find out about it.

The disadvantage of this is all cross network traffic (LAN 1 <-> LAN 2) appears in the LAN network. it is not suitable for many network connection. Typically chosen out of compulsion this method, if other methods cannot be used.

Right L3 topology

Right topology, one gateway in a network

The finally solution is we organize the network that really only one gateway (router) be in a subnet. Let the subnets communicate via routers and the routers communicate via deficated interfaces and technical subnets to each other. Always have to strive for this, if there is no reason for exclusion.

HA[3] router

HA routers

At this time there are the same networks (or different ones, but its purposes are the same, e.g. redundance ISP) behind the routers. In this case we put two routers into the network, because we would like that if one router get out of order or it cannot do its job for other reason, then the another router carry out it.

No two devices can have the same IP address in one network. So the two routers will have different IP addresses from which only one can be the default gateway. Terefore at the time of HA change-over if the passive router's address is available for the hosts then the asymmetric route is created, of if is not available then - in vain the other router is available - the hosts cannot communicate to other networks because they do not have knowledge about this. So the HA router cluster will no operate.

The solution is to use one of FHRP[4] protocol, in order to the two devices can decide which uses the common address. If the one get out of order the another pick up the address automatically and it continues the operate.

The hosts are informed at level 2 by ARP[5] protocol, at level 3 there is no change (for them) in the network.

What kind of FHRP protocol is supported by the router or is supported at all is also a matter for the vendor and type.