Regarding the MTU value of MP-BGP EVPN control plane packets in Cisco ACI, which statement about communication between spine nodes in different sites is true?
A.
By default, spine nodes generate 9000-bytes packets to exchange endpoints routing information. As a result, the Inter-Site network should be able to carry 9000-bytes packets.
B.
By default, spine nodes generate 1500-bytes packets to exchange endpoints routing information. As a result, the Inter-Site network should be able to carry 1800-bytes packets.
C.
By default, spine nodes generate 1500-bytes packets to exchange endpoints routing information. As a result, the Inter-Site network should be able to carry 1500-bytes packets.
D.
By default, spine nodes generate 9000-bytes packets to exchange endpoints routing information. As a result, the Inter-Site network should be able to carry 9100-bytes packets.
Correct answer is A
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html
Excerpt:
MTU of MP-BGP control-plane communication between spine nodes in different sites: By default, the spine nodes generate 9000-byte packets for exchanging endpoint routing information. If that default value is not modified, the ISN must support an MTU size of at least 9000 bytes
It is D from the link you give => "Maximum MTU of the frames generated by the endpoints connected to the fabric: If the endpoints are configured to support jumbo frames (9000 bytes), then the ISN should be configured with at least a 9100-byte MTU value. If the endpoints are instead configured with the default 1500-byte value, then the ISN MTU size can be reduced to 1600 bytes"
I agree, the question is about exchanging endpoint routing information (i.e. control plane traffic) *between* spines in different sites, not local endpoint to spine traffic for which the 9100 byte MTU applies to.
MTU of MP-BGP control-plane communication between spine nodes in different sites: By default, the spine nodes generate 9000-byte packets for exchanging endpoint routing information. If that default value is not modified, the ISN must support an MTU size of at least 9000 bytes, otherwise the exchange of control-plane information across sites would not succeed (despite being able to establish MP-BGP adjacencies).
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html
A is correct..
There is not overhead from VXLAN for control plane traffic.
Go to System > Control Plane MTU and you will see that the value that could be set is between 576 and 9000.
And we can also set this option to 1500 for remote-leaf architecture.
https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/6x/system-management-configuration/cisco-apic-system-management-configuration-guide-60x/basic-operations-60x.html
A is the right answer as per the link https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html
Answer is D. While it's true the question is about the control plane and a mtu of 9000 is suitable. For the data plane you need to configure 9100 for mtu. In a real world environment you need to account for the data plane and go with the highest value. It could be A, but it's a technically either way.
From ACI Multi-site white paper:
The MTU of MP-BGP control-plane communication between spine nodes in different sites: By default, the spine nodes generate 9000-byte packets for exchanging endpoint routing information. If that default value is not modified, the ISN must support an MTU size of at least 9000 bytes; otherwise, the MP-BGP exchange of control-plane information across sites would not succeed.
IPN requirements for a Remote Leaf solution are as follows:
MTU: The solution must support an end-to-end MTU that is at least 100 bytes higher than that of the endpoint source traffic. Assuming that 1500 bytes has been configured for data plane MTU, Remote Leaf can be deployed using a minimum MTU of 1600 bytes. An IPN MTU this low, however, necessitates that ACI administrators lower the ACI fabricwide control plane MTU, which is 9000 bytes by default.
https://www.ciscopress.com/articles/article.asp?p=3150964&seqNum=3
The minimum MTU value to configure in the ISN depends on two factors:
● The maximum MTU of the frames generated by the endpoints connected to the fabric: If the endpoints are configured to support jumbo frames (9000 bytes), then the ISN should be configured with at least a 9050-byte MTU value. If the endpoints are instead configured with the default 1500-byte value, then the ISN MTU size can be reduced to 1550 bytes.
Maximum transmission unit (MTU) of Multiprotocol Border Gateway Protocol (MP-BGP) Ethernet Virtual Private Network (EVPN) control plane communication between spine nodes in different sites - By default, the spine nodes generate 9000-byte packets to exchange endpoint routing information. If that default value is not modified, the Inter Site Network (ISN) must support an MTU size of at least 9100 bytes. In order to tune the default value, modify the corresponding system settings in each APIC domain.
This question has two answers on the internet.
But if you want to support endpoint traffic of a MTU of 9000, it is required to increase the MTU to at least 9100 on the ISN.
So what is this question about? Something that is minimal required for the MP-BGP protocol to work? Or an recommended setup looking further than only the communication between Spines.
I would like to pick MTU 9100 for the ISN, but not sure if it is a trick question.
LINK 1 = MTU 9100
https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-controller-apic/214270-configure-aci-multi-site-deployment.html
LINK 2 = MTU 9000
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html
Maximum MTU of the frames generated by the endpoints connected to the fabric: If the endpoints are configured to support jumbo frames (9000 bytes), then the ISN should be configured with at least a 9100-byte MTU value. If the endpoints are instead configured with the default 1500-byte value, then the ISN MTU size can be reduced to 1600 bytes.
● MTU of MP-BGP control-plane communication between spine nodes in different sites: By default, the spine nodes generate 9000-byte packets for exchanging endpoint routing information. If that default value is not modified, the ISN must support an MTU size of at least 9000 bytes, otherwise the exchange of control-plane information across sites would not succeed (despite being able to establish MP-BGP adjacencies). The default value can be tuned by modifying the corresponding system settings in each APIC domain
the ISN mtu value needed depends on whether you need jumbo frame support for endpoint or not. In this question it does not say anything about endpoint jumbo frame support, in this case 9000 is enough for ISN control plane packets
A is correct. We are asked exactly about the control plane traffic between sites, not about the size of frames of the EPs connected to the fabric. Link provided by therufus is clearly describing that.
This section is not available anymore. Please use the main Exam Page.300-620 Exam Questions
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
therufus
Highly Voted 4 years, 1 month agoJey10
3 years, 12 months agoanasham
3 years, 4 months agoRTL_dude
4 years agoveld2
3 years, 2 months agoashwind123
Most Recent 1 month, 2 weeks agodesignated
5 months, 3 weeks agoLalag
9 months, 4 weeks agozelya19
1 year, 2 months ago959836c
1 year, 4 months agoMaccc10
1 year, 6 months agokamel86
1 year, 6 months agoChanderia
1 year, 9 months agoMr_Certifiable
1 year, 11 months agoRododendron2
2 years agobizzar777
2 years, 7 months agomdsuresh
2 years, 7 months agokorthab
2 years, 9 months agoeddyedwards257
2 years, 9 months agoleetingo
3 years, 2 months agoPlayer
3 years, 5 months ago