Newsgroup: it.comp.reti.cisco
Titolo: Suggerimenti Port Adapters

Ho la necessità di far attestare 4 differenti circuiti di diversi carriers
su un cisco 7206 per il quale devo ancora acquistare i relativi port
adapters.. In relazione all'esigenza di future espansioni relative alla
banda dei vari circuiti, volevo chiedere al NG se qualcuno può darmi dei
suggerimenti per scegliere gli adapters giusti che fanno al mio caso e che
rispettino le mie esigenze.. I circuiti in fibra sono i seguenti:
1 x 34 MB (con possibilità di espansione a 155 MB)
1 x 12 MB (con possibilità di espansione a 34 o 155 MB)
1 x 6 MB (con possibilità di espansione a 34 MB)
1 x 6 MB (con possibilità di espansione a 34 MB)
Non ho contattato ancora i carriers proprio per avere un'idea della spesa da
sostenere per l'acquisto dell'hardware necessario.. non sono un esperto, e
penso si sia capito abbastanza, se avete delle soluzioni alternative da
suggerirmi sono ben gradite :-)
Grazie, Riccardo

 writes:
    > Ho la necessità di far attestare 4 differenti circuiti di
    > diversi carriers 
    > su un cisco 7206 per il quale devo ancora acquistare i relativi
    > port 
    > adapters.. In relazione all'esigenza di future espansioni
    > relative alla 
    > banda dei vari circuiti, volevo chiedere al NG se qualcuno può
    > darmi dei 
    > suggerimenti per scegliere gli adapters giusti che fanno al mio
    > caso e che 
    > rispettino le mie esigenze.. I circuiti in fibra sono i seguenti:
    > 1 x 34 MB (con possibilità di espansione a 155 MB)
    > 1 x 12 MB (con possibilità di espansione a 34 o 155 MB)
    > 1 x 6 MB (con possibilità di espansione a 34 MB)
    > 1 x 6 MB (con possibilità di espansione a 34 MB)
fatti bene i conti con la capacita' del backplane del router, o ti
troverai a dover cambiare anche quello.
Pf
-- 
-------------------------------------------------------------------------------
 Pierfrancesco Caci |            System Administrator @ 
seabone.net
 
p.c...@seabone.net
 |     Telecom Italia S.p.A. - International Wholesale Svcs
     Linux paperino 2.4.18-rc1 #1 Thu Feb 14 15:55:54 CET 2002 i686 unknown

 Pf
Il 7200VXR con NPE300 o superiore offre 1,2 Gbps, suddivisi in
due bus da 0,6 Gbps, restrizione questa che limita la liberta'
di posizionamento dei PA ad alta velocita' nello chassis. Considerato
cio', i PA che servono all'autore del post potrebbero essere
PA-A3-OC3MM   1 port ATM OC3 STM1 multimode
PA-A3-E3      1 port ATM E3
PA-4T+        4 port V.35
Nel numero opportuno limitato dal budget e dal bus del 7200
Ciao
Roberto
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 > Pf
 Beh per quanto riguarda la capacita' del backplane del router penso basti
quel del 7206vxr.. per stare ancora + sicuro potrei prendere un 7500 tanto i
PA suggeritimi:
Considerato
cio', i PA che servono all'autore del post potrebbero essere
PA-A3-OC3MM   1 port ATM OC3 STM1 multimode
PA-A3-E3      1 port ATM E3
PA-4T+        4 port V.35
sono compatibili vero?
Saluti
Riccardo

 Il 7200VXR con NPE300 o superiore offre 1,2 Gbps,
Backplane speed != Routing Capacity
Ti posso dimostrare con, per esempio con il mio traffico, che con 100 
Mbps (forse meno) saturo la CPU di un NPE400....
Ciao.
-- 
  Daniele Orlandi
  Planet Srl

 Ciao.
