cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7347
Views
75
Helpful
23
Replies

Ask the Expert: Configuring and Troubleshooting Border Gateway Protocol (BGP)

ciscomoderator
Community Manager
Community Manager

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 presented at  Cisco Live in June 2015 on Troubleshooting BGP 
Click here for More Information

 

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.

Find other  https://supportforums.cisco.com/expert-corner/events.

**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions

23 Replies 23

Peter Paluch
Cisco Employee
Cisco Employee

Hi Vinit,

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!

Best regards,
Peter

Hello Peter

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.

Vinit

Thanks
--Vinit

Hi Vinit,

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?

Thanks!

Best regards,
Peter

Hello Peter

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?

res

Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Peter

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.

https://www.ietf.org/mail-archive/web/idr/current/msg10951.html

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 3.3.3.3), (injected path from 192.168.0.0/16), (received & used)
    35.35.35.1 from 35.35.35.1 (3.3.3.3)
      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.

Regards

Vinit

Thanks
--Vinit

Hi Peter

Inject-map feature was added long long time ago (12.0S release). 

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpcri.pdf

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.

Regards,

Vinit

Thanks
--Vinit

Hi Vinit,

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.

Best regards,
Peter

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.

Best Regards,

Jose.

Hello Jose,

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.

Vinit

Thanks
--Vinit

Karan ()
Level 1
Level 1

Hi Vinit,

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.

Thanks

Hello

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,

Vinit

Thanks
--Vinit

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 ?
  <CR>               
  >                  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

 

 

Thanks
--Vinit

sumakhan
Cisco Employee
Cisco Employee

Hello Vinit,

 

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 [7046]  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)

 

Two questions:

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 ?

 

Thank you.

Suman

 

Hello Suman

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 1.1.1.1
Local host: 1.1.1.1 (8977), Foreign host: 2.2.2.2 (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 [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8683
2015 Aug 13 03:29:01 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8683
2015 Aug 13 03:29:19 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8683
2015 Aug 13 03:29:52 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8683
2015 Aug 13 03:30:19 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8683
2015 Aug 13 03:30:31 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8740
2015 Aug 13 03:30:43 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8740
2015 Aug 13 03:31:14 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8977
2015 Aug 13 03:31:26 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.8977
2015 Aug 13 03:31:38 Nexus-R1 %NETSTACK-3-TCP_MD5_AUTH_FAILURE:  netstack [3525]
  MD5_DIGEST_MISSING:Dropping packets from src:2.2.2.2.179,dst:1.1.1.1.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,

Vinit

Thanks
--Vinit
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: