Newsgroup: it.comp.reti.cisco
Titolo: traffico di ritorno BGP

Ciao a tutti,
qualcuno ormai conosce bene la mia situazione!
(sono uno spacca...... di quelli atomici) ma qui i piani alti spingono e
chiedo aiuto a voi!
allora,
sono (credo) finalmente riuscito a dire al traffico bgp che mi interessa di
prendere uno dei miei 2 peer in base alle route map, adesso finalmente tutto
il traffico per telecom esce da fastweb e l'altro traffico esce da e-planet,
il problema adesso si ritrova al ritorno, non riesco in nessun modo a far si
che il traffico che esce da fastweb verso telecom rientri da fastweb, posso
scrivere qualche comando magico per cui riesca a dare un costo molto alto al
ritorno di quei pacchetti verso e-planet di modo che il traffico rientri da
fastweb? non dico che voglio perfettamente bilanciare questo traffico perkč
so che č quasi impossibile, ma mi piacerebbe riuscire a dargli un minimo di
preferenze,
grazie a chiunque mi dia una risp
ciao
Francesco

 fastweb?
A farlo puoi farlo, basta che inserisci una route map in uscita da eplanet 
che prependa il tuo path un 3 o 4 volte. In questo modo il path preferito 
sarà quasi sempre quello di fastweb. Purtroppo il giochetto non funziona 
sempre, in quanto parecchi provider usano, come te, la local preference per 
alcune destinazioni, bypassando il tuo prepending. Ma è già qualcosa...
Esempio:
route-map peer_out permit 10
 match ip address prefix-list ourpref
 set as-path prepend tuoAS tuoAS tuoAS tuoAS
la riga match ip address prefix-list prefix è opzionale, ma come ti ho già 
detto è meglio filtrare ovunque puoi, male di certo non fà.
-- 
Ciao!
]\/[arco

 ]\/[arco

 mondo del BGP è cambiato!! non cade più niente :)
ehhehe! Grande cosa la soft-reconfiguration, sì! ;)
-- 
Ciao!
]\/[arco

 ha scritto nel messaggio
news:Xns9543669F4F...@130.133.1.4...


 ha scritto nel messaggio
news:Xns9543669F4F...@130.133.1.4...


 credo proprio che sia normale vi faccio vedere
No guarda, normale non è... in una topologia loop free, dovresti vedere la 
full table da entrambi gli eBGP e anche dall'iBGP... ho visto che hai 
configurato il next-hop-self anche sull'eBGP, non vorrei che creasse dei 
loop... pure il multihop a 5 sull'eBGP fastweb, sei sicuro che ti serva? 
-- 
Ciao!
]\/[arco

 ha scritto nel messaggio
news:Xns9543B4276F...@130.133.1.4...


 c'è tiscali! 
Ci fai vedere la routemap che hai applicato?
Non è che stai facendo il prepend di TUTTI i prefissi? In questo caso, 
ePlanet diventerà solo un backup di fastweb, di traffico non ne ritornerà 
mai... dovresti applicare la routemap con un match as-path come hai fatto 
per la local preference!
-- 
Ciao!
]\/[arco

 multihop non ho bene idea di cosa siano
Ti conviene capire le modifiche che fai, altrimenti non avrai mai la 
sicurezza di sapere cosa stà succedendo...
Dal sito Cisco:
Q. In eBGP sessions, which IP address is sent as the next hop?
    A. In eBGP peering, the next hop is the IP address of the neighbor 
that announced the route. However, when the route is advertised on a 
multi-access media (such as Ethernet or Frame Relay), the next hop is 
usually the IP address of the router interface connected to that media, 
which originated the route. Refer to the BGP Nexthop Attribute of BGP 
Case Studies for a more detailed explanation.
Il next-hop-self quindi NON è necessario, in quando le tue rotte vengono 
annunciato al neighbor già con l'IP della tua interfaccia come next hop. 
Se ti serve, vuol dire che probabilmente è sbagliata la configurazione 
della punto punto... E' necessario invece nell'iBGP, se non hai un 
protocollo di routing interno che ti annunci le rotte verso i neighbor.
Per il multihop, se il tecnico Fastweb ti ha detto di metterlo a 5, vuol 
dire che non ha una connessione diretta verso di te, ma ci arriva 
attraverso altri 5 router. Mi sembra oltremodo strano... prova a fare un 
traceroute dalla tua rete al loro neighbor, e vedi quandi hop fà.
Inoltre, ma forse questo è un pò tardi per dirtelo, controlla come 
arrivano ePlanet e Fastweb da te. Spesso ePlanet prende il local loop da 
Fastweb, il che significa che in alcune circostanze, se cade FW ti cade 
pure eP...
-- 
Ciao!
]\/[arco

 ]\/[arco

 ]\/[arco

 nell'altra route map che è sempre applicata sull'acces list 15
Se annunci l'intera /20, puoi influenzare il traffico solo dell'intera 
/20. Splitta l'annuncio su più classi, e solo allora potrai dare 
attributi diversi a classi diverse.
-- 
Ciao!
]\/[arco

 e-planet 
Questo mi conferma che ci deve essere qualche problema 'subdolo' da qualche 
parte... ricontrolla bene la config... il next-hop di fastweb coincide con 
il tuo neighbor? Hai l'indirizzo di una /30 sull'ethernet di fastweb, o 
altro? Dato che sembra ci siano più router di mezzo direi che l'indirizzo 
del neighbor non è nella subnet della tua fastethernet. Hai una statica che 
punta a quell'indirizzo?
-- 
Ciao!
]\/[arco

 ]\/[arco
Ancora Grazie, se mai dovessimo conoscerci, mi tocca pagarti una cena!

 ]\/[arco

 risolto l'arcano?
Forse... se non ti è troppo complicato, riesci a mandarmi la config 
completa di tutti e due i router? Se preferisci tenere gli IP nascosti fai 
pure, ma preserva nel giuste netmask, e soprattutto nascondili in modo che 
non sembrino tutti uguali, quindi niente x.x.x.x dappertutto, please.
Ho il sospetto che fastweb ti inietti delle route con dei loop. Forse 
prendono il transito da ePlanet, visto che sono arrivati dopo, e non hanno 
configurato bene i filtri, è capitato anche a me una volta con un cliente 
che stava letteralmente impazzendo per risolvere la cosa! ;)
Inoltre l'output di uno sh ip bgp eBGPAddress advertised-routes su ambedue 
i peer eBGP potrebbe essere utile. Lo sarebbe ancora di più se riuscissi a 
farlo anche su ogni iBGP, ed anche uno sh ip bgp eBGPAddress routes e 
received-routes sugli eBGP. Saraà una mail di qualche mega, ma almeno ci 
sarà la situazione completa! ;)
-- 
Ciao!
]\/[arco

 ha scritto nel messaggio
news:Xns954486EE92...@130.133.1.4...
