IPv4 -- Zanimljiv Tekst

[Paul Rendek, RIPE NCC]

Dear Colleagues,

There have been press articles posted over the past year that make
statements about the remaining pool of IPv4 address space. A recent article
states there is a shortage and that Internet Protocol Numbers will run out
some time in the year 2005.

The Regional Internet Registries (RIRs) do not themselves make predictions
about when the remaining IPv4 address space will be depleted. They do,
however, report on the rates of RIR allocation of IPv4 address space and on
the state of the remaining pool of IPv4 address space.

The information provided in these RIR reports makes it apparent that many
of the recent claims regarding IPv4 address space shortage are speculative
and are not based on authoritative, publicly available statistics.

IPv4 Address Space: Current Statistics
============================
The global pool of IPv4 addresses is administered by the Internet Assigned
Numbers Authority (IANA), which allocates address blocks to Regional
Internet Registries (RIRs) as they are required. The IPv4 allocation unit
in this case is the "/8 block", equivalent to approximately 16 million
addresses. It should be noted that as of 30 June 2003 the global pool of
IPv4 address space contained 91 of these blocks for this purpose.

The RIRs report on statistics regarding IPv4 allocation on their respective
web sites and present a "Joint Statistics" report at each of the RIR
meetings and at other Internet industry meetings several times yearly. This
information is publicly available and provides the most up-to-date
statistics on rates of IPv4 allocation. The most recent presentation on
this subject can be found at:

http://www.ripe.net/rs/statistics/resource-status-200310.pdf

This report states that the RIRs have collectively allocated 19.59 /8
equivalents in the four and a half years between January 1999 and June
2003. It also identifies that there are 91 /8 equivalents held by the IANA
in reserve for future allocation by the RIRs.

Based on today's total global allocation rate of approximately 4.25 blocks
per year in 2002, or 5.5 blocks in 2001, and the remaining pool of 91
blocks held by IANA, it is unrealistic to assume that there is an imminent
shortage in the IPv4 address space. Even allowing for a dramatic increase
in address consumption rates, it is highly probable that IPv4 address space
will last well beyond the two years predicted by some.

IPv4 Address Space: Allocated Globally According to Regional Needs
==================================================
The RIRs are not-for-profit membership organisations dedicated to providing
neutral and fair Internet resource distribution to their members, while
ensuring the conservation and aggregation of IPv4 address space. The IANA
policies for allocation of IPv4 address blocks to the RIRs are applied
fairly and are based purely on the documented need for address space.

When IPv4 address space finally "runs out" this will occur at the global
level, leaving each region with a relatively small pool of addresses
remaining to be allocated. It has been suggested that Asia will experience
an IPv4 address shortage before other regions. This is simply not true.
This is because addresses are distributed in a co-ordinated fashion from a
single global pool, and there is no system whereby that pool is exclusively
divided among, or pre-allocated to, different countries or regions. Through
the current system of address administration, IP addresses are allocated
according to immediate need wherever that need is demonstrated and it is
simply not possible for isolated "shortages" to exist.

As has been done in the past, the RIRs will continue to report regularly on
the registration and allocation rates of Internet Protocol Numbers, and
will work closely with the IANA to ensure the efficient management of the
remaining IPv4 address space.

RIR Statistics:
==========
APNIC http://www.apnic.net/info/reports/index.html
ARIN http://www.arin.net/statistics/index.html
LACNIC http://www.lacnic.net/en/est.html
RIPE NCC http://www.ripe.net/ripencc/mem-services/registration/statistics/

Raw Data/Historical RIR Allocations:
==========================
http://www.aso.icann.org/stats/index.html
http://www.iana.org/assignments/ipv4-address-space

The Internet Number Resource Status Report, prepared jointly by the four
RIRs, provides up-to-date statistics on rates of IPv4 allocation. This
presentation is available at:
http://www.ripe.net/rs/statistics/resource-status-200310.pdf