Ripeto, un 7200VXR con NPE300 o superiore offre 1,2 Gbps, suddivisi
in due bus pci da 600Kbps, e questi sono i dati di partenza per
quantificare quantita' e tipologia di PA da configurare. Detto questo,
nessuno mette in discussione quanto tu sia bravo ad infilare porcherie
in rete.


 in rete.
Bravo... ma vedi... nei router di quella classe c'e' anche una cosa sola 
che condividono tutti i port adapters... quella cosa si chiama CPU... e 
dalla CPU dipende anche il numero di pacchetti al secondo che puoi 
ruotare e, aihme', questo e' quasi sempre il parametro piu' limitante, 
meno calcolabile e meno documentato.
Detto cio', a meno che tu non riesca ad avere traffico con dimensione 
media del pacchetto molto alta, stai certo che toccherai il limite della 
CPU ben prima di quanto tu possa saturare la banda del backplane.
Per concludere, quello che tu chiami "porcherie", altro non e' il 
traffico tipico della mia azienda... ovvero pacchetti MOLTO piccoli.
Giusto per farti un esempio, con una quarantina di Mbps, ho il 50% di 
CPU utilizzata.... ok, la crescita non e' linare... ma fai tu...
Forse ti farebbe bene leggere le brochure o ascoltare i corsi con un po' 
piu' di occhio critico...


 piu' di occhio critico...
Se i tuoi router li avessi configurati io non avresti i problemi
che hai adesso. Non mi considerare arrogante, ma 40 Mbps non possono,
e non devono, mandare la cpu al 50%. Se hai la cpu al 50% non e'
per colpa dei 40Mbps di pacchetti a 64 byte, ma per qualche altro
motivo. 
Per quanto riguarda i corsi, ne ho fatti pochi, e tantissimi anni
fa.
Le brochure poi le strappo senza neanche guardarle, la carta
patinata non va bene neanche come carta igienica.


 patinata non va bene neanche come carta igienica.
E allora, da dove vengono quei 1.3 Gbps che a nulla servono ?


 Cosa vuoi che sia ? Routing... due belle full-views e niente filtri...
Se per full-view intendi una full routing table BGP allora
ovviamente non e' routing. Ma esattamente cio' che ti
avevo detto, "qualche altro motivo". Una sessione BGP e'
un'applicazione TCP, non routing.
Se tu avessi letto la domanda dell'autore del post converresti
con me che la mia risposta e' ragionevole, tutte le altre 
considerazioni come le tue sono solo chiacchere da bar, 
sintomatiche di visioni parziali, soggettive, ingenue.
Non so quanti anni tu abbia, secondo me sei un ragazzo
giovane, in questo caso spero che tu, crescendo, acquisisca
la maturita' di comprendere che il piccolissimo mondo
che vedi alla "Planet Srl" non e' il mondo vero.
Continuiamo questo interessante contenzioso!! il NG
ultimamente e' cosi' noioso...


Roberto Piersante wrote:
 >
 > Se per full-view intendi una full routing table BGP allora ovviamente
 > non e' routing. Ma esattamente cio' che ti avevo detto, "qualche
 > altro motivo". Una sessione BGP e' un'applicazione TCP, non routing.
Il carico dei processi legati al BGP e' alto (circa 5-7% di CPU) ma
costante... non e' correlato al traffico... mentre il 50% di CPU che ti
dico io e' correlato al traffico.
La full view porta carico al routing perche' comunque aumenta la
dimensione della routing table e quindi l'individuazione
dell'interfaccia di destinazione, processo non lineare (per fortuna), ma
neanche O(1).
 > Se tu avessi letto la domanda dell'autore del post converresti con
 > me che la mia risposta e' ragionevole, tutte le altre considerazioni
 > come le tue sono solo chiacchere da bar, sintomatiche di visioni
 > parziali, soggettive, ingenue.
