Nätverkskonfigurationsprotokollet, NETCONF , är ett nätverksenhetshanteringsprotokoll. Den utvecklades inom NETCONF-arbetsgruppen och publicerades först i RFC 4741 , som reviderades till RFC 6241 i juni 2011.
NETCONF tillhandahåller mekanismer för att ställa in, hantera och avkonfigurera nätverksenheter genom RPC-fjärrproceduranrop. NETCONF använder XML som ett sätt att tillhandahålla konfiguration och som ett sätt att generera meddelanden för ett protokoll som är implementerat ovanpå en transport.
NETCONF kan grovt delas in i fyra nivåer:
Nivå Exempel +----------------+ +------------------------------- ------------+ | Innehåll | | Enhetskonfiguration | +----------------+ +------------------------------- ------------+ | | +----------------+ +------------------------------- ------------+ | Verksamhet | |<get-config>, <edit-config>, <notification>| +----------------+ +------------------------------- ------------+ | | | +----------------+ +------------------------------+ | | RPC | | <rpc>, <rpc-reply> | | +----------------+ +------------------------------+ | | | | +----------------+ +------------------------------- ------------+ | Transport | | BEEP, SSH, SSL, konsol | | protokoll | | | +----------------+ +------------------------------- ------------+Den grundläggande implementeringen av protokollet inkluderar följande typer av förfrågningar: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, < close-session>, <kill-session>.
Den grundläggande funktionaliteten i NETCONF kan utökas med tillägg. När en session upprättas utbyter klienten och servern information om installerade tillägg med varandra. RFC 4741 definierar ytterligare funktioner, specifikt: xpath och :validate.
Möjligheten att prenumerera på och ta emot asynkrona meddelanden publiceras i RFC 5277 . Den definierar en begäran av typen <create-subscription> som inkluderar möjligheten att prenumerera på realtidsmeddelanden. I sin tur skickas meddelanden via <notification>-instruktionen. RFC definierar också en funktion: interleave som, i samband med: notifiering, hjälper till att hantera olika NETCONF-förfrågningar under en aktiverad prenumeration.
Ytterligare funktioner inkluderar låsande del av konfigurationen. Detta låter dig redigera icke-överlappande träd i en körbar konfiguration inom flera sessioner. Utan detta tillägg är endast blockering av hela konfigurationen möjlig.
Arbetsgruppen arbetar för närvarande med stöd för meddelanden som tillåter utbyte av mallar ( XML Schema , Relax NG , etc.) som definierar NETCONF-trädet.
NETCONF kan köras ovanpå flera transportprotokoll:
Innehållet i NETCONF-förfrågningar är giltig XML, varav de flesta är relaterad till enhetskonfiguration.
NETMOD-arbetsgruppen har slutfört arbetet med ett mänskligt orienterat språk för att representera aktuell enhetstillstånd, konfiguration, varningar och operationer, kallat YANG . YANG definieras i RFC 6020 och utökas med RFC 6021 , som introducerar de grundläggande datatyperna.
Under sommaren 2010 fick NETMOD-arbetsgruppen möjlighet att arbeta med en konfigurationsmodell (system, gränssnitt, routing) kompatibel med SNMP- modellen .
I slutet av 80-talet utvecklade IETF SNMP , som blev mycket populärt. Trots det faktum att SNMP gav möjligheten att konfigurera enheter, användes detta protokoll i stort sett för nätverksövervakning. År 2002 gick Internet Architecture Council och nyckelmedlemmar i IETF-gemenskapen ihop med transportörer för att diskutera denna situation. Resultaten av diskussionen publiceras i RFC 3535 . På den tiden använde telekomoperatörer ett proprietärt kommandogränssnitt för att konfigurera sina enheter. Gränssnittet hade många bekvämligheter, till skillnad från SNMP. Dessutom tillät många tillverkare inte fullständig konfiguration av sina enheter via SNMP. Nätverksingenjörer skrev mestadels skript som hjälpte dem att hantera enheter, men kommandogränssnittet i det här fallet är orsaken till många svårigheter. Den mest betydelsefulla av dessa är oförutsägbarheten hos utdata som genereras av nätverksenheten. Utdatans innehåll och formatering tenderar att förändras på sätt som inte alltid är förutsägbara.
Samtidigt använde Juniper Networks en XML-baserad konfiguration. Detta har föreslagits av IETF och cirkulerat till samhället.
Dessa två fakta ledde till skapandet av ett protokoll som skulle uppfylla kraven från både nätoperatörer och utrustningsleverantörer.