Cheers,

Paul Rendek
Head of Member Services and Communications
RIPE NCC

---

Drugim rečima, nema ništa od najavljivanog nestanka ipv4 adresnog prostora, barem ne u skorije vreme (koje se meri sa više godina). Ovo će još odužiti uvođenje ipv6 utopije :)

ipv6 utopije ???


pff ..

---

Pa shvatili ljudi da je lakše racionalnije iskoristiti 91x16mil nepodeljenih ip blokova i ko zna koliko neiskorišćenih adresa u ovima koji su već podeljeni, nego da se sav softver prepisuje da radi sa ipv6. Ok doći će i dan za to, ali izgleda da nije tako blizu zato što u stvari i nema pravih razloga za to još uvek.

Dobar deo programa je vec ipv6 enabled. Dovoljan deo da bi svi ostali programi mogli da rade preko 4to6.
Koristeci ipv6 kao transport za tunelovani ipv4 saobracaj bi ustedelo dodatne milone ipv4 ( ipv5? ) adresa za ipv4 ovisnike i zastareli software koji se vise ne razvija a jos uvek je u upotrebi.

---

pa nece ni biti nekog generalnog prelaska... Ali sigurno je da ce 6bone rasti i rasti... evo verat je vec uveo neki pristup preko v6. Nemoze se josh uvek prelaziti pogotovo zato sto samo win XP SP1 i server 2003 pruzaju podrsku za ipv6. Ako uzmemo da je 70% korisnika koristi XP, od toga 20% ima SP1 i od toga je 0.0001% instaliralo IPv6(za koji jos uvek ne postoji GUI vec se radi preko CMD-a) dolazimo do zakljucka da ce IPv6 uzeti neki delic tek kada izadje Longhorn koji ce ga verovatno imati instaliranog by default.

---

Windows podrška za IPv6 je potpuno irelevantna kao faktor za prelazak na IPv6 iz prostog razloga što osnovni razlozi za prelazak na IPv6 uopšte ne leže na "obroncima" Interneta, već njihovom kakvom-takvom centru. Čisto kao ilustracija:



Poslednji broj u ispisu je broj aktivnih ruta u globalonj routing tabeli. Koliko to memorije zauzima u jednom ruteru, imaš u tekstu iznad. Ovo je ruter koju punu tabelu prima samo od jednog "komšije" (neighbor). U slučaju rutera sa više komšija, situacija je još gora.

Jedna od osnovnih ideja iza IPv6 je da se drastično smanji broj ruta u koru Interneta. Još jednom, Windows kao faktor tu ne egzistira previše.


Marko.

---

To bas i nije nesto strasno.. evo ti slucaj sa dve full tabele i vise konekcija sa po manje :)

Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 630CC240 183713216 131000344 52712872 45536784 45458572
I/O 20000000 33554432 420516 33133916 32186240 32338364
I/O-2 E000000 33554512 3980336 29574176 29574176 29571260

Za BGP je otislo oko 35M, a gde se zametnu ostalih 95 ?:))) Nije problem u BGP tabelama vec u arhitekturi CISCO router-a, nepostojanju ASIC kola, glupavog hardverskog resenja i ogranicavanja kolicine memorije. CISCO nazalost vecinu stvari radi u softveru. U svakom slucaju povecas memoriju i ne brines... u core-u mreze cisco izbacis, stavis router sa 2GB i zaboravis.... :))

Inace:

#sh memory processor allocating-process totals

Allocator PC Summary for: Processor

PC Total Count Name
0x609C8B70 24112844 366 IP single NDB
0x605FA178 21146016 628 CEF: one path <- fast switching, cist hardware :>
0x60C3B0F0 15976668 243 IPv4 Unicast n
0x60C3AF84 15282676 233 IPv4 Unicast p
0x609CBDCC 10769716 164 IP RDB Chunk
0x60C0B86C 9982756 152 BGP battr chun
0x605FA288 8442420 256 IP mtrie node
0x60C3B40C 4155424 126 BGP (0) attr
...

