Nexus TCAM: ARP 억제 영역에 슬라이스 두 개가 필요한 이유

ARP 억제 영역의 크기를 정하고, 설계에 필요한 항목 수를 세고, 그보다 여유 용량이 많은 영역을 찾아도 변경은 여전히 들어가지 않습니다. 잘못 계산된 것은 없습니다. 읽고 있던 예산은 슬라이스 단위로 측정되며, 이중 폭으로 잘린 기능은 어떤 항목도 고려되기 전에 그중 두 개가 필요합니다.

할당을 고정된 단위 수를 가진 레이아웃 문제로 다루면 산술이 제대로 동작하기 시작합니다.

영역은 항목이 아니라 슬라이스를 소유한다

이 플랫폼의 TCAM은 슬라이스로 나뉘며, 각 슬라이스는 정확히 하나의 영역에 속합니다. 영역은 슬라이스 단위로 크기가 정해지고, 기능의 폭이 최소 몇 개의 슬라이스를 소비하는지 결정합니다. 단일 폭 기능은 슬라이스 하나에 들어갈 수 있지만, 이중 폭 기능에는 인접한 한 쌍이 필요합니다.

따라서 빈 슬라이스가 자동으로 사용 가능한 용량은 아닙니다. 서로 다른 슬라이스에 있는 두 단일 폭 영역은 새 이중 폭 영역에 필요한 한 쌍으로 합쳐지지 않으며, 전체적으로 사용되지 않은 공간이 많다고 보여 주는 표는 쓸 수 없는 풀을 말해 줍니다.

잘라 내기 전에 기준선을 기록하라

정확한 하드웨어 모델, NX-OS 릴리스, 현재 영역 폭과 크기, 각 영역을 소비하는 기능을 수집하십시오. 어떤 변경 전에도 이렇게 하십시오. 다시 로드한 뒤에는 이전 상태가 사실이 아니라 기억이 되기 때문입니다.

show version
show hardware capacity
show running-config | include hardware profile

명령 이름은 플랫폼과 릴리스에 따라 다르며, 잘라 내기 안내서는 자체 하드웨어에 적용되는 명령을 제시합니다. 다른 모델의 명령이 같은 표를 낸다고 가정하지 말고 실제로 받는 출력을 읽으십시오.

그다음 각 영역이 무엇을 위한 것인지 적으십시오. VACL 영역은 이유가 있어 필터 용량이고, QoS 영역은 아직 유효한 정책을 위해 누군가 크기를 정했기 때문에 존재합니다. 그런 공간을 확인 없이 회수 가능한 공간으로 취급하는 계획은 기능을 조용히 제거하는 계획입니다. 축소하려는 모든 영역에 소유자를 지정하고, 창 이전에 그 소유자에게 새 크기를 알리십시오.

방향도 고려하십시오. 플랫폼이 인그레스와 이그레스 할당을 연결하는 곳에서는 한쪽 변경이 다른 쪽 예산을 소비할 수 있으며, 인그레스 표만 세는 계획은 올바르게 보이지만 다시 로드할 때 실패합니다.

큰 슬라이스 하나를 비우는 것이 하지 않는 일

큰 단일 폭 영역을 줄이면 슬라이스 하나가 비워집니다. 대상 영역에 한 쌍이 필요하다면, 그 단일 슬라이스는 다른 빈 슬라이스에 인접하지 않는 한 쓸모가 없을 수 있으며, 인접성은 레이아웃의 속성이지 총합의 속성이 아닙니다.

이 지점에서 사람들은 플랫폼이 고장 났거나 문서가 틀렸다고 결론짓습니다. 둘 다 사실이 아닙니다. 할당 모델은 말한 대로 정확히 동작하고, 실수는 올바른 위치의 빈 슬라이스를 세는 대신 빈 공간을 센 것이었습니다. 레이아웃을 종이에 그려 보면 사용 가능한 쌍은 있거나 없거나 둘 중 하나이며, 그것은 총합을 두고 다투는 것보다 플랫폼 소유자와 훨씬 쉬운 대화입니다.

이름 붙일 만한 버전 함정도 있습니다. Cisco의 잘라 내기 안내서는 특정 하드웨어 세대를 설명하며, 그 모델이 Cloud Scale도 Silicon One도 아니라고 분명히 밝힙니다. 영역 이름, 기본 크기, 심지어 어떤 기능이 이중 폭인지도 다른 곳에서는 다르므로, 한 플랫폼의 특정 영역에 관한 경고는 그 플랫폼과 릴리스에 대한 증거이지 보편적인 레시피가 아닙니다.

영역 변경은 기능 변경이다

모든 잘라 내기는 용량 거래입니다. 영역을 줄여 ARP 억제를 위한 공간을 만드는 것은 그 영역이 보호하던 것을 줄이며, 그 결과는 공간이 필요한 정책이 다시 적용될 때까지 나타나지 않을 수 있습니다.

창 이전에 영향을 받는 각 기능의 소유자로부터 서면 동의를 받으십시오. 그것은 관료주의가 아닙니다. 원래 VACL 영역의 크기를 정한 사람은 그것이 무엇을 필터링하는지 알고, 공간을 만드는 사람은 보통 모릅니다.

하드웨어 레이아웃을 바꾸는 변경에는 다시 로드를 예상하십시오. 일부 플랫폼은 이를 요구하고 일부는 그렇지 않지만, 다시 로드가 가능할 때 유지보수 창 없이 계획하는 것은 라우팅 변경이 장애가 되는 방식입니다. 창은 명령이 아니라 다시 로드를 중심으로 잡고, 이전 프로필 텍스트는 관리 세션을 잃은 콘솔에서 읽을 수 있는 곳에 보관하십시오.

적용하고 기준선과 대조해 검증하라

플랫폼이 지원하는 절차로 계획을 적용한 다음, 추가한 기능만이 아니라 유지한 기능도 검증하십시오. 필터링이 조용히 일치를 멈춘 상태에서 동작하는 새로 잘라 낸 영역은 원래의 실패보다 나쁜 결과입니다.

용량 출력을 다시 읽고 기록한 기준선과 비교한 다음, 변경을 촉발한 기능을 시험하십시오. Nexus TCAM 잘라 내기 안내서 는 여기서 설명한 폭과 슬라이스 모델의 참조이며, 어떤 하드웨어 세대를 다루는지도 포함합니다.