[ miodragpro @ 17.09.2011. 16:00 ] @
Dobri ljudi iz sveta Enterprise Networking-a, imam jednu nedoumicu koja me tišti evo već par dana a to je:
- Relacija između route mapa i policy lista u BGP protokolu.
Primer:
POLISA:
Code:
Router(config)# ip policy-list POLICY-LIST-NAME-1 permit 
Router(config-policy-list)# match as-path 1
Router(config-policy-list)# match metric 10
Router(config-policy-list)# end
------------------------------------------------------------------
Router(config)# ip policy-list POLICY-LIST-NAME-2 permit 
Router(config-policy-list)# match community 20
Router(config-policy-list)# match metric 10
Router(config-policy-list)# ip community-list 20 permit 20:1
Router(config-policy-list)# end
------------------------------------------------------------------
Router(config)# ip policy-list POLICY-LIST-NAME-3 deny 
Router(config-policy-list)# match community 20
Router(config-policy-list)# match metric 10
Router(config-policy-list)# end


ROUTE MAPA:
Code:
Router(config)# route-map MAP-NAME-1 10
Router(config-route-map)# match ip-address 1
Router(config-route-map)# match policy-list POLICY-LIST-NAME-1 
Router(config-route-map)# match policy-list POLICY-LIST-NAME-2 
Router(config-route-map)# set community 10:1
Router(config-route-map)# set local-preference 140
Router(config-route-map)# end
------------------------------------------------------------------
Router(config)# route-map MAP-NAME-2 10
Router(config-route-map)# match policy-list POLICY-LIST-NAME-3 POLICY-LIST-NAME-4
Router(config-route-map)# set community 10:1
Router(config-route-map)# set local-preference 140
Router(config-route-map)# end
------------------------------------------------------------------

Buni me to što i jedna i druga varijanta imaju match klauzulu, koja je prednost ovih policy lista u odnosu na route mape?
Primer sam našao ovde.

- Regular expressions u BGP-u, naravno, ako bi neko naveo neki primer upotrebe i kratko objašnjenje istih. Sporna mi je upotreba sledećih karaktera:

| * Zero or more instances
|----------------------------------------------------
| + One or more instance
|-----------------------------------------------------
| ? Zero or one instance


Hvala unapred.

[Ovu poruku je menjao miodragpro dana 17.09.2011. u 17:12 GMT+1]

[Ovu poruku je menjao miodragpro dana 17.09.2011. u 17:13 GMT+1]

[Ovu poruku je menjao miodragpro dana 18.09.2011. u 18:59 GMT+1]

[Ovu poruku je menjao miodragpro dana 18.09.2011. u 19:01 GMT+1]
[ B3R1 @ 20.09.2011. 21:40 ] @
Policy liste sluze za grupisanje vise uslova, u cilju uproscavanja route mapa. Policy liste, za razliku od route mapa, imaju samo match klauzule, odnosno sluze samo da se ispitaju odredjeni uslovi (da li ruta sadrzi odredjeni BGP atribut ili ne) i vracaju TRUE ili FALSE kao rezultat. Ali same policy liste nemaju mogucnost definisanja akcije. Pogledaj "Restrictions" na toj stranici koju si citirao.

Sve u svemu ogavno budzenje na kvadrat, kojim je Cisco pokusao da napravi mehanizam route mapa u standardnom IOS-u malcice elasticnijim. U IOS-XR je to reseno na mnogo fleksibilniji i mocniji nacin. :-)

Policy liste sluze zapravo za sazimanje konfiguracije i izbegavanje ponavljanja istih provera u razlicitim route mapama - umesto:

route-map MAP1 permit 10
match community 10 101 102
match as-path 11
match ip address 12
match ip next-hop 192.0.1.1
set community 65000:1
!
route-map MAP2 permit 10
match community 10 101 102
match as-path 11
match ip address 12
match ip next-hop 192.0.1.2
set community 65000:2
!
...
mozes da napises:

ip policy-list COMMON permit
match community 10 101 102
match as-path 11
match ip address 12
i onda da u svakoj route mapi samo pozoves taj "common" deo:

route-map MAP1 permit 10
match policy-list COMMON
match ip next-hop 192.0.1.1
set community 65000:1
!
route-map MAP2 permit 10
match policy-list COMMON
match ip next-hop 192.0.1.2
set community 65000:2
...

Citat:
Regular expressions u BGP-u, naravno, ako bi neko naveo neki primer upotrebe i kratko objašnjenje istih

Da ne bih izmisljao toplu vodu, ima ko je to uradio pre mene na veoma sazet i elegantan nacin:

http://blog.ine.com/2008/01/06...nding-bgp-regular-expressions/
[ miodragpro @ 21.09.2011. 10:15 ] @
Berislave, hvala na pojednostavljenom objašnjenju. Da li konstatacija "ogavno budženje" znači i to da se iste i ne primenjuju baš često u realnim uslovima tj. u produkciji?
[ B3R1 @ 21.09.2011. 13:23 ] @
Citat:
miodragpro: Berislave, hvala na pojednostavljenom objašnjenju. Da li konstatacija "ogavno budženje" znači i to da se iste i ne primenjuju baš često u realnim uslovima tj. u produkciji?
Da li se negde primenjuju ili ne, ne znam.

Jedino mogu da kazem da ja licno to nikada u praksi nisam koristio. :-)

Stavise, cim vidim da na nekom mestu imam poduzu route mapu stavim prst na celo i krenem da razmisljam o totalnom redizajnu rutiranja. Jer izuzetno slozene konfiguracije i ekstremno dugacke route mape su obicno odraz propusta u dizajnu ili - daleko cesce - loseg planiranja kapaciteta i neblagovremenog upgrade-a na linkovima i interkonekcijama (peering & transit). I onda to krene - najpre napravis jedan izuzetak od postavljenog pravila za jedan prefiks ili ASN, tako reci zakrpu route mape ... pa onda izuzetak od izuzetka, odnosno zakrpu zakrpe ... i tako redom, a route mapa raste li raste. Na kraju dodjes do situacije da kada BGP sesija pukne iz nekog razloga ruterima treba i do pola sata da ponovo razmene sve rute, jer BGP scanner svaki primljeni prefiks propusta kroz tu dzinovsku route mapu i odlucuje da li ga treba prihvatiti / oglasiti ili ne. Za to vreme control plane podivlja, jer CPU utilization skoci na blizu 100%, zbog cega padaju i LDP i IGP procesi ... a onda i ta BGP sesija ponovo pukne i tako u krug ...

S druge strane ako napravis dobar dizajn u pocetku i organizujes proces upgrade-a kapaciteta kako valja potrebe za slozenijim pravilima rutiranja nema. Route mape su kratke, jasno citljive cak i za priucene ljude cije je znanje ispod CCNA nivoa, takve konfiguracije mogu lako da se dokumentuju i standardizuju. A ako BGP sesija pukne rute se brzo razmene i nema dugotrajnog opterecenja control plane-a.

A pod "ogavnim budzenjem" mislim na nacin na koji je Cisco uveo tu i slicne modifikacije route mapa. To je uvedeno u vreme IOS 12.0(22)S, bas kada su im Juniper i jos neki proizvodjaci krenuli da budu ozbiljni konkurenti. JUNOS ima izuzetno mocne "policy" mehanizme, koje je tek IOS-XR uspeo da dostigne po fleksibilnosti (moram da priznam da IOS-XR policies izgledaju lepo, cak podsecaju na programske jezike - if / then / else ... ). :-)