CEF i fast switching nisu isto, za početak. U svakom slučaju i jedan i drugi sa procesom "rutiranja" (u smislu razmene ruta) nemaju puno veze. Istina, distributed CEF je zgodna stvar, ali nije podržana na srednjim platformama. Drugo, nepostojanje ASIC kola u Cisco ruterima je samo delimično tačno. 7500 i jači (12000 GSR, recimo) imaju ASIC kola. Ti ruteri, kao i 3550/3750 switchevi implementiraju CEF u hardveru. 7200 i 7200VXR (u odsustvu boljeg prevoda, ono VXR je skraćeno za very expensive router), na žalost nemaju, a daleko su najčešći kod srednjih i malih porovajdera kao edge ruteri, vezani na internet "core". Istina, NSE-1 i jači procesori rešavaju problem brzine (mada ni NPE-400 nije za bacanje) koristeći CEF, pa makar i u sofveru. Probaj na tom ruteru da kažeš "no ip cef" -- dobićeš gomilu memorije. Uporedi iskorišćenost procesora i performanse switchinga posle toga. Što se mene tiče, CEF može da troši koliko hoće memorije :-).

Ono na šta sam ja hteo da skrenem pažnju je količina ruta, ne Cisco arhitektura. Baš par minuta posle nego što sam poslao poruku, setio sam se da imam jedan ruter koji prima dve pune tabele. To je bilo još dodatnih 10MB. Meni uopšte nije teško da zamislim BGP ruter sa 10-15 neighbora. Da prostiš, to nije malo, bez obzira na cenu memorije.

Drugo, na isti problem sa BGP tabelama kukaju i ljudi sa ne-Cisco (čitaj: Juniper) opremom. Probaj na svom ruteru "sh ip bgp | i /25", recimo. Šta će to đubre unutra? :-)

Ehm, udaljih se ja od teme.


Marko.

---

Šta ti imaš protiv /25 ruta? :)

Sigurno su tu da bi rutiranje bilo EFIKASNIJE. Možda je ta mreža izdvojena iz svog superneta, pa se bolje dolazi do nje nekim drugim putem. U stvari sigurno je to jer bi sumarizacija bila odrađena i ne bi postojala ova specifičnija ruta da je putanja do te mreže ista.

Forwarding se realizuje preko CEF-a sto ti se svede na isto:) Kada kazes no ip cef, dobices rasulo sve dok ne ukljucis flow cache na interfejsima, posle toga u principu 10% losije perfomanse sto se procesora tice, a memorije kolko hoces (bar u mom slucaju) :)
dCEF je zgodna stvarcica, ali i dalje se gusi, opet iz mog iskustva :) Pored toga za razliku od tog navedenog 'junipera' obican GSR nema razdvojen forwarding i control plane, to bi trebalo da su (opet delimicno) odradili tek u verzijama 12400 koje su novijeg datuma... A sto se memorije tice, bar kod junipera nije problem da nakrcas 2GB ako ti treba :) i nije skupo :)

I dalje tvrdim, losa arhitektura.... uostalom... ethernet kartice sa amd chipom od 0.5 eura im kostaju ko da su ih radili sa dijamantima :) Odvratno :)

Sto se kolicine routa tice, tesko da ce biti nekih vecih problema sve do 200k :) a za /25:) Niko ti ne brani prefix filter, automatski ces se resiti svih gluposti :) Mnogi to rade :)

p.s. kada toliko volis CEF, probaj da podignes 20-tak tunela sa udaljenim lokacijama, pa ces da vidis sta su perfomanse CEF-a:)
recimo, ne funkcionise kada su paketi fragmentirani i zavrsavaju na routeru :)

a da ti ne kazem kakva iskustva imaju provajderi koji rade SMIN:)) svaki paket koji udje obradjuje procesor... evo da pogledas malo :)) Sto mislis koliko treba truda da ubijes router koji ovako radi ?:)

