ARGOMENTO:

Ciao Virgilio..vorrei che tu mi aiutassi nel risolvere un dubbio che mi attanaglia da diverse notti..tanto da non farmi dormire in modo tranquillo..
Durante la prima topologia della lezione Bgp,quella per intenderci con gli A.S 65456 e A.S 65123,
dopo tutti i passaggi di neighbor e protocolli IGP(OSPF)..se dal router R1 do il comando:
R1=ping 172.16.0.4 ossia la loo0 di R4,il ping va a buon fine..perchè dopo aver eseguito per filo e per segno le configurazioni come da lezione non vorrei che per quell'errore che ti avevo segnalato,forse un probabile bug,io debba credere di non aver capito nulla delle problematiche relative al protocollo...e questo mi spaventerebbe molto..visto che ci ho passato due giorni interi..
Grazie della tua pazienza.

Ecco l'errore
Nov 30 10:53:00.339: %BGP-5-ADJCHANGE: neighbor 10.2.4.2 Down BGP Notification sent
R4#
*Nov 30 10:53:00.343: %BGP-3-NOTIFICATION: sent to neighbor 10.2.4.2 1/1 (header synchronization problems) 0 bytes
R4#
*Nov 30 10:53:05.243: %BGP_SESSION-5-ADJCHANGE: neighbor 10.2.4.2 IPv4 Unicast topology base removed from session  BGP Notification sent

Ciao Matteo,
ti ringrazio della domanda, il problema che vedi è piuttosto anomalo e probabilmente dipende dal router che stai utilizzando o dal carico di CPU della tua macchina.
La cosa che non capisco esattamente è: il tuo problema è che il ping va a buon fine?

Per aiutarmi a capire meglio, puoi dirmi

versione IOS del router che utilizzi
qual'è il carico di CPU della macchina
Tabella di routing di R1
Tabella BGP di R1

Ho provato a usare il (C2691-ADVENTERPRISEK9_SNA-M), Version 12.4(13b)..ora mi filtra almeno le prefix che non mi filtrava da R4 verso gli altri router..è già un passo avanti..
tabella di routing di R1:
172.16.0.0/32 is subnetted, 8 subnets
B 172.16.0.4 [200/0] via 10.2.4.4, 00:20:04
B 172.16.1.4 [200/0] via 10.2.4.4, 00:20:04
B 172.16.2.4 [200/0] via 10.2.4.4, 00:20:04
C 172.16.1.1 is directly connected, Loopback1
C 172.16.0.1 is directly connected, Loopback0
B 172.16.0.2 [200/0] via 10.1.2.2, 00:20:29
C 172.16.2.1 is directly connected, Loopback2
B 172.16.0.3 [200/0] via 10.1.3.3, 00:20:29
10.0.0.0/24 is subnetted, 5 subnets
C 10.1.3.0 is directly connected, FastEthernet0/1
C 10.1.2.0 is directly connected, FastEthernet0/0
O 10.2.3.0 [110/11] via 10.1.3.3, 00:04:31, FastEthernet0/1
[110/11] via 10.1.2.2, 00:04:31, FastEthernet0/0
O 10.2.4.0 [110/20] via 10.1.2.2, 00:04:33, FastEthernet0/0
O 10.3.4.0 [110/20] via 10.1.3.3, 00:04:33, FastEthernet0/1


tabella bgp di R1:
*> 172.16.0.1/32 0.0.0.0 0 32768 i
*>i172.16.0.2/32 10.1.2.2 0 200 0 i
*>i172.16.0.3/32 10.1.3.3 0 100 0 i
*>i172.16.0.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.1.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.2.4/32 10.2.4.4 0 200 0 65456 ?



Ho aggiunto anche un link fisico tra R2 e R3..ma niente..non riesco a pingare
R1#ping 172.16.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
...

R4#ping 172.16.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/57/88 ms

R1#show process cpu history

R1 12:45:23 AM Friday Mar 1 2002 UTC



