В предните 2 публикации се опитах горе-долу да обясня какво точно са 4 байтовите ASNи и изобщо каква роля играят ASN в BGP. Сега ще се опитам да обясня как точно се постига backward-compatibility между стари и нови BGP имплементации ( условно ще наричам НОВА тази имплементация, която поддържа 4 байтови ASN, а стара - тази която поддържа само 2 байтовите).
Да започваме. Първият логичен въпрос - Как 1 BGP рутер ще разбере дали съседът му поддържа стара или нова. Това става лесно чрез така нареченият capabilities advertisement. Както споменах преди - преди да започне обмяна на информация за рутирания, 2 BGP съседа си разменят OPEN съобщения, в които договарят параметри за връзката. В това OPEN съобщения може да се съдържа един незадължителен параметър - capibilites. На практика той описва какви точно възможности поддържа даденият рутер. Това е много удобен начин когато се започва една връзка между 2 BGP съседа те да си разменят такива OPEN съобщения, съдържащи capibilites параметъра и да кажат например нещо от сорта на "аз поддържам 4 байтови автономни системи. Моята 4 байтова автономна система е 0.xxx" - това е само пример, но горе-долу така изглежда целият процес. И ако другият съсед също поддържа 4 байтова автономна система, то той ще отговори по същия начин и така 2та рутера ще знаят своите 4 байтови автономни системи, без дори да използва 2 байтовото "My AS" поле в OPEN пакета ( за повече информация какво точно съдържа един BGP пакет, прочетете съответното RFC ).
Горният сценарий ще се получи, когато и двата съседа "говорят" ново BGP. Нека сега видим какво става, ако единият от двата не го поддържа. То този с "новата" имплементация пак ще прати OPEN съобщения с capabilities параметър, но "старата" имплементация или ще отговори, че не поддържа новия формат или няма да отговори изобщо на това съобщение. По този начин единият съсед ще знае дали другият има поддръжка или няма за 4 байтови ASN.
Тук е интересният момент - какво става, когато 2 съседа са установили връзка, но единият от тях не поддържа "новите" ASN? Как точно ще работи този, който ги поддържа? Просто е - в My Autnomous System, този с "новото" BGP ще сетне за автономна система - 23456 (както написах в първата публикация - това е една от резервираните автономни системи и ето за какво се използва). По този начин "новото" BGP ще знае, че съседа му не поддържа 4 байтовите автономни системи и ще се нагоди за работа с него, докато този рутер със старата имплементация просто ще си работи нормално.
До тук добре, ясно е че рутери ще могат да установят връзка, но какво става с AS_PATH атрибута, който при старите имплементации е с дължина 2 байта и не може да побира по-големи автономни системи. Ако един "нов" рутер изпльоска 4 байтова автономна система в AS_PATH, то "старите" нямат да могат да го разберат, но инженерите от IETF са се сетили и за това. Ето как са решили проблема.
Вместо да добавят 4 байтова автономна система в AS_PATH, то "новото BGP" ще добави 23456 и ще добави още един атрибут към пакета - AS4_PATH. В него ще се съдържа пълния списък на автономните системи - 2 и 4 байтови. Старите BGP имплементации, които не разбират какво точно прави, просто ще го пропускат нататък по веригата, няма да извършват никакво филтриране или strip-ване (тоест да го премахнат). Когато един такъв route бъде изпратен към "нов BGP" съсед, то той ще използва и AS4_PATH (ще вземе само 4 байтовите ASN) и AS_PATH (ще вземе всички), за да знае целия път за този маршрут. Това е много удобно, защото новите имплементации ще енкапсулират 4 байтовите си ASN в AS4_PATH, а всички стари BGP spaker-и ще си използват стандартното AS_PATH.
За AGGREGATOR атрибута нещата са горе долу същите - между 2 BGP рутера, които поддържат 4 байтови ASN ще се използва AGGREGATOR атрибута, който по дизайн ще поддържа 4 байта дължина на ASN, а между "стар" и "нов" BGP speaker ще се използват незадължителният атрибут - AS4_AGGREGATOR, който ще носи в себе си реалната автономна систем, а AGGREGATOR ще бъде носи стойността - 23456.
Накратко това е за новият формат на автономните системи. Сигурно ще минат години преди да почне масовото алокиране на автономни системи от RIRовете, но това е бъдещето и рано или късно то ще ни застигне и трябва да сме подготвени.
Горният сценарий ще се получи, когато и двата съседа "говорят" ново BGP. Нека сега видим какво става, ако единият от двата не го поддържа. То този с "новата" имплементация пак ще прати OPEN съобщения с capabilities параметър, но "старата" имплементация или ще отговори, че не поддържа новия формат или няма да отговори изобщо на това съобщение. По този начин единият съсед ще знае дали другият има поддръжка или няма за 4 байтови ASN.
Тук е интересният момент - какво става, когато 2 съседа са установили връзка, но единият от тях не поддържа "новите" ASN? Как точно ще работи този, който ги поддържа? Просто е - в My Autnomous System, този с "новото" BGP ще сетне за автономна система - 23456 (както написах в първата публикация - това е една от резервираните автономни системи и ето за какво се използва). По този начин "новото" BGP ще знае, че съседа му не поддържа 4 байтовите автономни системи и ще се нагоди за работа с него, докато този рутер със старата имплементация просто ще си работи нормално.
До тук добре, ясно е че рутери ще могат да установят връзка, но какво става с AS_PATH атрибута, който при старите имплементации е с дължина 2 байта и не може да побира по-големи автономни системи. Ако един "нов" рутер изпльоска 4 байтова автономна система в AS_PATH, то "старите" нямат да могат да го разберат, но инженерите от IETF са се сетили и за това. Ето как са решили проблема.
Вместо да добавят 4 байтова автономна система в AS_PATH, то "новото BGP" ще добави 23456 и ще добави още един атрибут към пакета - AS4_PATH. В него ще се съдържа пълния списък на автономните системи - 2 и 4 байтови. Старите BGP имплементации, които не разбират какво точно прави, просто ще го пропускат нататък по веригата, няма да извършват никакво филтриране или strip-ване (тоест да го премахнат). Когато един такъв route бъде изпратен към "нов BGP" съсед, то той ще използва и AS4_PATH (ще вземе само 4 байтовите ASN) и AS_PATH (ще вземе всички), за да знае целия път за този маршрут. Това е много удобно, защото новите имплементации ще енкапсулират 4 байтовите си ASN в AS4_PATH, а всички стари BGP spaker-и ще си използват стандартното AS_PATH.
За AGGREGATOR атрибута нещата са горе долу същите - между 2 BGP рутера, които поддържат 4 байтови ASN ще се използва AGGREGATOR атрибута, който по дизайн ще поддържа 4 байта дължина на ASN, а между "стар" и "нов" BGP speaker ще се използват незадължителният атрибут - AS4_AGGREGATOR, който ще носи в себе си реалната автономна систем, а AGGREGATOR ще бъде носи стойността - 23456.
Накратко това е за новият формат на автономните системи. Сигурно ще минат години преди да почне масовото алокиране на автономни системи от RIRовете, но това е бъдещето и рано или късно то ще ни застигне и трябва да сме подготвени.
0 коментара:
Публикуване на коментар