Switching path Pkts In Chars In Pkts Out Chars Out
Processor 62691798 1116273743 732006 75289592
Route cache 0 0 26494580 2151549808
Total 62691798 1116273743 27226586 2226839400

NPE-400 bi trebalo da terminise 8000 ppp sesija sa tune-ovanom broadband verzijom IOS-a :) ali ako u ovom okruzenju izvuces vise od 500 onda je carevski :))

itd itd....

p.p.s. nemoj krivo da me shvatis i ja obozavam NPE-400 :) ali neke stvari su jednostavno... jadne... :)

Pa ne svodi se na isto, zato što postoji suštinska razlika između process, fast i CEF (cisco express forwarding) switchinga. Netflow switching je nešto sasvim deseto. Takođe, ako imaš samo par interfejsa na ruteru, razlike su zaista minimalne između CEF-a i fast switchinga. Netflow radi u kombinaciji sa oba. Ako uključiš flow, interfejs automatski prelazi u fast switching (ako se ne varam, mada nisam 100% siguran). Od IOS-a 12.0 pa na dalje, default switching je fast, a ne process kao ranije. Kad u globalnom modu isključiš CEF (no ip cef) i na interfajsu kažeš "no ip route-cache", tek ćeš onda da vidiš šta znači kad procesor switchuje pakete ;-). Ah da, imaj pri ruci konzolni kabl ako ovo radiš na edge ruteru.




Dva komentara :-). Oduvek sam tvrdio da se problemi najlakše rešavaju novčanikom. Ne treba ti pamet uopšte. Toliko na temu "nakrcaš 2GB" ;-).

Drugi komentar je zapravo pitanje. verovatno više teoprijske prirode, ali... Šta ti tačno podrazumevaš pod "forwarding" i "control" planeom u ovom kontekstu!? Ovo ne pitam zajedljivo, nego mi prosto nije jasno na šta tačno misliš?



O Ciscovim cenama uopšte neću ni da počinjem da raspravljam. Sve što kažeš na tu temu, a da spada u najgrđu pljuvačku, totalno i apsolutno si u pravu. Odvratno :-).



Da, naravno da možeš da staviš filter i lepo k'o čovek ne primaš ništa ispod /20 (što na žalost mnogi veliki ISP-ovi rade), ali to nije suštinsko rešenje problema velikog broja ruta.



Osnovna stvar u svakoj tehničkoj diskusiji je da sagovornici pričaju istim jezikom, ili bar znaju o čemu je reč. kako ja o SMIN-u znam samo da je call forwarding na steroidima, možda ne bi bilo loše da me malo prosvetliš o tehničkom delu SMIN konekcije između Telekoma i provajdera. S druge strane, imaj na umu da su CEF i fast switching fundamentalno nekompatibilni sa svim tipovima procesiranja DOLAZNIH paketa, sem osnovnih i proširenih access-listi (koje analiziraju samo prvi paket u istom FEC-u). Drugo vezano za SMIN, ako je istina da su zaista to implementirali preko nekakvih PPTP ili kakvih već tunela, a ne preko MPLS VPN-ovaa u svojoj infrastrukturi, onda me uopšte ne iznenađuje što provajderi imaju problema sa performansama i SMIN-om. To je sve zaista process switched i tu nema pomoći, ali za to ne treba kriviti Cisco.



Šta ja znam, ja imam drugih favorita :-)

cisco 7206VXR (NPE-G1) processor (revision A) with 245760K/16384K bytes of memory.
Processor board ID 29741013
SB-1 CPU at 700Mhz, Implementation 1, Rev 0.2, 512KB L2 Cache
6 slot VXR midplane, Version 2.7


Marko.

P.S. Imam i ja četiri-pet NPE-400, al' volim da se puvam :->

---

Moj favorit je ipak.... ili nesto u sledecem stilu.. :)