E' esattamente il contrario... dire "Puoi metterci 600 Mbps per BUS" e'
un'affermazione semplicistica, se non addirittura falsa... dubito che tu
riuscirai mai a far ruotare 1.3 Gbps ad un 7200 neanche nelle condizioni
piu' ideali e irreali.
 > Non so quanti anni tu abbia, secondo me sei un ragazzo giovane, in
 > questo caso spero che tu, crescendo, acquisisca la maturita' di
 > comprendere che il piccolissimo mondo che vedi alla "Planet Srl" non
 > e' il mondo vero.
Non ho paura di mettermi in gioco, sono abituato a vincere e quando mi
capita di perdere comunque ci ho guadagnato qualcosa, indi per cui, 
questa e' la parte piu' rilevante della mia config... ora tocca a te...
ip subnet-zero
no ip source-route
ip cef
!
ip multicast-routing
!
interface Loopback0
  ip address 212.212.212.2 255.255.255.255
!
interface FastEthernet0/0
  ip address 212.212.213.2 255.255.255.224
  ip pim sparse-mode
  ip route-cache flow
  ip ospf message-digest-key 1 md5 ..............
  ip ospf priority 64
  duplex full
  speed auto
!
interface FastEthernet0/1
  no ip address
  no ip proxy-arp
  ip route-cache flow
  duplex full
  speed auto
!
interface FastEthernet0/1.7
  encapsulation dot1Q 7
  ip address 212.212.216.129 255.255.255.192
  ip access-group BLABLA_OUT out
  ip pim sparse-mode
  ntp multicast
!
interface Serial1/0
  description T3-00123 Planet --> Pizzapluto for IP transit
  ip address 212.11.22.33 255.255.255.252
  ip access-group BORDER_IN in
  rate-limit input access-group 170 768000 70000 70000 conform-action 
transmit exceed-action drop
  ip route-cache flow
  framing c-bit
  cablelength 10
  dsu bandwidth 44210
  serial restart-delay 0
!
interface Serial1/1
  description T3-00124 Planet --> MIX
  ip address 212.212.212.17 255.255.255.252
  ip pim sparse-mode
  encapsulation ppp
  ip route-cache flow
  framing c-bit
  cablelength 10
  dsu bandwidth 44210
  serial restart-delay 0
!
router ospf 12565
  log-adjacency-changes
  area 0 authentication message-digest
  redistribute connected subnets
  redistribute static subnets
  network 212.212.261.2 0.0.0.0 area 0
  network 212.212.262.2 0.0.0.0 area 0
  network 212.212.262.17 0.0.0.0 area 0
  default-information originate always metric 4
!
router bgp 12565
  no synchronization
  bgp log-neighbor-changes
  bgp dampening
  network 212.212.212.0 mask 255.255.224.0
  neighbor 212.11.22.29 remote-as 12345
  neighbor 212.11.22.29 description Colt
  neighbor 212.11.22.29 prefix-list BGP_IN in
  neighbor 212.11.22.29 route-map UPSTREAM1_IN in
  neighbor 212.11.22.29 route-map UPSTREAM1_OUT out
  neighbor 212.11.22.29 filter-list 1 out
  neighbor 212.212.262.3 remote-as 12565
  neighbor 212.212.262.3 description CORE-2
  neighbor 212.212.262.3 update-source Loopback0
  neighbor 212.212.262.4 remote-as 12565
  neighbor 212.212.262.4 description MIX
  neighbor 212.212.262.4 update-source Loopback0
  neighbor 212.212.262.4 filter-list 1 out
  no auto-summary
  !
  address-family ipv4 multicast
  neighbor 212.212.262.3 activate
  neighbor 212.212.262.4 activate
  exit-address-family
!
ip classless
ip route 212.212.212.0 255.255.224.0 Null0
no ip http server
ip tacacs source-interface Loopback0
ip bgp-community new-format
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit ^.*_.*$
ip pim bidir-enable
ip pim rp-address 212.212.214.62
!
!
ip prefix-list BGP_IN description Prefixes accepted from external peers 
via BGP
ip prefix-list BGP_IN seq 5 deny 
0.0.0.0/0
 le 7