22222
100
90
80
70
60
50
40
30
20
10
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
CPU% per second (last 60 seconds)


7 1 4
1251119112121311111111122132 1336 7833 21 1
100
90
80 *
70 *
60 *
50 *
40 * *
30 * *
20 * *
10 # * * * ** *
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
CPU% per minute (last 60 minutes)
* = maximum CPU% # = average CPU%




100
90
80
70
60
50
40
30
20
10
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%

L'errore iniziale è scomparso.. come quello delle prefix...quindi posso affermare quasi con certezza che si trattava di un bug per quella versione di stw...resta il problema del ping...se pingabile???

Bene che tu abbia risolto il problema, per il futuro ti consiglio di utilizzare 3750 o 7200 che sono macchine su cui ho più esperienza in dynamips.

Ad ogni modo ipotizzo che il problema stia nel traffico di ritorno, sei certo che R4 conosca la strada per la 10.1.2.0/24?

Attenzione..ho risolto solo il problema delle prefix e l'errore:
Nov 30 10:53:00.339: %BGP-5-ADJCHANGE: neighbor 10.2.4.2 Down BGP Notification sent
R4#
*Nov 30 10:53:00.343: %BGP-3-NOTIFICATION: sent to neighbor 10.2.4.2 1/1 (header synchronization problems) 0 bytes
R4#
*Nov 30 10:53:05.243: %BGP_SESSION-5-ADJCHANGE: neighbor 10.2.4.2 IPv4 Unicast topology base removed from session BGP Notification sent
che mi era proprio causato usando un roter con stw c7200-advipservicesk9-mz.122-33.SRE3.EXTRACTED.bin..
Se R4 non avesse il traffico di ritorno non riuscirei neppure a pingare..
Purtroppo per me il tanto atteso R1=ping 172.16.0.4 resta un miraggio..ossia mi da irrangiungibile..mentre durante la prima lezione BGP,parte seconda,alla fine tu concludi con un ping positivo...ecco l'ultimo comando che dai:
R4=traceroute 172.16.0.4 source loo0
L'ultima prova che potrei fare è cambiare ulteriormente stw..provando con un 375o..come mi consigli tu..ma non lo trovo in download..

Forse hai ragione tu...ma il ping non dovrebbe fallire allora..da R4 verso R1..ai posteri l'ardua sentenza..

Aggiunto link tra R2 e R3 + neighbor tra i ripsettivi router..
R1#show ip bg
R1#show ip bgp
BGP table version is 21, local router ID is 172.16.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.1/32 0.0.0.0 0 32768 i
*>i172.16.0.2/32 10.1.2.2 0 200 0 i
*>i172.16.0.3/32 10.1.3.3 0 100 0 i
*>i172.16.0.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.1.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.2.4/32 10.2.4.4 0 200 0 65456 ?


R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 8 subnets
B 172.16.0.4 [200/0] via 10.2.4.4, 00:06:43
B 172.16.1.4 [200/0] via 10.2.4.4, 00:06:43
B 172.16.2.4 [200/0] via 10.2.4.4, 00:06:43
C 172.16.1.1 is directly connected, Loopback1
C 172.16.0.1 is directly connected, Loopback0
B 172.16.0.2 [200/0] via 10.1.2.2, 00:06:27
C 172.16.2.1 is directly connected, Loopback2
B 172.16.0.3 [200/0] via 10.1.3.3, 00:11:39
10.0.0.0/24 is subnetted, 5 subnets
C 10.1.3.0 is directly connected, FastEthernet0/1
C 10.1.2.0 is directly connected, FastEthernet0/0
O 10.2.3.0 [110/11] via 10.1.3.3, 01:03:47, FastEthernet0/1
[110/11] via 10.1.2.2, 01:03:47, FastEthernet0/0
O 10.2.4.0 [110/20] via 10.1.2.2, 01:03:49, FastEthernet0/0
O 10.3.4.0 [110/20] via 10.1.3.3, 01:03:50, FastEthernet0/1



