Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
quagga i rozsyłanie as
38 views
Skip to first unread message
MaRc
Nov 8, 2011, 6:22:03 AM11/8/11
to
witam
mam dwóch operatorów od których dostaję pełną tablicę prefixów, tp i nask.
przyszedł do mnie klient ze swoim as i swoimi prefixami co by go
rozgłosić dalej. o ile z rozgłoszeniem do nasku nie ma problemu to tepsa
nie przyjmuje tranzytu as odemnie.
chce zrobić aby ruch od tego mojego klienta zawsze wychodził przez nask
bo i tak tepsa go nie przyjmie.
do tepsy rozsyłam jednynie swoje prefixy a do nasku moje i jego. to
działa. ale kwestia teraz wysłania prefixów do tego mojego klienta.
zrobiłem accesliste wycinającą as 5617 tepsy i podpiołem ją pod out do
klienta.
ip as-path access-list AS_GREF_OUT deny ^5617_
ip as-path access-list AS_GREF_OUT permit .*
po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale
niestety klient otrzymuje 1/3 wszystkich prefixów.
na przykładzie:
router-bgp# sh ip bgp 31.6.192.0/21
BGP routing table entry for 31.6.192.0/21
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
83.1.33.202
8308 5617 30824
195.18.22.17 from 195.18.22.17 (19.9.0.15)
Origin IGP, localpref 100, valid, external
Community: 5617:3389 8308:60050 8308:64000 8308:64100 8308:64120
Last update: Fri Nov 4 00:37:38 2011
5617 30824
80.5.4.29 from 80.5.4.29 (23.2.2.17)
Origin IGP, localpref 100, valid, external, best
Community: 5617:3389
Last update: Sun Oct 23 00:27:17 2011
jak widac, prefix ten mam osiągany przez nask jak i tepse.
jeśli nie zastosuje tej prefix listy na oucie dla gref to mu ten prefix
rozgłaszam, ale jednynie przez tepse:
router-bgp# show ip bgp neighbors 83.1.33.202 advertised-routes
...
*> 31.6.192.0/21 83.1.33.201 0 5617 30824 i
*> 31.6.192.0/22 83.1.33.201 0 5617 30824 i
...
podpinam teraz ta accesliste:
router-bgp# show ip bgp neighbors 83.1.33.202 advertised-routes
*> 1.0.4.0/22 83.1.33.201 0 8308 6695
6939 7545 7545 7545 7545 7545 56203 i
*> 1.0.64.0/18 83.1.33.201 0 8308 6939
4725 7670 18144 i
*> 1.5.0.0/16 83.1.33.201 0 8308 6939 4725 i
*> 1.18.117.0/24 83.1.33.201 0 8308 8928
3356 3786 9700 i
*> 1.18.119.0/24 83.1.33.201 0 8308 6939
4766 23600 i
*> 1.22.12.0/23 83.1.33.201 0 8308 3257
9498 45528 i
...
*> 31.6.64.0/21 83.1.33.201 0 8308 39869 i
*> 31.6.64.0/22 83.1.33.201 0 8308 39869 i
*> 31.6.68.0/23 83.1.33.201 0 8308 39869 i
*> 31.6.72.0/21 83.1.33.201 0 8308 6695
8468 25098 34555 i
*> 31.6.80.0/22 83.1.33.201 0 8308 6695
41313 34984 39582 i
*> 31.6.84.0/22 83.1.33.201 0 8308 6695
41313 34984 39582 i
*> 31.6.92.0/22 83.1.33.201 0 8308 8928 39582 i
*> 31.6.96.0/19 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.96.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.104.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.112.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.238.0/23 83.1.33.201 0 8308 24709
30824 i
...
no i tego prefixu mi nie rozsyła.
co prawda w mojej tablicy jako best jest właśnie przez tepse. czasem nie
tu leży problem, że begep dystrybuuje tylko najlepsze, wybrane trasy?
jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
--
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a
wówczas pobije cię swoimi argumentami.
mam dwóch operatorów od których dostaję pełną tablicę prefixów, tp i nask.
przyszedł do mnie klient ze swoim as i swoimi prefixami co by go
rozgłosić dalej. o ile z rozgłoszeniem do nasku nie ma problemu to tepsa
nie przyjmuje tranzytu as odemnie.
chce zrobić aby ruch od tego mojego klienta zawsze wychodził przez nask
bo i tak tepsa go nie przyjmie.
do tepsy rozsyłam jednynie swoje prefixy a do nasku moje i jego. to
działa. ale kwestia teraz wysłania prefixów do tego mojego klienta.
zrobiłem accesliste wycinającą as 5617 tepsy i podpiołem ją pod out do
klienta.
ip as-path access-list AS_GREF_OUT deny ^5617_
ip as-path access-list AS_GREF_OUT permit .*
po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale
niestety klient otrzymuje 1/3 wszystkich prefixów.
na przykładzie:
router-bgp# sh ip bgp 31.6.192.0/21
BGP routing table entry for 31.6.192.0/21
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
83.1.33.202
8308 5617 30824
195.18.22.17 from 195.18.22.17 (19.9.0.15)
Origin IGP, localpref 100, valid, external
Community: 5617:3389 8308:60050 8308:64000 8308:64100 8308:64120
Last update: Fri Nov 4 00:37:38 2011
5617 30824
80.5.4.29 from 80.5.4.29 (23.2.2.17)
Origin IGP, localpref 100, valid, external, best
Community: 5617:3389
Last update: Sun Oct 23 00:27:17 2011
jak widac, prefix ten mam osiągany przez nask jak i tepse.
jeśli nie zastosuje tej prefix listy na oucie dla gref to mu ten prefix
rozgłaszam, ale jednynie przez tepse:
router-bgp# show ip bgp neighbors 83.1.33.202 advertised-routes
...
*> 31.6.192.0/21 83.1.33.201 0 5617 30824 i
*> 31.6.192.0/22 83.1.33.201 0 5617 30824 i
...
podpinam teraz ta accesliste:
router-bgp# show ip bgp neighbors 83.1.33.202 advertised-routes
*> 1.0.4.0/22 83.1.33.201 0 8308 6695
6939 7545 7545 7545 7545 7545 56203 i
*> 1.0.64.0/18 83.1.33.201 0 8308 6939
4725 7670 18144 i
*> 1.5.0.0/16 83.1.33.201 0 8308 6939 4725 i
*> 1.18.117.0/24 83.1.33.201 0 8308 8928
3356 3786 9700 i
*> 1.18.119.0/24 83.1.33.201 0 8308 6939
4766 23600 i
*> 1.22.12.0/23 83.1.33.201 0 8308 3257
9498 45528 i
...
*> 31.6.64.0/21 83.1.33.201 0 8308 39869 i
*> 31.6.64.0/22 83.1.33.201 0 8308 39869 i
*> 31.6.68.0/23 83.1.33.201 0 8308 39869 i
*> 31.6.72.0/21 83.1.33.201 0 8308 6695
8468 25098 34555 i
*> 31.6.80.0/22 83.1.33.201 0 8308 6695
41313 34984 39582 i
*> 31.6.84.0/22 83.1.33.201 0 8308 6695
41313 34984 39582 i
*> 31.6.92.0/22 83.1.33.201 0 8308 8928 39582 i
*> 31.6.96.0/19 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.96.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.104.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.112.0/21 83.1.33.201 0 8308 6695
21219 43554 43554 43554 i
*> 31.6.238.0/23 83.1.33.201 0 8308 24709
30824 i
...
no i tego prefixu mi nie rozsyła.
co prawda w mojej tablicy jako best jest właśnie przez tepse. czasem nie
tu leży problem, że begep dystrybuuje tylko najlepsze, wybrane trasy?
jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
--
MaRc
Nie kłóć się z idiotą. Będziesz musiał zniżyć się do jego poziomu a
wówczas pobije cię swoimi argumentami.
Tomasz Winiarski
Nov 8, 2011, 7:05:14 AM11/8/11
to
On 08.11.2011 12:22, MaRc wrote:
> ip as-path access-list AS_GREF_OUT deny ^5617_
> ip as-path access-list AS_GREF_OUT permit .*
>
> po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale niestety klient
> otrzymuje 1/3 wszystkich prefixów.
>
Taka jest zasada działania protokołów routingu - routery wymieniają się najlepszymi wpisami
> ip as-path access-list AS_GREF_OUT deny ^5617_
> ip as-path access-list AS_GREF_OUT permit .*
>
> po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale niestety klient
> otrzymuje 1/3 wszystkich prefixów.
>
ze swojej tablicy routingu - jeśli masz lepsze trasy z TPSA i je odfiltrujesz to klient
dostanie tylko resztę prefixów. Czyli tutaj lepiej nie będzie.
Możesz spróbować zmienić routing klienta za pomocą route-map
--
Tomasz Winiarski
Jabber: tomekwin at jabber.org
mail: inactive user
MaRc
Nov 8, 2011, 7:06:37 AM11/8/11
to
W dniu 08.11.2011 12:22, MaRc pisze:
nawet wyślę klientowi ścieżki które nie są wybrane jako best to w sumie
i tak mi to nic nie da oprócz tego, że będzie miał on wszystkie prefixy.
Jego ruch i tak zostanie skierowany przez mój router tak jak ma w
tablicy routingu a nie w tablicy bgp więc i tak, jego pakiety będą szły
do tepsy, gdzie zostaną przez tepse dropowane :(
czy dobrze myślę?
> czasem nie tu leży problem, że begep dystrybuuje tylko najlepsze,
> wybrane trasy?
> jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
Tak się zastanawiam, czy czasem nie chcę walczyć z wiatrakami. Jeśli
> wybrane trasy?
> jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
nawet wyślę klientowi ścieżki które nie są wybrane jako best to w sumie
i tak mi to nic nie da oprócz tego, że będzie miał on wszystkie prefixy.
Jego ruch i tak zostanie skierowany przez mój router tak jak ma w
tablicy routingu a nie w tablicy bgp więc i tak, jego pakiety będą szły
do tepsy, gdzie zostaną przez tepse dropowane :(
czy dobrze myślę?
Tomasz Winiarski
Nov 8, 2011, 7:13:02 AM11/8/11
to
On 08.11.2011 13:06, MaRc wrote:
> W dniu 08.11.2011 12:22, MaRc pisze:
>> czasem nie tu leży problem, że begep dystrybuuje tylko najlepsze,
>> wybrane trasy?
>> jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
>
> Tak się zastanawiam, czy czasem nie chcę walczyć z wiatrakami. Jeśli nawet wyślę klientowi
> ścieżki które nie są wybrane jako best to w sumie i tak mi to nic nie da oprócz tego, że
> będzie miał on wszystkie prefixy.
> Jego ruch i tak zostanie skierowany przez mój router tak jak ma w tablicy routingu a nie w
> tablicy bgp więc i tak, jego pakiety będą szły do tepsy, gdzie zostaną przez tepse dropowane :(
> czy dobrze myślę?
>
>
Dlatego jeśli klient ustawi sobie np. default gw na Twój router to Ty muszisz zadbać, żeby
> W dniu 08.11.2011 12:22, MaRc pisze:
>> czasem nie tu leży problem, że begep dystrybuuje tylko najlepsze,
>> wybrane trasy?
>> jak powiedzieć quadze, żeby rozesłała mi do tego klienta wszystkie ścieżki?
>
> Tak się zastanawiam, czy czasem nie chcę walczyć z wiatrakami. Jeśli nawet wyślę klientowi
> ścieżki które nie są wybrane jako best to w sumie i tak mi to nic nie da oprócz tego, że
> będzie miał on wszystkie prefixy.
> Jego ruch i tak zostanie skierowany przez mój router tak jak ma w tablicy routingu a nie w
> tablicy bgp więc i tak, jego pakiety będą szły do tepsy, gdzie zostaną przez tepse dropowane :(
> czy dobrze myślę?
>
>
jego ruch był kierowany do odpowiedniego operatora (np. via soure routing)
MaRc
Nov 8, 2011, 7:15:36 AM11/8/11
to
W dniu 08.11.2011 13:13, Tomasz Winiarski pisze:
> Dlatego jeśli klient ustawi sobie np. default gw na Twój router to Ty muszisz zadbać, żeby
> jego ruch był kierowany do odpowiedniego operatora (np. via soure routing)
>
no właśnie. jak to zrobić w quagga?
> jego ruch był kierowany do odpowiedniego operatora (np. via soure routing)
>
Tomasz Winiarski
Nov 8, 2011, 8:08:54 AM11/8/11
to
On 08.11.2011 13:15, MaRc wrote:
> W dniu 08.11.2011 13:13, Tomasz Winiarski pisze:
>> Dlatego jeśli klient ustawi sobie np. default gw na Twój router to Ty muszisz zadbać, żeby
>> jego ruch był kierowany do odpowiedniego operatora (np. via soure routing)
>>
>
> no właśnie. jak to zrobić w quagga?
>
mogę podać przykład dla cisco - nie wiem czy zadziała z quagga:
> W dniu 08.11.2011 13:13, Tomasz Winiarski pisze:
>> Dlatego jeśli klient ustawi sobie np. default gw na Twój router to Ty muszisz zadbać, żeby
>> jego ruch był kierowany do odpowiedniego operatora (np. via soure routing)
>>
>
> no właśnie. jak to zrobić w quagga?
>
configure
ip access-list extended LISTA
permit ip 192.168.100.0 0.0.0.255 any
deny ip any any
route-map SOURCE-ROUTE permit 10
match ip address LISTA
set ip next-hop 10.10.10.1
na interfejsie do klienta dodajesz
ip policy route-map SOURCE-ROUTE
Z tego co pamiętam, to source routing dość mocno obciąża CPU routera
MaRc
Nov 8, 2011, 8:38:28 AM11/8/11
to
W dniu 08.11.2011 14:08, Tomasz Winiarski pisze:
> set ip next-hop
wielkie dzięki, to mnie nakierowało.
zrobiłem to według przykładu:
router bgp <LocASN>
neighbor 86.x.x.81 remote-as <FASN>
neighbor 86.x.x.81 route-map set-nexthop in
route-map set-nexthop permit 10
set ip next-hop 86.x.x.137
nie wywaliło błędów. zrobiłem clear. teraz, jak sprawdzić czy to zadziałało?
> set ip next-hop
wielkie dzięki, to mnie nakierowało.
zrobiłem to według przykładu:
router bgp <LocASN>
neighbor 86.x.x.81 remote-as <FASN>
neighbor 86.x.x.81 route-map set-nexthop in
route-map set-nexthop permit 10
set ip next-hop 86.x.x.137
nie wywaliło błędów. zrobiłem clear. teraz, jak sprawdzić czy to zadziałało?
Tomasz Winiarski
Nov 8, 2011, 8:52:05 AM11/8/11
to
On 08.11.2011 14:38, MaRc wrote:
> W dniu 08.11.2011 14:08, Tomasz Winiarski pisze:
>> set ip next-hop
>
> wielkie dzięki, to mnie nakierowało.
>
> zrobiłem to według przykładu:
> router bgp <LocASN>
> neighbor 86.x.x.81 remote-as <FASN>
> neighbor 86.x.x.81 route-map set-nexthop in
>
> route-map set-nexthop permit 10
> set ip next-hop 86.x.x.137
>
> nie wywaliło błędów. zrobiłem clear. teraz, jak sprawdzić czy to zadziałało?
>
kierunek - dodaj sobie jakiś secondary ip z tej klasy i ustaw jako źródło pakietu obserwując
> W dniu 08.11.2011 14:08, Tomasz Winiarski pisze:
>> set ip next-hop
>
> wielkie dzięki, to mnie nakierowało.
>
> zrobiłem to według przykładu:
> router bgp <LocASN>
> neighbor 86.x.x.81 remote-as <FASN>
> neighbor 86.x.x.81 route-map set-nexthop in
>
> route-map set-nexthop permit 10
> set ip next-hop 86.x.x.137
>
> nie wywaliło błędów. zrobiłem clear. teraz, jak sprawdzić czy to zadziałało?
>
jaką trasą opuszcza router
MaRc
Nov 8, 2011, 8:53:30 AM11/8/11
to
W dniu 08.11.2011 14:52, Tomasz Winiarski pisze:
pozdrawiam
> kierunek - dodaj sobie jakiś secondary ip z tej klasy i ustaw jako źródło pakietu obserwując
> jaką trasą opuszcza router
dzięki za pomoc.
> jaką trasą opuszcza router
pozdrawiam
MaRc
Nov 9, 2011, 3:28:48 AM11/9/11
to
W dniu 08.11.2011 14:38, MaRc pisze:
jeden z prefixów tego klient widziałem z 3 ścieżkami: przez nask, przez
tepse i bezpośrednio ze mną. Nawet do jego sieci, nexthopa miałem przez
nask i zero ruchu na jego interfejsie.
rozwiązałem to w inny sposób. zrobiłem to przez iproute według opisu
"zaawansowany routing how to" w dziale source routing.
"# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup John
32766: from all lookup main
32767: from all lookup default
# ip route add default via 195.96.98.253 dev ppp2 table John"
i to poszło i to działa.
> zrobiłem to według przykładu:
> router bgp <LocASN>
> neighbor 86.x.x.81 remote-as <FASN>
> neighbor 86.x.x.81 route-map set-nexthop in
>
> route-map set-nexthop permit 10
> set ip next-hop 86.x.x.137
Według tego przykładu tylko teoretycznie ruszyło. po zaaplikowaniu tego
> router bgp <LocASN>
> neighbor 86.x.x.81 remote-as <FASN>
> neighbor 86.x.x.81 route-map set-nexthop in
>
> route-map set-nexthop permit 10
> set ip next-hop 86.x.x.137
jeden z prefixów tego klient widziałem z 3 ścieżkami: przez nask, przez
tepse i bezpośrednio ze mną. Nawet do jego sieci, nexthopa miałem przez
nask i zero ruchu na jego interfejsie.
rozwiązałem to w inny sposób. zrobiłem to przez iproute według opisu
"zaawansowany routing how to" w dziale source routing.
"# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup John
32766: from all lookup main
32767: from all lookup default
# ip route add default via 195.96.98.253 dev ppp2 table John"
i to poszło i to działa.
Tomasz Winiarski
Nov 9, 2011, 4:25:41 AM11/9/11
to
On 09.11.2011 09:28, MaRc wrote:
> W dniu 08.11.2011 14:38, MaRc pisze:
>> zrobiłem to według przykładu:
>> router bgp <LocASN>
>> neighbor 86.x.x.81 remote-as <FASN>
>> neighbor 86.x.x.81 route-map set-nexthop in
>>
>> route-map set-nexthop permit 10
>> set ip next-hop 86.x.x.137
>
> Według tego przykładu tylko teoretycznie ruszyło. po zaaplikowaniu tego jeden z prefixów
> tego klient widziałem z 3 ścieżkami: przez nask, przez tepse i bezpośrednio ze mną. Nawet do
> jego sieci, nexthopa miałem przez nask i zero ruchu na jego interfejsie.
> rozwiązałem to w inny sposób. zrobiłem to przez iproute według opisu "zaawansowany routing
> how to" w dziale source routing.
>
> "# echo 200 John >> /etc/iproute2/rt_tables
> # ip rule add from 10.0.0.10 table John
> # ip rule ls
> 0: from all lookup local
> 32765: from 10.0.0.10 lookup John
> 32766: from all lookup main
> 32767: from all lookup default
>
> # ip route add default via 195.96.98.253 dev ppp2 table John"
>
> i to poszło i to działa.
>
>
>
>
stosując route-map na wejściu ustawiałeś next-hopa dla prefixów z neighbor 86.x.x.81
> W dniu 08.11.2011 14:38, MaRc pisze:
>> zrobiłem to według przykładu:
>> router bgp <LocASN>
>> neighbor 86.x.x.81 remote-as <FASN>
>> neighbor 86.x.x.81 route-map set-nexthop in
>>
>> route-map set-nexthop permit 10
>> set ip next-hop 86.x.x.137
>
> Według tego przykładu tylko teoretycznie ruszyło. po zaaplikowaniu tego jeden z prefixów
> tego klient widziałem z 3 ścieżkami: przez nask, przez tepse i bezpośrednio ze mną. Nawet do
> jego sieci, nexthopa miałem przez nask i zero ruchu na jego interfejsie.
> rozwiązałem to w inny sposób. zrobiłem to przez iproute według opisu "zaawansowany routing
> how to" w dziale source routing.
>
> "# echo 200 John >> /etc/iproute2/rt_tables
> # ip rule add from 10.0.0.10 table John
> # ip rule ls
> 0: from all lookup local
> 32765: from 10.0.0.10 lookup John
> 32766: from all lookup main
> 32767: from all lookup default
>
> # ip route add default via 195.96.98.253 dev ppp2 table John"
>
> i to poszło i to działa.
>
>
>
>
dlatego source-routing powinieneś wykonywać na "wjeściu" interfejsu
Oczywiście - nie zmieni Ci to nic w wysyłaniu prefixów do peera, jedynie zmieni trasę
domyślną dla pakietów trafiających w access-listę.
Oczywiście pakiet iproute2 daje radę :D
MaRc
Nov 9, 2011, 6:14:56 AM11/9/11
to
W dniu 09.11.2011 10:25, Tomasz Winiarski pisze:
> dlatego source-routing powinieneś wykonywać na "wjeściu" interfejsu
wejściu czy wyjściu? czyli powinienem to na out ??
Tomasz Winiarski
Nov 9, 2011, 6:40:07 AM11/9/11
to
On 09.11.2011 12:14, MaRc wrote:
> W dniu 09.11.2011 10:25, Tomasz Winiarski pisze:
>> dlatego source-routing powinieneś wykonywać na "wjeściu" interfejsu
>
> wejściu czy wyjściu? czyli powinienem to na out ??
>
na interfejsie sieciowym z którego dostajesz ruch klienta
> W dniu 09.11.2011 10:25, Tomasz Winiarski pisze:
>> dlatego source-routing powinieneś wykonywać na "wjeściu" interfejsu
>
> wejściu czy wyjściu? czyli powinienem to na out ??
>
MaRc
Nov 9, 2011, 7:53:19 AM11/9/11
to
W dniu 09.11.2011 12:40, Tomasz Winiarski pisze:
> na interfejsie sieciowym z którego dostajesz ruch klienta
>
ok
>
Sergiusz Rozanski
Nov 14, 2011, 2:07:08 PM11/14/11
to
Dnia 08.11.2011 Tomasz Winiarski <to...@from.elblag.pl> napisał/a:
> On 08.11.2011 12:22, MaRc wrote:
>
>> ip as-path access-list AS_GREF_OUT deny ^5617_
>> ip as-path access-list AS_GREF_OUT permit .*
>>
>> po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale niestety klient
>> otrzymuje 1/3 wszystkich prefixów.
>>
> Taka jest zasada działania protokołów routingu - routery wymieniają się najlepszymi wpisami
> ze swojej tablicy routingu - jeśli masz lepsze trasy z TPSA i je odfiltrujesz to klient
> dostanie tylko resztę prefixów. Czyli tutaj lepiej nie będzie.
>
> Możesz spróbować zmienić routing klienta za pomocą route-map
A nie prościej po prostu skoro i tak nie może lecieć przez tepse (czemu? łącze transferowe?)
> On 08.11.2011 12:22, MaRc wrote:
>
>> ip as-path access-list AS_GREF_OUT deny ^5617_
>> ip as-path access-list AS_GREF_OUT permit .*
>>
>> po zastosowaniu tego, ładnie wszystko wycina z początkiem as tespy, ale niestety klient
>> otrzymuje 1/3 wszystkich prefixów.
>>
> Taka jest zasada działania protokołów routingu - routery wymieniają się najlepszymi wpisami
> ze swojej tablicy routingu - jeśli masz lepsze trasy z TPSA i je odfiltrujesz to klient
> dostanie tylko resztę prefixów. Czyli tutaj lepiej nie będzie.
>
> Możesz spróbować zmienić routing klienta za pomocą route-map
to ustawić mu statycznie routing jego klas na nask? dwukierunkowo? Olewając w ogóle
tablicę routingu budowaną przez quagga - i szybciej i wydajniej. A co do prefiksów
to możesz pobawić się i wysłać mu tylko te oferowane przez nask z pominięciem
tepsianych - tak aby jego bgp miało szansę ustawić prawidłową trasę przez Twój
router.
Adam Przybyla
Nov 15, 2011, 2:44:39 AM11/15/11
to
Z powazaniem
Adam Przybyla
MaRc
Nov 17, 2011, 10:08:43 AM11/17/11
to
W dniu 14.11.2011 20:07, Sergiusz Rozanski pisze:
> to ustawić mu statycznie routing
tak też musiałem zrobić i działa
0 new messages