ip prefix-list BGP_IN seq 10 deny 
0.0.0.0/32
ip prefix-list BGP_IN seq 15 deny 
127.0.0.0/8
 le 32
ip prefix-list BGP_IN seq 20 deny 
10.0.0.0/8
 le 32
ip prefix-list BGP_IN seq 25 deny 
172.16.0.0/12
 le 32
ip prefix-list BGP_IN seq 30 deny 
192.168.0.0/16
 le 32
ip prefix-list BGP_IN seq 35 deny 
192.0.2.0/24
 le 32
ip prefix-list BGP_IN seq 40 deny 
224.0.0.0/8
 le 32
ip prefix-list BGP_IN seq 45 deny 
217.29.66.0/23
 le 32
ip prefix-list BGP_IN seq 200 permit 
0.0.0.0/0
 le 26
ip prefix-list BGP_IN seq 210 deny 
0.0.0.0/0
 le 32
!
ip access-list extended BORDER_IN
  deny   ip 212.212.212.0 0.0.31.255 any log-input
  permit ip any any
ip access-list extended BLABLA_OUT
  permit tcp any any established
! etc etc 99% of traffic is allowed by the second rule
  deny   tcp any any log-input
access-list 170 remark All ICMP traffic
access-list 170 permit icmp any any


 questa e' la parte piu' rilevante della mia config... ora tocca a te...