R1#ping 172.16.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Ciao Matteo,
non avevo capito quale fosse il problema.

Se ho ben compreso R1 riesce a pingare la 172.16.0.4 invece tu ti aspetteresti che questo ping debba fallire.

E' per me molto difficile capire a quale punto della prima lezione ti riferisci e quale fosse il problema specifico visto che durante le lezioni abbiamo cambiato molte volte la configurazione.

Tuttavia provo a intuire a cosa ti riferisci, credo che il problema fosse che R1 nonostante ricevesse la 172.16.0.4 tramite BGP non poteva installarla in tabella in quanto la 10.2.4.0 non era stata iniettata in OSPF e quindi non riusciva a risolvere in next hop. Se ti riferisci a quel punto, il problema è solo che tu invece hai annunciato quel link in OSPF e quindi R1 riesce a risolvere il next hop.

Se invece ti dovessi riferire ad un punto differente della lezione, ti chiedo la cortesia di indicarmi il minuto della registrazione così riandandolo a guardare riuscirò ad indicarti quale sia la differenza di config tra il tuo lab e quello di quel punto della lezione.

Tieni duro che riusciremo a spuntarla

Si..è difficile spiegarlo per email..in laboratorio probabilmente ci avresti tenuto qualche secondo a risolvere il problema...
Il mio problema è proprio su R1..non riesco a capire perchè il ping fallisce...ecco quanto esce:
R1#ping 172.16.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Mentre nella tabella BGP la 172.16.0 4 viene enunciata come risolvibile:


R1#show ip bgp
BGP table version is 21, local router ID is 172.16.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.1/32 0.0.0.0 0 32768 i
*>i172.16.0.2/32 10.1.2.2 0 200 0 i
*>i172.16.0.3/32 10.1.3.3 0 100 0 i
*>i172.16.0.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.1.4/32 10.2.4.4 0 200 0 65456 ?
*>i172.16.2.4/32 10.2.4.4 0 200 0 65456 ?

Sia nella tabella di routing:

R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/32 is subnetted, 8 subnets
B 172.16.0.4 [200/0] via 10.2.4.4, 00:41:02
B 172.16.1.4 [200/0] via 10.2.4.4, 00:41:02
B 172.16.2.4 [200/0] via 10.2.4.4, 00:41:02
C 172.16.1.1 is directly connected, Loopback1
C 172.16.0.1 is directly connected, Loopback0
B 172.16.0.2 [200/0] via 10.1.2.2, 00:40:46
C 172.16.2.1 is directly connected, Loopback2
B 172.16.0.3 [200/0] via 10.1.3.3, 00:45:58
10.0.0.0/24 is subnetted, 5 subnets
C 10.1.3.0 is directly connected, FastEthernet0/1
C 10.1.2.0 is directly connected, FastEthernet0/0
O 10.2.3.0 [110/11] via 10.1.3.3, 01:38:06, FastEthernet0/1
[110/11] via 10.1.2.2, 01:38:06, FastEthernet0/0
O 10.2.4.0 [110/20] via 10.1.2.2, 01:38:11, FastEthernet0/0
O 10.3.4.0 [110/20] via 10.1.3.3, 01:38:11, FastEthernet0/1

Anche il next-hop della 172.16.0.4 è raggiungibile da IBGP..come dicevi pocanzi..

Come ti dicevo mettendo insieme i pezzi, si capisce che c'è un problema sul traffico di ritorno.
R4 conosce la 10.1.2.0/24? Il fatto che pinghi 172.16.0.1 non vuol dire che conosca il link tra R1 e R2

Si..la soluzione era a portata di mano..non c'è peggior cieco...
Mi sopravvalutavo..pensavo di averlo capito bene..ma sicuramente qualche dettaglio mi è sfuggito..e non da poco..
Grazie Virgilio..il traghettatore BGP!