Copyright (c) 1992-1998 FreeBSD Inc.
Copyright (c) 1996-2000 Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
JUNOS x.xRx #0: 200x-xx-xx 03:24:10 UTC
[email protected]:/b/build/x.xRx/release_kernel/sys/compile/GENERIC
CPU: Pentium Pro (331.71-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x66a Stepping=10
Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,<b16>,<b17>,MMX,<b24>>
real memory = 805306368 (786432K bytes)
avail memory = 786079744 (767656K bytes)
....
root> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis xxxxx M40
Backplane REV 02 710-001348 xxxxx
Power supply B REV 08 740-000235 xxxxx DC
Maxicab
Minicab
Display REV 07 710-000150 xxxx
SCB REV 02 710-001838 xxxx Internet Processor II
FPC 0 REV 01 710-001292 xxxx
PIC 0 REV 01 750-002501 xxxx 4x E3
PIC 1 REV 03 750-002954 xxxx 4x E1, RJ48
PIC 2 REV 08 750-001072 xxxx 1x G/E, 1000 BASE-SX
PIC 3 REV 01 750-001323 xxxx 1x Tunnel
FPC 1 REV 01 710-001292 xxxx
....

Bolje radi :) definitivno :) Inace, evo ti samo mali paste za ono pitanje...

Juniper Networks pioneered modern routing architecture by cleanly separating the control plane from the forwarding plane for high resiliency. This carrier-class architecture consists of three components: the Routing Engine, which runs the JUNOS and ERX OS software in the control plane; and the ASIC-driven switch fabric and packet processing performed by the Packet Forwarding Engines.

CISCO tek sada implementira neke stvari... dok su ostali imali davno... doduse i ovi su bezobrazni sto se cene tice, cak i bezobrazniji od kviska.... inace, pogledaj 'sh proc cpu h' kod sebe i primetices tacno kada CISCO radi konvergenciju u BGP-u:) svakih j.. minut i nesto:) a spora je do bola i sve je sporija kako se broj routa povecava... tek su u 12.3.2T1 uveli optimizaciju BGP konvergencije, sto naravno ako imas dodatnih 35M uzme i to :) ako nemas, trpi svakih minut po 10 sec zakucavanja procesora za racunanje next-hop, proveru itd itd :) Sto se u tom trenutku ako imas puno sesija i ne koristis peering grupe odrazi na perfomanse forwardinga, upravo zbog nerazdvojenosti.

Doduse sve ovo nema veze sa ipv6, a u neku ruku opet ima... samo pogledaj na http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp od koje verzije cisco podrzava CEFv6 switching for automatic IPv6 in IPv4 tunnels :) Kod junipera opet imas karticu koja hardverski radi tunnel od 622Mbps :) Uostalom... IPv6 je jos daleko od korisnog .... :) prvo edukacija, pa implementacija pa da i debilu postane jasno kako to funkcionise. Klik, dva klika i da ne razmislja :)

To ne bih znao, direktnog iskustva sa Juniperom, na žalost nemam. Doduše, nemam ni ništa protiv Junipera. Definitivno je ozbiljna tehnologija u pitanju. U krajnjem slučaju, u svim modernim tehnološkim pravcima Juniper i Cisco veoma tesno sarađuju (opet moja omiljena tema - MPLS).



Opet ti. Lepo sam ti rekao da ima ASIC na jačim platformama. Takođe, treba imati na umu još jednu stvar, a to je Ciscov pristup buretu, da ne kažem problemu. Cisco je prvenstveno softverska firma. Zaslužnost za Ciscovo prisustvo na tržištu je IOS, manje-više njihov hardver (sve što valja od njihovog hardvera, kupljeno je od drugih). Totalno drugi problem je što je IOS prepun kojekakvih arhaičnih stvari koje nikom živom više ne trebaju.



Interesantno:


Totalno nemam problem sa tim. Kao što vidiš, peak je na cca. 50%, dok je prosek daleko ispod. Jesi li siguran da nemaš rekurzivne pretrage za svaki next-hop, ako ti se to dešava?

Na stranu to što 12.3.(2)T1 još nije izašao i što je najnovija verzija 12.3(2)T u kojoj se ne spominje ništa nalik. Istina, možda nisam dobro video -- imaš li link možda? Ovo me baš zanima. Ah, da. T IOS-i su beta IOS-i. Sve probleme koje imaš sa njima >/dev/null ;-). Ja sam imao ruter koji je umirao sam od sebe kad saobraćaj premaši 20kilopaketa/s. Ispostavilo se da je bio BUG u CEF-u u toj T verziji na 2651 platformi. Ne-T verzija je radila savršeno.



Sa ovim se izgleda svi slažemo.

Marko.

---

Gledaj malo cesce CPU% per second graf, upravo ti peakovi na CPU per minute grafu su od tih skokova i malo su veci :) jer nemas uracunate hardverske interupte koji se tu ne vide, a router gus-gus:)


Sto se tice trenutnih verzija ios-a ovako stvari stoje:

ftp> pwd
257 "/cisco/crypto/3DES/ios/12.3" is current directory
ftp> ls
200 PORT: Command successful
150 Opening ASCII mode data connection for file list
drwxr-x--- 15 ftpadmin ftptrides 4096 Oct 20 14:24 .
drwxr-x--- 8 ftpadmin ftptrides 4096 May 19 18:33 ..
drwxr-x--- 38 ftpadmin ftptrides 4096 Sep 24 16:51 12.3.1
drwxr-x--- 39 ftpadmin ftptrides 4096 Sep 24 16:51 12.3.1a
drwxr-x--- 5 ftpadmin ftptrides 4096 Aug 29 09:01 12.3.1aB
drwxr-x--- 17 ftpadmin ftptrides 4096 Aug 11 16:22 12.3.2-XA
drwxr-x--- 5 ftpadmin ftptrides 4096 Sep 11 17:01 12.3.2-XA1
drwxr-x--- 4 ftpadmin ftptrides 4096 Oct 9 16:30 12.3.2-XA2
drwxr-x--- 3 ftpadmin ftptrides 4096 Aug 25 20:36 12.3.2-XB
drwxr-x--- 11 ftpadmin ftptrides 4096 Sep 29 14:32 12.3.2-XC
drwxr-x--- 36 ftpadmin ftptrides 4096 Jul 28 16:13 12.3.2T
drwxr-x--- 35 ftpadmin ftptrides 4096 Sep 2 14:22 12.3.2T1
drwxr-x--- 31 ftpadmin ftptrides 4096 Oct 20 15:20 12.3.2T2
drwxr-x--- 30 ftpadmin ftptrides 4096 Sep 16 12:56 12.3.3
drwxr-x--- 29 ftpadmin ftptrides 4096 Oct 20 14:41 12.3.3a
226 Transfer complete.
ftp> cd /cisco/ios/12.3/
250 CWD command successful.
ftp> ls
200 PORT: Command successful
150 Opening ASCII mode data connection for file list
drwxr-x--- 15 ftpadmin ftpcio 4096 Oct 20 14:25 .
drwxr-x--- 16 ftpadmin ftpcio 4096 May 19 18:31 ..
drwxr-x--- 56 ftpadmin ftpcio 4096 Sep 24 16:48 12.3.1
drwxr-x--- 57 ftpadmin ftpcio 4096 Sep 24 16:49 12.3.1a
drwxr-x--- 5 ftpadmin ftpcio 4096 Aug 29 08:58 12.3.1aB
drwxr-x--- 9 ftpadmin ftpcio 4096 Aug 11 16:21 12.3.2-XA
drwxr-x--- 4 ftpadmin ftpcio 4096 Sep 11 17:01 12.3.2-XA1
drwxr-x--- 3 ftpadmin ftpcio 4096 Oct 9 16:30 12.3.2-XA2
drwxr-x--- 5 ftpadmin ftpcio 4096 Aug 25 20:37 12.3.2-XB
drwxr-x--- 5 ftpadmin ftpcio 4096 Sep 29 14:31 12.3.2-XC
drwxr-x--- 35 ftpadmin ftpcio 4096 Jul 28 16:14 12.3.2T
drwxr-x--- 34 ftpadmin ftpcio 4096 Sep 2 14:21 12.3.2T1
drwxr-x--- 30 ftpadmin ftpcio 4096 Oct 20 15:19 12.3.2T2
drwxr-x--- 47 ftpadmin ftpcio 4096 Sep 16 12:56 12.3.3
drwxr-x--- 46 ftpadmin ftpcio 4096 Oct 20 17:15 12.3.3a
226 Transfer complete.


inace za koji dan izlaze 12.3.5 i 12.3.4T

a vise o BGP convergence optimizaciji u T verzijama 12.3 na:
http://www.cisco.com/univercd/...ution/ip_sol/grip/grip_ovr.htm
inace ugradjena je i u novije 12S..

Kao što rekoh, uopšte nisam primetio da se ruter(i) guše.



Ovo sam sve iščitao i prošao kroz:

http://www.cisco.com/univercd/...123newft/123t/123t_2/index.htm
http://www.cisco.com/univercd/...123newft/123t/123t_4/index.htm

i uopšte nisam naišao na to što pričaš. Naravno, onaj dokument piše o optimizaciji BGP konvergencije, ali to nema veze s tim što ti pričaš. Mislim, onaj dokument je napisan 2002... Još uvek nisam ubeđen... :-)


Marko.

---

Al si ti neki nepoverljiv covek... :) Uloguj se bre na CCO i lepo udaris search IOS by feature :) i onda dobijes sledece:

Cisco Feature Navigator II
Objective: Define a specific software image in order to view its supported features.
Select from the pull down menus to find releases which support particular platform and feature set combinations.View your results in the table below and repeat as necessary to define a specific software image.

Your Selections:
Features: BGP Convergence Optimization

GD Release
LD Release
ED Release 12.3(4)T 12.3(2)XC 12.3(2)XB 12.3(2)XA2 12.3(2)T2 12.2(20)S 12.2(19)SW 12.2(18)SV 12.2(18)S1

-----
ende :)

Pa tako lepo reci kao čovek. Vidiš gore da ne piše u "what's new" :-)

Marko.

---

I mene to "what's new" iritira, pola stvari izostave... ali zato kada odes na feature navigator i kazes mu "compare images" on izlista sve i sta su skinuli i sta su dodali i slucajno pre jedno 4 meseca primetim taj detalj, kliknes i lepo ima read more:)

Doduse ove T verzije ne bih savetovao da koristis jos, upravo taj feature ume da zaglavi router u potpunosti ako nisi na svim komsikama :)) stavio MTU discovery pogotovo ako koristis RR ili iBGP preko Eth (mtu problem). To mi se desilo:) prevideo sam da treba MTU discovery:))

S verziju koristim, ona je ok... sasvim...

Nisam lud da teram T -- been there, done that.

Uzgred, ova rasprava je mala izašla iz okvira ovog foruma. Možda bismo mogli da se prebacimo u mreže.

Marko.

P.S. Uzgred, *upravo* sam svojim očima video da si zapravo u pravu. Čisto probe radi sam rešio da prihvatim tvoje mišljenje na temu BGP konvergencije i računanja sledećeg hop-a i rešio jedan jitter problem. Naime, problem o kojem ti pričaš se manifestuje samo ako BGP next-hop nije isto što i IGP next-hop, dakle ako IBGP neighbori nisu direktno vezani (što nije retka pojava). Nisam ni bio svestan da je zapravo to uzrok tog jittera koji sam imao. Korisna rasprava :-)

---