簡介
本文檔介紹如何理解與裝置主機名和IP對映相關的XDR-Analytics行為。
背景
XDRA試圖跟蹤一段時間的邏輯裝置行為，稱為裝置。
它使用各種技術將網路流量隨著時間的推移關聯到這些邏輯裝置。
但是，特別是在內部部署環境中，系統可以將流量關聯到裝置的能力存在限制。
XDRA主要通過Netflow通過ONA、CTB或Cisco Meraki整合（「新的」Meraki整合）收集本地環境的遙感勘測。 其次，可以通過以下方式獲得主機名解析：
- 通過反向DNS查詢和通過ONA的SMB查詢進行活動主機名解析（可選）
- 通過ONA整合ISE
- 「舊」Meraki整合
- NVM整合，附帶其他警告
Netflow的IP地址沒有主機名資訊。
如果沒有主機名資訊，它將假定看到的每個內部IP地址（請參閱下面的定義）都是裝置，因為它沒有進一步的資訊來實現更智慧的裝置關聯。
在配置了主機名集合的情況下，XDRA使用主機名（如果看到），將其與裝置的內部表示形式相關聯。
這允許XDRA在一段時間內將多個IP地址分組到一個裝置。
NVM遙測可作為XDR的一部分進行可選配置。
此遙測源提供類似netflow的資料饋送，但也提供具有唯一識別符號的終端資訊。
XDRA利用此資訊的方式具有裝置跟蹤的淨效果，與在ONA上啟用主機名收集的情況類似。
所有這些設定都存在限制（基於可用遙測的限制）。
請注意，XDRA假定IP地址與主機名對映的性質為多對一關係（許多IP可以對映到一個主機名）。
一個邏輯裝置可以同時具有多個IP（例如，兩個物理介面或IPv4和IPv6）。
由於監控的性質，XDRA永遠不能假定在任何給定的時間擁有實際網路的所有關係。
重疊的子網
如果單個XDRA租戶同時監視多個本地子網，則系統無法區分其中每個子網中看到的同一IP。
因此，它將IP與裝置過度關聯。主機名可用性不能改善這種情況。
解決此問題的一種方法是擁有多個XDRA門戶（每個子網一個）。 另一種方法是使用「新」Cisco Meraki整合，因為此整合帶來的名稱空間隔離。
沒有可用主機名資訊的環境
作為有限的遙測資訊的一個副作用，系統可能會對裝置歷史記錄產生不正確的理解。
一種情況是IP是動態分配的，XDRA無法知道底層邏輯裝置已更改（例如WIFI上的筆記型電腦離開），並且IP已分配給新的筆記型電腦。
在沒有主機名或其他標識資訊的情況下，系統將多個邏輯裝置的活動關聯到一個裝置。這會導致裝置配置檔案資訊混亂。
Actual Situation
t0 t1 t2 t3
ip1 d1------ d2------
As seen by XDRA
t0 t1 t2 t3
ip1 d1----------------------
反之，如果一個邏輯裝置具有多個IP地址（例如，兩個物理介面或IPv4和IPv6），則沒有資訊可以可靠地將這些地址關聯到同一裝置，因此系統沒有此功能。
Actual Situation
t0 t1 t2 t3
ip1 d1--------------
ip2 d1--------------
As seen by XDRA
t0 t1 t2 t3
ip1 d1--------------
ip2 d1--------------
包含主機名資訊的環境
其中XDRA可以看到主機名資訊，系統能夠將多個IP地址與一個裝置相關聯。然而，鑑於資料的性質，系統能夠可靠地確定的資料仍有侷限性。這會導致IP與系統中的裝置過度關聯。
如果在XDRA中具有IP與主機名關聯的裝置，然後邏輯裝置更改IP地址，則遙測最終會反映新的IP與主機名的對映。
但是，由於這可能是一個多對一關係，因此XDRA無法安全地假設以前看到的IP不再與主機名（從而與裝置）相關聯。
例如，它可以是連線到同一邏輯裝置的單獨物理介面。因此，XDRA將以前看到的IP與最近看到的IP一起保留，直到發現遙測時，該遙測會將IP地址正對映到不同的主機名。
此時，XDR「過期」對映並將其列為前一個IP地址。
沒有辦法告訴系統「早期」中斷關聯。
有關主機名匹配的註釋
為了更好地處理租戶在多個域中配置了相同主機名的情況，XDRA採用「靈活」匹配方法，並在查詢匹配現有裝置（即匹配IP）時將表中顯示的條目視為匹配的主機名：
example
example.com
example.net
example.obsrvbl.com
example.invalid.obsrvbl.com
example.example.com
使用NVM的環境
此設定與「包含主機名資訊的環境」部分非常相似，但存在一些差異。
此資料饋送提供了額外的優勢，即能夠為使用者提供一些獨特的端點識別符號，這些ID可能允許我們跟蹤主機名發生變化的物理裝置（如果不進行跟蹤，我們將建立2個不同的裝置）。
儘管根據終端資料饋送（具有唯一終端ID）建立裝置，但在根據流資料對該終端進行觀察之前，沒有與這些裝置關聯的主機名或IP。
使用ISE的環境
ISE到裝置跟蹤的優勢最終與具有主機名信息的環境完全相同。
ISE資料用於將其收集的主機名資訊與IP地址相關聯，但不會建立新裝置或跟蹤Netflow中未檢測到的IP。
使用Meraki的環境
「舊」Meraki整合（即與XDRA整合）
此Meraki整合可主動從Meraki裝置收集主機名資訊，並按照常規方式將這些主機名對映到本地裝置（即「預設名稱空間」）中的IP。
如果裝置尚不存在，此過程將建立裝置。
由於名稱空間差異，它不會增加從其他「新」Cisco Meraki整合收集的裝置或IP資訊。
實際上，這會導致此配置的行為與包含主機名資訊的環境類似。
「全新」Cisco Meraki整合(即與XDR)
此整合將netflow從Meraki網路裝置通過XDR資料湖連線到標準XDRA netflow路徑。
因此，它會像任何其他netflow一樣建立Devices;此外，與任何其他netflow一樣，它不包含主機名資訊。
實際上，此配置的行為與沒有可用主機名資訊的環境類似，只有一個主要例外。
此整合利用傳送的資訊將來自不同Meraki裝置的netflow標籤到不同的名稱空間。
這避免了通常的子網重疊問題，但是如果設定多個整合，則可能會帶來新的困難。
最明顯的是，如果同時設定了「舊」和「新」Meraki整合，則它們不使用相同的名稱空間，因而建立了非重疊的裝置，即使在資訊表示同一物理裝置的情況下也是如此。
也就是說，您有2個裝置，其中一個位於預設名稱空間中，具有主機名且無流量，另一個位於特定Meraki名稱空間中，且無主機名。
如果同時啟用，則其他整合可能會發生類似的「拆分」。
定義
-
內部IP地址：XDRA考慮IP地址是內部地址還是外部地址，可以通過子網設定進行配置。內部子網的預設子網為RFC內部子網（RFC1918和RFC4193），但可以配置（新增或刪除）子網。
-
名稱空間：用於標籤從不同觀察點看到的netflow和裝置的其他資訊，允許子網重疊而不出現重疊IP問題。
ISE主機名資料流
-
ONA收集ISE會話資料，每10分鐘上傳至S3
-
此資料包含使用者<->IP資訊，有時還包含主機名
-
IseSessionsMiner分析上傳的資料，並在可能的情況下將IP與裝置關聯。如果裝置不存在，則不會建立裝置。這樣，只要我們已有裝置，它就會收集可用的主機名<->IP對映。
-
然後，它會在s3中建立一個檔案，其中的對映格式與ONA從其反向DNS查詢上傳的對映格式相同
-
然後通知系統載入這些主機名，就像載入ONA主機名一樣。
常見問題
為什麼在XDRA裝置上看到不再與我的網路上的該邏輯裝置關聯的IP?
不幸的是，我們對此無能為力。
系統無法知道舊關聯是否無效，或者是否由其他物理網路介面導致。
我沒有任何主機名資訊被傳送到XDRA，為什麼同時使用IPv4和IPv6地址的裝置顯示為2個不同的裝置？
如果沒有主機名資訊，我們就無法知道不同的IP與網路上的同一邏輯裝置相關聯。
為什麼在同一個XDRA裝置中會出現來自不同子網的多個邏輯裝置？
XDRA目前無法區分來自哪個子網遙測，因此相同的IP總是被分組到一個裝置中。
意見