Házirend-alapú útválasztás konfigurálása

A házirend-alapú útválasztás segítségével megváltoztatható a következő ugrás IP-címe a bizonyos kritériumoknak megfelelő forgalom esetében. Ez hasznos lehet az útválasztási táblázat felülbírálására bizonyos forgalomtípusok esetében. Megmutatom, hogyan kell a házirend alapú útválasztást konfigurálni.

Konfiguráció

Itt van a topológia, amit használni fogunk:

Nézze meg a fenti topológiai képet. Az OSPF minden útválasztón be van konfigurálva. Mivel mindenhol gigabites interfészeket használunk, az R1-ről a 4.4.4.4.4-re irányuló forgalom normál esetben az R2 és az R3 között kerülne terheléselosztásra. Azonban megváltoztattam a költséget az R1 Gigabit Ethernet 0/3-as interfészén, így az összes forgalom az R1 > R2 > R4-ről fog menni.

Vizsgáljuk meg ezt:

Fentebb látható a megnövekedett költség. Próbáljunk ki egy gyors traceroute-t a H1-ről:

Most tegyük fel, hogy az R1 és R3 közötti linket szeretném használni, hogy elérjem a 4.4.4.4.4-et. Befolyásolhatom az OSPF metrikát, de ez minden forgalomra vonatkozik. Mi van, ha ezt a linket csak bizonyos forgalomra szeretném használni?

Az R1/R2 közötti linket használhatnánk a forgalom nagy részére, az R1/R3 közötti linket pedig csak bizonyos forgalomra. Ez nagyon hasznos lehet. Képzeljük el például, hogy az R1/R3 közötti link egy dedikált link, amely QoS-t kínál a VoIP forgalom számára.

Ezt a PBR (Policy Based Routing) segítségével érhetjük el Hadd mutassam meg, hogyan!

Most minden forgalmat R2 felé küldünk:

R1#show ip route | include 4.4.4.4O 4.4.4.4 via 192.168.12.2, 00:16:48, GigabitEthernet0/2

Most tegyük fel, hogy azt szeretnénk, hogy a H1-ről a 4.4.4.4.4-re irányuló összes ICMP forgalom átmenjen az R1/R3 közötti linken. Íme, hogyan csináljuk ezt:

R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4

Először is létrehozok egy hozzáférési listát, amely megfelel a forgalomnak. Most létre kell hoznunk egy route-mapot:

Ha a forgalom megfelel a hozzáférési listának, akkor a következő ugrást 192.168.13.3-ra (R3) változtatjuk.

Végül, de nem utolsó sorban aktiváljuk:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1 

Nézzük meg, hogy működik-e, hogy lássuk működés közben, engedélyezem a debugot az R1-en:

R1#debug ip policy Policy routing debugging is on

Most küldjünk egy pinget a H1-ről:

A ping működik, lássuk, mit szól hozzá az R1:

Fentebb látható, hogy a 192 felé irányított irányelvek szerint.168.13.3. Ezt a route-mapot is ellenőrizhetjük:

Kipróbáljunk egy olyan forgalmat, ami nem felel meg a hozzáférési listánknak. Például a Telnet:

H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open

H1 képes csatlakozni, de nem policy routed:

R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwarding

Amint fentebb láthatjuk, ez a telnet forgalom a normál útvonalat használja.

Még egy dolgot szeretnék megmutatni. A házirend-alapú útválasztásnál különbség van az útválasztón átmenő és az útválasztótól származó forgalom között.

A fenti példa a mi útválasztónkon átmenő forgalomra vonatkozik. Mi van akkor, ha az R1-ről induló forgalmat szeretnénk házirend alapján útválasztani? Akkor egy másik parancsot kell használnunk az aktiváláshoz. Hozzunk létre egy másik route-mapot:

A fenti route-map az R1-ről a 4.4.4.4.4-re érkező összes forgalmat átirányítja az R3 felé. Ennek aktiválásához egy másik parancsot kell használnunk:

R1(config)#ip local policy route-map PBR_R1

Ezúttal az ip local policy parancsot kell használnunk. Teszteljük ezt:

Nagyszerű, az R1-ről érkező forgalmunk a házirend szerint van irányítva.