Re: BGP MDT

Marko,

I fully agree but looking into the reality, there are still many many
route reflector implementations in the field running with RD Type 2 or
running in a mixed environment with MDT SAFI and RD Type 2 and
therefore doing the conversion.
The big fun starts when you have IOS-XR boxes in the field running
only MDT SAFI and in addition old RD Type 2 boxes. If you have to
combine that with your Route Reflectors....
....lots of fun with lots of bugs :-) hehe...

regards

Roger #23543

On Thu, Jun 28, 2012 at 7:08 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
> Old-style type 2 peers are running code at least 6-7 years old, if not
> more. If anything, that should be a nice reminder to upgrade ;-)
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Thu, Jun 28, 2012 at 12:45 PM, Roger Pfaeffli <rpf23543_at_gmail.com> wrote:
>> As I said, this must be a bug :-)
>> mVPN is unfortunately a very sad topic on Cisco equipment, especially when it comes to interoperability with new style mdt safi and old style rd type 2 peers :-(
>>
>> Regards
>>
>> Roger #23543
>>
>> Sent from my iPhone
>>
>> On 27.06.2012, at 21:25, Brian McGahan <bmcgahan_at_ine.com> wrote:
>>
>>> Hi Nicky,
>>>
>>> You're right. I just verified this in 12.2(33)SRE3. At first if the MDT neighbor is not manually activated, the capabilities exchange does not contain AFI/SAFI IPv4 MDT. However after a reload AFI/SAFI IPv4 MDT is advertised to all VPNv4 peers that weren't previously activated, which results in them constantly sending NOTIFICATION about the disjoint capability. It shouldn't behave this way though.
>>>
>>> Most likely you could categorize this as a low severity bug, because although it's a step above a cosmetic bug it still shouldn't negatively affect anything in the control plane or data plane. You'll just constantly get the log messages that the neighbors failed the capabilities exchange for that AFI/SAFI.
>>>
>>> I would venture to guess that this problem is probably related to bug CSCsx21230, which states:
>>>
>>> CSCsx21230 - mVPN - PIM MDT information broken after reload
>>> Description
>>> Symptom:
>>>
>>> - PIM neighbors over default MDT on multicast VPN configuration may not come up on MPLS PE after a reload
>>>
>>> - On the output of "show ip pim mdt" there will be no indication of the MDT default group address
>>>
>>> Conditions:
>>>
>>> - Issue may be seen on MPLS PE configured for mVPN after doing IOS upgrade from image using extended communities and Type 2 RD for BGP advertisement, to an image supporting BGP address family MDT SAFI.
>>>
>>> - Router needs to be running IOS 12.4(20)T or later where the BGP address family MDT SAFI was introduced.
>>>
>>> Workaround:
>>>
>>> - After the reload, need to manually configure the new BGP address family ipv4 mdt and activate it for the VPNv4 neighbors.
>>>
>>>
>>> The latest version affected by this in the S train is listed as 12.2(33)SRB1, our versions 12.2(33)SRE2 and 3 should theoretically have the fix installed. Probably what they did as the fix is just to automatically activate all VPNv4 neighbors as MDT neighbors, even though the result of this doesn't show up in the running configs.
>>>
>>> You can see in my log output the "show bgp ipv4 mdt all summary" shows 5.5.5.5 as a NoNeg neighbor, but there is no "neighbor 5.5.5.5 activate" under address-family ipv4 mdt. Furthermore when you say "no neighbor 5.5.5.5 activate" under address-family ipv4 mdt there is no change in the running config, however there is a state change in the network as the neighbor stops advertising AFI/SAFI IPv4 MDT in the capabilities exchange, which stops the NOTIFICATION message.
>>>
>>> Interesting problem :) You can submit a bug report about it if you want and they'll add it to their queue. Within the scope of the CCIE Lab Exam I wouldn't worry about it though.
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>> bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>> From: Nicky [mailto:ccienovice_at_gmail.com]
>>> Sent: Wednesday, June 27, 2012 10:23 AM
>>> To: Brian McGahan
>>> Cc: ccielab_at_groupstudy.com
>>> Subject: Re: BGP MDT
>>>
>>>
>>> sh bgp ipv4 mdt all su
>>> BGP router identifier 8.8.8.8, local AS number 100
>>> BGP table version is 7, main routing table version 7
>>> 5 network entries using 740 bytes of memory
>>> 5 path entries using 280 bytes of memory
>>> 3/3 BGP path/bestpath attribute entries using 372 bytes of memory
>>> 8 BGP rrinfo entries using 192 bytes of memory
>>> 1 BGP AS-PATH entries using 24 bytes of memory
>>> 7 BGP extended community entries using 328 bytes of memory
>>> 0 BGP route-map cache entries using 0 bytes of memory
>>> 0 BGP filter-list cache entries using 0 bytes of memory
>>> BGP using 1936 total bytes of memory
>>> BGP activity 42/0 prefixes, 51/0 paths, scan interval 60 secs
>>>
>>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
>>> 2.2.2.2 4 9 0 0 1 0 0 never (NoNeg) >>> reappeared after reload
>>> 5.5.5.5 4 9 20 7 7 0 0 00:01:46 4
>>>
>>> sh bgp ipv4 mdt all
>>> BGP table version is 7, local router ID is 8.8.8.8
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
>>> r RIB-failure, S Stale, m multipath, b backup-path, x best-external
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>
>>> Network Next Hop Metric LocPrf Weight Path
>>> Route Distinguisher: 100:100 (default for vrf CUST)
>>> *>i3.3.3.3/32 3.3.3.3 0 100 0 ?
>>> *>i4.4.4.4/32 4.4.4.4 0 100 0 ?
>>> *>i7.7.7.7/32 7.7.7.7 0 100 0 ?
>>> *> 8.8.8.8/32 0.0.0.0 0 ?
>>> Route Distinguisher: 1001:100
>>> *>i9.9.9.9/32 5.5.5.5 0 100 0 1001 ?
>>> *>i10.10.10.10/32 5.5.5.5 0 100 0 1001 ?
>>>
>>> 2.2.2.2 is appearing because I have configured mdt default in vrf. But I need to know why such default has been programmed by cisco.
>>> On Wed, Jun 27, 2012 at 7:33 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>>> What does "sh bgp ipv4 mdt all summary" and "sh bgp ipv4 mdt all" say?
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>> bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>> From: Nicky [mailto:ccienovice_at_gmail.com]
>>> Sent: Tuesday, June 26, 2012 9:33 PM
>>> To: Brian McGahan
>>> Cc: ccielab_at_groupstudy.com
>>> Subject: Re: BGP MDT
>>>
>>> Please find the configuration:-
>>>
>>> vrf definition CUST
>>> rd 100:100
>>> !
>>> address-family ipv4
>>> route-target export 100:100
>>> route-target import 100:100
>>> route-target import 1001:100
>>> mdt default 239.255.2.10
>>>
>>> exit-address-family
>>> !
>>> address-family ipv6
>>> route-target export 100:100
>>> route-target import 100:100
>>> route-target import 1001:100
>>> exit-address-family
>>>
>>> =============
>>> router bgp 100
>>> no bgp default ipv4-unicast
>>> bgp log-neighbor-changes
>>> neighbor 2.2.2.2 remote-as 100
>>> neighbor 2.2.2.2 update-source Loopback0
>>> neighbor 5.5.5.5 remote-as 100
>>> neighbor 5.5.5.5 update-source Loopback0
>>>
>>> !
>>> address-family ipv4
>>> no synchronization
>>> network 8.8.8.8 mask 255.255.255.255
>>> neighbor 2.2.2.2 activate
>>> neighbor 5.5.5.5 activate
>>> no auto-summary
>>> exit-address-family
>>> !
>>> address-family vpnv4
>>> neighbor 2.2.2.2 activate
>>> neighbor 2.2.2.2 send-community extended
>>> exit-address-family
>>> !
>>> address-family ipv4 mdt
>>> neighbor 5.5.5.5 activate
>>> neighbor 5.5.5.5 send-community extended
>>> exit-address-family
>>>
>>> This is the config after removing the neighbor under mdt.Also, the IOS version is "12.2(33)SRE2".
>>>
>>> Cheers,
>>> Nikhil E.
>>> On Tue, Jun 26, 2012 at 10:27 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>>> That's only for versions that are pre-standard, and also only if you have the VRF locally configured, and only if you have the default MDT configured under the VRF. If you want to explicitly disable it then upgrade to a version that supports the standardized BGP AFI/SAFI for IPv4 MDT.
>>>
>>> Post your config and relevant show outputs if you're having trouble with a specific design and I'd be more than happy to help.
>>>
>>> HTH,
>>>
>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>> bmcgahan_at_INE.com
>>>
>>> Internetwork Expert, Inc.
>>> http://www.INE.com
>>>
>>> On Jun 26, 2012, at 10:27 AM, "Nicky" <ccienovice_at_gmail.com> wrote:
>>>
>>> This not a bug but IOS operation itself. Kindly go through the excerpt from the link shared by Brian:-
>>>
>>> "when a default MDT configuration exists and a VPNv4 neighbor in BGP is configured, a similar neighbor in the IPv4 MDT address family will be automatically configured."
>>>
>>> Cheers,
>>> Nicky
>>> On Tue, Jun 26, 2012 at 8:46 PM, Roger Pfaeffli <rpf23543_at_gmail.com> wrote:
>>> If you remove the neighbor from the mdt address family and it still appears in the config under the address family, it seems to be a bug. There is nothing like the "no bgp default ipv4 unicast". Like Brian said, if you completely want to remove The functionality" just delete the address-family ipv4 mdt.
>>>
>>> Regards
>>>
>>> Roger #23543
>>>
>>> Sent from my iPhone
>>>
>>> On 26.06.2012, at 14:22, Nicky <ccienovice_at_gmail.com> wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Kindly ignore the first sentence and please do let me know if there is any
>>>> command similar to "no bgp default ipv4-unicast" to disable this MDT SAFI
>>>> functionality.
>>>>
>>>> Cheers,
>>>> Nicky
>>>>
>>>> On Tue, Jun 26, 2012 at 5:47 PM, Nicky <ccienovice_at_gmail.com> wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>> Even if use the command no neighbor and reload the router the
>>>>> configuration reappears. Is there any command same as "no bgp default
>>>>> ipv4-unicast"?
>>>>>
>>>>> Cheers,
>>>>> Nicky
>>>>>
>>>>>
>>>>> On Tue, Jun 26, 2012 at 5:00 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>>>>>
>>>>>> MDT BGP neighbors don't get activated by default. Just like any other
>>>>>> AFI/SAFI in BGP, e.g. VPNv4, VPNv6, etc. you have to enable it manually.
>>>>>> You would need to add the "neighbor w.x.y.z activate" command under the
>>>>>> address-family ipv4 mdt.
>>>>>>
>>>>>> For versions that a pre-standard for BGP MDT SAFI, your VPNv4 peers will
>>>>>> also be your MDT peers. If you migrate to a newer version that supports
>>>>>> the BGP MDT standard it will automatically activate these peers under MDT
>>>>>> in addition to their VPNv4 configuration:
>>>>>>
>>>>>>
>>>>>> http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_mvpn.html#wp1116841
>>>>>>
>>>>>> If you want to remove a peer though you simply need to say "no neighbor
>>>>>> w.x.y.z activate" under address-family ipv4 mdt.
>>>>>>
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>>>>>> bmcgahan_at_INE.com
>>>>>>
>>>>>> Internetwork Expert, Inc.
>>>>>> http://www.INE.com
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>>>>> Nicky
>>>>>> Sent: Tuesday, June 26, 2012 5:58 AM
>>>>>> To: ccielab_at_groupstudy.com
>>>>>> Subject: BGP MDT
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> By default the neighbors get activated under address family ipv4 mdt.
>>>>>>
>>>>>> Is there any command to disable the default activation.
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Nicky
>>>>>>
>>>>>>
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>
>>>>>> _______________________________________________________________________
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Jun 29 2012 - 10:43:27 ART