Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and any ask questions about how to configure and troubleshoot Border Gateway Protocol with Cisco expert Vinit Jain.
Ask questions from Monday August 10th to Friday August 21, 2015
Border Gateway Protocol (BGP) is one of the most widely deployed protocols in networks today and is the definitive routing protocol in the Internet. BGP is a flexible protocol, in that a variety of options are available to network engineers. Furthermore, extensions and implementation enhancements make BGP a powerful and yet complex tool. Because of BGP's pervasive deployment across multiple networks and the large number of use-cases that BGP can be applied to, it is becoming increasingly important to understand how to troubleshoot BGP issues quickly and easily. I will be helping you answer your queries on how to troubleshoot BGP
Vinit will be helping you with all your queries on all of the above.
Vinit Jain, 3X CCIE #22854 is a Technical Lead in HTTS (High Touch Technical Support) team supporting customers in areas of routing, MPLS, TE, IPv6, multicast and a wide variety of platform issues like High CPU, Memory leak, etc IOS, IOS XE, IOS XR and NxOS code base. Has been delivering trainings within Cisco on various technology as well as platform troubleshooting topics. He has also written workbook on IOS XR fundamentals on Cisco Support Community. Vinit has CCIE in R&S, SP and Sec and holds multiple certifications on programming and databases.
**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions
It is nice to have you here answering our questions regarding BGP!
My (first - more will surely come ;) question is of a more theoretical nature: Has Cisco's BGP implementation ever honored the ATOMIC_AGGREGATE attribute in any way? It is possible to receive a prefix having this attribute set, obviously generated by an aggregation, and yet construct an inject map that will de-aggregate this prefix by injecting more specific subprefixes into the BGP RIB. So is there any meaning to the ATOMIC_AGGREGATE attribute in Cisco's BGP implementation at all?
Thank you very much!
Thanks for posting an interesting question.
Since you know, ATOMIC_AGGREGATE attribute is just a kind of an alert attribute that tells the receiving router that aggregate route might or might-not not be from the advertising AS. from what i have read (not really seen Juniper's implementation) that both Cisco and Juniper behave the opposite when it comes to ATOMIC_AGGREGATE. Cisco by default doesn't set the AS_SET attribute hence ATOMIC_AGGREGATE must be set.
Why different vendors have diff implementation, is a debatable thing :)
The RFC 4271 states as below:
If an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD include the ATOMIC_AGGREGATE attribute.
so in a way, I look at it is, When we are aggregating, we are just trying to hide the information and thus the default behavior of having ATOMIC_AGGREGATE attribute set.
Hope that makes sense.
Feel free to post any questions. Its always interesting to have such discussions.
Thank you very much for responding.
My question was more focused on taking the ATOMIC_AGGREGATE attribute into account once it has been set. RFC 4271, Section 5.1.6 states:
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT make any NLRI of that route more specific (as defined in 9.1.4) when advertising this route to other BGP speakers.
Section 9.1.4 says:
In particular, a route that carries the ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated. That is, the NLRI of this route cannot be more specific.
I recall, however, doing an experiment in the past where I created an aggregate route with the ATOMIC_AGGREGATE set, and on another router receiving this aggregate, I have configured an inject map that injected a couple of more specific subnets of this aggregate, i.e., I have deaggregated the aggregate again, despite the received aggregate prefix had the ATOMIC_AGGREGATE set.
It would appear that Cisco's BGP implementation does not actually take the ATOMIC_AGGREGATE attribute into account even if it is set - would that be a correct observation?
Following on from your question -
Is Cisco saying even with the atomic-aggregate set your not suppose to be able to inject a conditional route based on the receiving aggregate ?
If I understand this correctly -what you are doing is telling your routers the best path to take for a specific route within that received aggregate.
by injecting this specific route in the local rib of the router- And if so would why would this matter?
i remember having that discussion few yrs back and also read one of the conversations in the IETF community and found it a bit confusing.
To be very honest, i have not seen any deployments while troubleshooting these years where they are trying to de-aggregate an aggregated prefix. From what i understand is ATOMIC_AGGREGATE serves as an indication to the receiver that it can't "deaggregate" the prefix per some of the granularity associated with the NLRI of that route and deaggregation could result in the introduction of loops.
I tired that in lab and saw what you were saying:
R5#sh ip bgp 192.168.0.0 BGP routing table entry for 192.168.0.0/24, version 6 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Not advertised to any peer 200, (aggregated by 200 184.108.40.206), (injected path from 192.168.0.0/16), (received & used) 220.127.116.11 from 18.104.22.168 (22.214.171.124) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best R5#
So, yes, i think you can de-aggregate it but doing that might lead to possible loops and definitely not a good design. So your observation is correct :)
I will still have to check with some developers on whats their take on this. Will keep you posted.
And thanks again for posting interesting questions like these.
Inject-map feature was added long long time ago (12.0S release).
So I can only say inject-map does not follow RFC4271 section 9.1.4.
I dont think there are any plans for making a change to this CLI as there are customers who expect this CLI to work in the current way.
My explanation is that the inject-map is a manual BGP route policy change, should be configured only if they know it will not introduce loop.
Hope this answers your questions.
Thank you for these answers. So for now, I will simply assume that the ATOMIC_AGGREGATE is an attribute that is effectively ignored.
To Paul Driver: Is Cisco saying even with the atomic-aggregate set your not suppose to be able to inject a conditional route based on the receiving aggregate ?
No, in fact, Cisco behaves as if the ATOMIC_AGGREGATE never existed :) It's RFC 4271 that says that prefixes with ATOMIC_AGGREGATE must not be deaggregated while the inject-map effectively allows me to deaggregate such prefixes. I was trying to understand what is this attribute for - it appears to be useless and unused as it has no effect whatsoever.
Hello Vinit & Peter,
nice discussion about this lovely protocol!
I respectfully disagree with Vinit:
"Since you know, ATOMIC_AGGREGATE attribute is just a kind of an alert attribute that tells the receiving router that aggregate route might or might-not not be from the advertising AS."
Atomic-Aggregate attribute function is to indicate that loss of information, BGP attributes, has occurred.
As you know, you already have the information about which router performed the aggregation as it is indicated in the optional attribute AGGREGATOR that includes the AS and router-id of the router that did the aggregation.
By default, in Cisco, when you configure aggregation without the as-set option, it includes the atomic-aggregate attribute. It creates the summary with the specific prefixes "cleaning" BGP attributes, losing the AS_SET information. Also, if for example there are communities attached in the specific prefixes it will get lost.
On the other hand, when you configure aggregation with the as-set option for loop detection, it will include the attributes of the specific prefixes, with the AS_SEQUENCE in the AS_PATH and also, as said, it inherits the attributes of the routes that contribute to generate the aggregate. You may always control or cleaning the attributes of the aggregate with the attribute-map option
By the way, when you use conditional route injection both atomic-aggregate and aggregator attributes are copied to the injected prefix regardless the copy-attributes is used or not.
Thanks for the reply. The statement mentioned by me meant the same thing that ATOMIC_AGGREGATE means potential loss of information (aggregate prefix might or might not be from the advertising AS) and the answer is more from the AS perspective and in context to what Peter asked. Though i see he has clarified his question.
The BGP peer which advertised the ATOMIC_AGGREGATE, might be the same AS# from which the prefix was originally advertised thus the statement "might or might not be".
Though i agree that it indicates the information is lost.
Thanks again for clarification.
I went through your Cisco Live presentation and was checking on Slow-Peer. I do not see this CLI available on Nexus 7000 running 6.2.10. Is there any plan to integrate this feature in later release or is there a behavior change on how its treated in Nexus platforms.
NxOS doesn't support update-groups so a slow-peer condition doesn't apply on this platform.
I dont think its supported even on any latest releases like 7.x
Hope this answers,
Also, if you check the CLI, you will not find commands like show ip bgp update-group or show ip bgp replication:
sh ip bgp ?
> Redirect it to a file
>> Redirect it to a file in append mode
A.B.C.D Display one particular network from the BRIB in detail
A.B.C.D/LEN Display one particular prefix from the BRIB in detail
all Display BGP information for all address families
community Display routes matching the BGP communities
community-list Display routes matching the community-list
dampening Display dampening info
extcommunity Display routes matching the BGP extcommunities
extcommunity-list Display routes matching the extcommunity-list
filter-list Display routes matching the filter-list
flap-statistics Display route flap statistics
ipv4 Display BGP information for IPv4 address family
neighbors Display all configured BGP neighbors
nexthop Display routes matching the nexthop
nexthop-database Display nexthop database
paths Display Path information
peer-policy Display information about a peer-policy
peer-session Display information about a peer-session
peer-template Display information about a peer-template
prefix-list Display routes matching the prefix-list
received-paths Display paths stored for soft-reconfig
regexp Display routes matching the AS path regular expression
route-map Display routes matching the route-map
summary Display summarized information of BGP state
vrf Virtual Router Context
| Pipe command output to filter
Thank you for looking into our BGP issues !!
Nexus 7k running 6.2 ( 8a)
When bgp peering is configured with Md5 authentication & the other side is unconfigured or shutdown, the switch generates the below log messages continuously , filling up the logs.
2015 Jul 28 00:11:23 ltx1-e2-csw01.nw %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src: x.x.x.x.x.179,dst:x.x.x.x.39986
I dont see this behavior in a older code, 5.1(6)
1) Is this expected behavior for these messages to pop up every few secs if the remote end is not responding.
sh socket connection tcp detail shows the following states:
Local host: x.x.x.x (45444), Foreign host: x.x.x.x (179) Protocol: tcp, type: stream, ttl: 1, tos: 0xc0, Id: 29 Options: none, pcb flags unknown, state: | NBIO MTS: sap 40574 Receive buffer: cc: 0, hiwat: 16384, lowat: 1, flags: none Send buffer: cc: 0, hiwat: 16384, lowat: 2048, flags: none Sequence number state: iss: 1413260968, snduna: 1413260968, sndnxt: 1413260969, sndwnd: 0 irs: 0, rcvnxt: 0, rcvwnd: 0, sndcwnd: 536 Timing parameters: srtt: 0 ms, rtt: 0 ms, rttv: 12000 ms, krtt: 3000 ms rttmin: 1000 ms, mss: 536, duration: -1253082592 ms State: SYN_SENT Flags: | MD5TCP MD5 stats: 4 Tx Pass used, 4 disges_missing_noroll, 4 digest_miss_keychain,TCP MD5 Roll stats: MD5 digest: (1 peer) Host: 10.148.96.46 Context: default passwd configured Context: default
2) Is there any way to filter out these messages ?
I think the first step that needs to be done is, if the peer device is un-configured or shutdown, its better to shutdown on this side as well.
Having said that, i think its an expected behavior:
Nexus-R1# show sockets connection tcp detail | section 126.96.36.199 Local host: 188.8.131.52 (8977), Foreign host: 184.108.40.206 (179) Protocol: tcp, type: stream, ttl: 64, tos: 0xc0, Id: 19, tracer flag: FALSE Options: none, pcb flags unknown, state: | NBIO MTS: sap 39712 Receive buffer: cc: 0, hiwat: 16512, lowat: 1, flags: none Send buffer: cc: 0, hiwat: 16512, lowat: 2048, flags: none Sequence number state: iss: 1133083897, snduna: 1133083897, sndnxt: 1133083898, sndwnd: 0 irs: 0, rcvnxt: 0, rcvwnd: 0, sndcwnd: 516 Timing parameters: srtt: 0 ms, rtt: 700 ms, rttv: 12000 ms, krtt: 3000 ms rttmin: 1000 ms, mss: 536, duration: -1702163296 ms State: SYN_SENT Flags: | MD5 Nexus-R1# sh logging last 10 2015 Aug 13 03:28:50 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:220.127.116.11.179,dst:18.104.22.168.8683 2015 Aug 13 03:29:01 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:22.214.171.124.179,dst:126.96.36.199.8683 2015 Aug 13 03:29:19 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:188.8.131.52.179,dst:184.108.40.206.8683 2015 Aug 13 03:29:52 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:220.127.116.11.179,dst:18.104.22.168.8683 2015 Aug 13 03:30:19 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:22.214.171.124.179,dst:126.96.36.199.8683 2015 Aug 13 03:30:31 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:188.8.131.52.179,dst:184.108.40.206.8740 2015 Aug 13 03:30:43 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:220.127.116.11.179,dst:18.104.22.168.8740 2015 Aug 13 03:31:14 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:22.214.171.124.179,dst:126.96.36.199.8977 2015 Aug 13 03:31:26 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:188.8.131.52.179,dst:184.108.40.206.8977 2015 Aug 13 03:31:38 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE: netstack  MD5_DIGEST_MISSING:Dropping packets from src:220.127.116.11.179,dst:18.104.22.168.8683 Nexus-R1#
I have tested this on 7.2 release. The only possible workaround I could find is shutting down the neighbor from N7k side first and then the other side could be shut down.
Can you give it a try and let me know if that helps overcome the MD5 messages.
Hope this helps,