E' affascinante questa tua interpretazione del lavoro nel campo
del networking, duelli alla "mezzogiorno di fuoco", sfide alla
"topgun", partite di biliardo come in "lo spaccone"...
"lo spaccone", non so se lo conosci, e' quel film con Paul Newman
dal quale hanno tratto il remake "Il colore dei soldi", imparagonabile
all'originale.
Comunque, cerchiamo di rendere costruttivo questo confronto/scontro:
La tua configurazione dice poco, se non e' completa, e corredata di
sh ver
sh proc cpu
sh proc mem
sh interfaces switching (cosi' capiamo chi gira i pacchetti...)
sh mem summary
Vedo che usi Netflow, fate veramente accounting e billing, 
oppure serve a fare la classifica dei clienti che vanno sui
siti porno...?


 siti porno...?
L'accounting/billing lo faccio su un altro router. Su questo mi serve 
per identificare la provenienza dei DoS attacks. Io non faccio 
classifiche dei gusti dei miei clienti.... non ho parole....
Ciao.



Adesso se uno spende un tot per cablare tutti gli apparati presenti in una
lan a 1 Gbps perchč poi deve trovarsi
con il 60-70% in meno di quello che si aspetta e per di piů sul nodo piů
importante?
Spero questa sia una questione che riguarda solo i 72xx.. perchč se cosě
fosse mi sbarazzerei immediatamente del
7206VXR acquistando un bel 7507 con RSP8 tanto per cominciare, ovviamente
solo se quest'ultimo e il processore
gigabit associato a un convertitore 1000BASE-SX mi dassero effettivamente
quello che mi aspetterei..
Ciao

 classifiche dei gusti dei miei clienti.... non ho parole....
Beh, in questo caso posso solo suggerirti di eliminare il
netflow completamente, ed utilizzare CEF.
Siamo sicuri che Riccardo ha bisogno di netflow per "identificare
la provenienza dei DoS attacks", e deve quindi dotarsi di un
7600 o un 12000 per un PA OC3 ed un paio di E3, e non vedere
cosi' la %di CPU delle schede sopra 40?
Se i tuoi router li avessi configurati io ovviamente non avrei
configurato netflow switching per individuare la provenienza dei
DoS attacks, c'e' qualche metodo piu' intelligente per farlo.
Per concludere, l'affermazione "Il 7200VXR con NPE300 o superiore
offre 1,2 Gbps" non e' disinformazione, altrimenti dovresti
considerare disinformazione anche la scritta "100Mbps" sulle
schede Fast Ethernet.


 Spero questa sia una questione che riguarda solo i 72xx.
Il 7200 e' per una certa fascia di banda... se hai bisogno di un router 
che routi agevolmente 1 Gbps, ti devi orientare su altri prodotti.
 > perchè se così fosse mi sbarazzerei immediatamente del 7206VXR 
acquistando
 > un bel 7507 con RSP8 tanto per cominciare
Non risolveresti un gran che'... il 7500 e' migliore per ruotare tra 
molte reti, ma le singole VIP incorrono in limitazioni piu' o meno 
analoghe al 7200.
Devi orientarti su i cosiddetti "Layer 4" switches che altro non sono 
che routers che si avvalgono di ASICs per effettuare le operazioni di 
routing, analogamente a come avviene per gli ethernet switches anche se 
con molta piu complessita'.
Ciao!


 schede Fast Ethernet.
No, dire "Con le FastEthernet offrono 12.5 MB/s" sarebbe disinformazione.


 neanche fare un billing accurato...
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm
Per il 7600, come per i 6500, c'e' l'MLS NDE, ma qui e' colpa di 
cisco che gli ha dato lo stesso nome marketing di netflow.
 
Ti segnalo inoltre questo link:
http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm
"NetFlow is an input side measurement technology which should be
deployed
on appropriate interfaces"


 quello che mi aspetterei..
La PA-GE+ del 7500 e' commercializzata con 800 Mbps nominali,
io sinceramente non ne ho comunque mai vista una sopra 100/200 Mbps,
questo perche' la rete dietro non riusciva a riempirla.


 on appropriate interfaces"
Certo... infatti lo uso dove mi serve... saranno cacchi miei se e dove 
voglio usarlo ? Tanto il punto e' l'utilizzazione della CPU e il NetFlow 
non me la sta modificando...
BTW, aspetto ancora qualche consiglio su come ridurre drasticamente la 
CPU del mio router, come da te anticipato.....!!!!!


 non me la sta modificando...
Il fatto che tu l'abbia configurato su tutte le interfacce
probabilmente vuol dire che da tutte le interfacce hai traffico
potenziale in ingresso da classificare (accounting o DoS nel tuo caso),
e questo vuole anche dire che probabilmente l'hai configurato sul
router sbagliato, o sulle interfacce sbagliate (a meno che
tu non ti aspetti DoS attacks anche dalla tua rete interna).
Se configuri un router senza seguire le buone norme probabilmente
hai un motivo valido strutturale, ma poi non puoi pretendere che
il comportamento del tuo apparato possa essere considerato
tipico e generalizzato. 
 
In definitiva, vorrei sottolineare un punto, il netflow, anche solo
come switching, definitivamente aumenta le risorse (CPU e MEM), con
o senza CEF abilitato, della macchina dove gira. Mi era gia' capitato,
e' una questione nota, ho gia' provato a trovarti qualche link, ora
provo con questo che ho ritrovato nei bookmark:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite.htm#xtocid2867965
Si', lo so e' una RSP2, ma il concetto e' che mantenendo un
no-drop-rate di 70 Kpps, la CPU senza netflow e' al 42%, con
netflow switching al 60%, e netflow switching + export al 65%.
L'esempio poi considera pacchetti da 512, nel tuo caso, immagino
tutte http get piccole dovrebbe essere ancora peggio.


 wrote in message
news:e1020c41b3436b531b9...@mygate.mailgate.org...


 come switching, definitivamente aumenta le risorse (CPU e MEM)
No, se usato bene le riduce parecchio (vedi sopra), quindi questa e' da 
considerarsi una baggianata.
Non hai risposto alle altre domande.


 fidarti... altrimenti siamo qui a prenderci in giro...
Hai ragione tu, mi sono fidato dei miei casi personali ed ho
interpretato in modo conseguentemente parziale la documentazione
in merito.
Scusa se ho assunto un ingiustificato tono presuntuoso.
