No Pim Neighbor with MVPNs

Answered Question
Sep 21st, 2009

PE1 is non SAFI capable running(12.3.16a), RR1 and PE2 are SAFI capable(12.2.31.SB11

why isn't my RR "dumbing down the update" to PE1, is anyone aware of any bugs in either IOS?

I have this problem too.
0 votes
Correct Answer by Laurent Aubert about 7 years 2 months ago

Please clear the session and check with the debugs if the RR is sending the update to PE1.

Even after it's not working, last option I see before opening a TAC case is to try with SRC2 as it's the one I used in my set-up.

Laurent.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
shivlu jain Mon, 09/21/2009 - 21:49

If the PE is using mdt safi and route reflectors are using mdt safi & pre mdt safi in this case on PE you need to activate the ipv4 mdt for both the route reflectors so that PE can send the updates to RR1 with mdt safi and for RR2 it sends the update with extended 2:65500:1 community. In short we can upgraded RR1 is backward compatabile to the PE with respect to the mdt. Only one thing which we need to take is that to enable mdt safi for the non mdt PE.

Please refer the full document

http://shivlu.blogspot.com/2009/02/upgradation-of-rr-to-mdt-safi.html

regards

shivlu jain

lbrooker Mon, 09/21/2009 - 21:58

no the topology is

PE1 = MDT Safi Capable 122-31.SB11

PE2 = extended community 123-16a

RR(only 1 RR)= MDT SAFI Capable 122-31.SB11

shivlu jain Mon, 09/21/2009 - 22:20

MDT safi is used for mainly MVPN customers. If you are not going to activate the neighbor under ipv4 mdt in RR then it will dump the updates. If the mdt is activated under RR towards the non-mdt safi, it will not dump the updates.

regards

shivlu jain

lbrooker Tue, 09/22/2009 - 15:43

Thats the problem! The RR is configured for both vpnv4 and mdt towards both PEs, but the PE that doesn't support the MDT SAFI is not receiving it as a type 2 RD. Its like the RR is "not dumbing down" the new type MDT to old type 2 to the non MDT capable router. Hence why I think this is a bug on the RR. Its IOS is 122-31.SB11

Cheers

Mat

lbrooker Wed, 09/23/2009 - 05:49

OK changed the IOS on the RR and PE2 to

c7200p-spservicesk9-mz.122-33.SRC4

IOS of PE1 is c7200-p-mz.123-21 still no joy although i get an interesting debug message from debug ip bgp vpnv4

*Sep 23 05:17:59.111: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

*Sep 23 05:17:59.315: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

what does the above mean?

shivlu jain Wed, 09/23/2009 - 07:54

It means that the PE1 is receiving the routes with extended community because it doesn't support mdt safe, but it is rejecting the route because not able to find any vrf for the same.

regards

shivlu jain

lbrooker Thu, 09/24/2009 - 20:40

Hi Shivlu

I actually think its rejecting the route because of the RD? As if you put that IP address on an interface in that vrf it still fails.....have you managed to get this to work with RR supporting MDT SAFI sending updates to non supporting and supporting MDT SAFI PEs? I am looking at maybe an import map on the vrf configuration :o)

lbrooker Thu, 09/24/2009 - 20:48

actually that doesn't work either. I know my config is great so looking at IOS' if you have had this runnning then I would love to know how.

lbrooker Thu, 09/24/2009 - 21:16

Yeah I have already read this, but was just wondering if you had it working as well?

Laurent Aubert Fri, 09/25/2009 - 06:08

Hi,

*Sep 23 05:17:59.111: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

It's a locally generated update. If 203.194.30.63 is the address of PE1 then this is the update generated by PE1.

Do you have send-community both configured under the MDT AF ?

Thanks

Laurent.

lbrooker Sun, 09/27/2009 - 17:59

Hi Laurent, welcome to the party :o)

well from the PE point of view b/c its non SAFI the connection is via VPNv4 but both is stipulated. I think i read in the whitepaper that cisco released they say if you have a hybrid environment then you must have both stipulated on the RR, so in answer to your question yes we do have it.

PE1 is non SAFI shows no PIM neighbor

PE2 is SAFI and show one PIM neighbor(which happens to be PE1)

Cheers

lbrooker Sun, 09/27/2009 - 18:14

output from sh ip pim vrf "" neighbor command

PE2

sh ip pim vrf mpls neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

P - Proxy Capable, S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address Prio/Mode

203.194.30.63 Tunnel0 2d22h/00:01:28 v2 1 / DR S

PE1

sh ip pim vrf mpls neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address

Laurent Aubert Mon, 09/28/2009 - 07:25

Hi,

I tested it and it's working fine for me:

PE1--RR--PE2

PE1 running 12.3(16a), non-MDT aware L0= 10.1.2.1

RR and PE2 running 12.2(33)SRC2. MDT aware. L0: 100.100.2.1 and 10.1.2.2

Debug on PE2:

*Sep 28 15:10:07.165: %BGP-5-ADJCHANGE: neighbor 100.100.2.1 Up

*Sep 28 15:10:07.169: BGP:from:3 to:3 update format 2:2001:10.1.2.1/32 MDT grp 232.0.0.1 pfxptr->masklen 128

*Sep 28 15:10:13.541: BGP(4): ... start import cfg version = 5BGP: bpath->mdt 0xE8000001 232.0.0.1

*Sep 28 15:10:14.381: BGP:from:3 to:3 update format 2:2000:10.1.2.2/32 MDT grp 232.0.0.1 pfxptr->masklen 128

Debug from RR:

00:05:56: BGP(3): 10.1.2.1 send UPDATE (format) 2:2000:10.1.2.2/32, next 10.1.2.2, metric 0, path Local, extended community RT:2:20 MDT:2:232.0.0.1

Debugs from PE1:

AS2-PE20#

*Sep 28 15:15:34.595: BGP: Incoming path from 100.100.2.1

*Sep 28 15:15:34.595: BGP: Accepted path from 100.100.2.1

*Sep 28 15:15:34.595: BGP: Incoming MDT from 100.100.2.1 : present

*Sep 28 15:15:34.595: BGP: Inform multicast system about mdt 232.0.0.1 from router-id 10.1.2.1 with next-hop 10.1.2.1 : present

*Sep 28 15:15:34.595: BGP VPNV4: MPLS label changed for prefix 2:2:2001:10.1.2.1/32

*Sep 28 15:15:34.595: BGP VPNV4: bestpath from neighbor 100.100.2.1 nexthop 10.1.2.1 new outlabel exp-null

AS2-PE20#

AS2-PE20#sh ip pim mdt bgp

Peer (Route Distinguisher + IPv4) Next Hop

MDT group 232.0.0.1

2:2:2001:10.1.2.1 10.1.2.1

AS2-PE20#

AS2-PE20#sh ip mroute

...

(10.1.2.1, 232.0.0.1), 00:14:09/00:02:58, flags: sTIZ

Incoming interface: Ethernet0/0, RPF nbr 192.168.2.5

Outgoing interface list:

MVRF MVPN-IAS-B, Forward/Sparse, 00:14:09/00:02:10

(10.1.2.2, 232.0.0.1), 00:31:52/00:03:27, flags: sT

Incoming interface: Loopback0, RPF nbr 0.0.0.0

Outgoing interface list:

Ethernet0/0, Forward/Sparse, 00:09:52/00:03:21

(*, 224.0.1.40), 00:32:02/00:02:30, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Loopback0, Forward/Sparse, 00:32:02/00:02:20

Ethernet0/0, Forward/Sparse, 00:31:57/00:02:30

AS2-PE20#sh ip pim vrf MVPN-IAS-B neighbor

PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR

Address Prio/Mode

10.1.2.1 Tunnel0 00:17:15/00:01:41 v2 1 / S

AS2-PE20#

Can you check how the update is propagated from PE2 to PE1 ? Also please share your complete configuration.

Thanks

Laurent.

lbrooker Mon, 09/28/2009 - 15:38

Hi Laurent

Many thanks for this.

OK I am using PIM SSM and here is the config attached. each router is linked by a 7600 router that performs IGP connectivity and PIM signalling.

lbrooker Mon, 09/28/2009 - 16:07

Hi Laurent

Forgot to attach debugs from BGP updates

PE1)

wsr17-kent-syd-test#clear ip bgp *

wsr17-kent-syd-test#

*Sep 28 15:02:20.484: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Down User reset

*Sep 28 15:02:27.300: vpn: bgp_vpnv4_bnetinit: 20:1:172.17.20.1/32

*Sep 28 15:02:30.176: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Up

*Sep 28 15:02:30.176: BGP: Incoming path from 203.194.30.62

*Sep 28 15:02:30.176: vpn: bgp_vpnv4_bnetinit: 20:1:172.17.20.3/32

*Sep 28 15:02:30.176: BGP: Accepted path from 203.194.30.62

*Sep 28 15:02:30.176: vpn: bgp_vpnv4_alloc_tag route_tag_change for mpls:172.17.20.1/255.255.255.255

*Sep 28 15:02:30.176: vpn: tag_vpn_find_route_tags: 20:1:172.17.20.1

*Sep 28 15:02:30.176: vpn: intag=1886, outtag=aggregate(mpls), outtag owner=BGP

*Sep 28 15:02:40.196: %SEC-6-IPACCESSLOGS: list ssm-range permitted 239.232.0.17 1 packet

*Sep 28 15:02:42.612: vpn: tag_vpn_find_route_tags: 20:1:172.17.20.3

*Sep 28 15:02:42.612: vpn: intag=vpn-route, outtag=833, outtag owner=BGP

*Sep 28 15:03:27.320: vpn: bgp_vpnv4_bnetinit: 2:20:1:203.194.30.63/32

*Sep 28 15:03:27.320: vpn: bgp_vpnv4_alloc_tag route_tag_change for mpls:172.17.20.1/255.255.255.255

*Sep 28 15:03:27.320: vpn: tag_vpn_find_route_tags: 20:1:172.17.20.1

*Sep 28 15:03:27.320: vpn: intag=1886, outtag=aggregate(mpls), outtag owner=BGP

*Sep 28 15:03:27.320: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

*Sep 28 15:03:27.932: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

RR1)

rrv01-kent-syd-test#clear ip bgp vpnv4 unicast 20

rrv01-kent-syd-test#

5d19h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.61 VPNv4 Unicast topology base removed from session User reset

5d19h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.61 IPv4 MDT topology base removed from session User reset

5d19h: %BGP-5-ADJCHANGE: neighbor 203.194.30.61 Down User reset

5d19h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 VPNv4 Unicast topology base removed from session User reset

5d19h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 IPv4 MDT topology base removed from session User reset

5d19h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Down User reset

5d19h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.61, 0.0.0.0] from router-id 0.0.0.0 with next-hop 0.0.0.0 : absent

5d19h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 0.0.0.0] from router-id 0.0.0.0 with next-hop 0.0.0.0 : absent

5d19h: %BGP-5-ADJCHANGE: neighbor 203.194.30.61 Up

5d19h: BGP(4): Incoming path from 203.194.30.61

5d19h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.61, 239.232.0.17] from router-id 203.194.30.61 with next-hop 203.194.30.61 : present

5d19h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Up

5d19h: BGP(4): Incoming path from 203.194.30.63

5d19h: BGP(4): Incoming path from 203.194.30.63

5d19h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 239.232.0.17] from router-id 203.194.30.63 with next-hop 203.194.30.63 : present

PE2)

*Sep 29 02:46:44.637 EST: vpn: free local label 1048577 for remote prefix mpls:172.17.20.1/32BGP: bpath->mdt 0xEFE80011 239.232.0.17

*Sep 29 02:46:44.637 EST: BGP(3): 3 Inform multicast system about mdt [%Rx:203.194.30.63, 239.232.0.17] from router-id 203.194.30.62 with next-hop 203.194.30.63 : present

*Sep 29 02:46:44.637 EST: BGP:from:3 to:3 update format 20:1:203.194.30.63/32 MDT grp 239.232.0.17 pfxptr->masklen 128

*Sep 29 02:46:44.637 EST: BGP(4): Revise route installing 1 of 1 routes for 172.17.20.1/32 -> 203.194.30.63(mpls) to mpls IP table

*Sep 29 02:46:44.637 EST: vpn: get path labels: 20:1:172.17.20.1/255.255.255.255

*Sep 29 02:46:44.637 EST: vpn(4): inlabel=nolabel, outlabel=1886, outlabel owner=BGP

*Sep 29 02:46:44.637 EST: vpn(4): Announce labels to IPRM mpls:172.17.20.1/32 gw 203.194.30.63 inlabel=nolabel, outlabel=1886

Laurent Aubert Mon, 09/28/2009 - 19:31

I don't see PE1 receiving any MDT updates from the RR.

Can you run debug ip bgp vpnv4 unicast updates on both PE1 and RR and then do a clear ip bgp 203.194.30.63 soft out on the RR ?

Could you also run SRC2 on the RR so we will have the same set-up.

Thanks

Laurent.

lbrooker Mon, 09/28/2009 - 19:58

OK debugs are here, I am running SRC4, are you sure you want me to downgrade to SRC2?

RR1)

rrv01-kent-syd-test#clear ip bgp 203.194.30.63

rrv01-kent-syd-test#

5d23h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 VPNv4 Unicast topology base removed from session User reset

5d23h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 IPv4 MDT topology base removed from session User reset

5d23h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Down User reset

5d23h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 0.0.0.0] from router-id 0.0.0.0 with next-hop 0.0.0.0 : absent

5d23h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Up

5d23h: BGP(4): Incoming path from 203.194.30.63

5d23h: BGP(4): Incoming path from 203.194.30.63

5d23h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 239.232.0.17] from router-id 203.194.30.63 with next-hop 203.194.30.63 : present

PE1

wsr17-kent-syd-test#

*Sep 28 19:16:20.923: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Down Peer closed the session

wsr17-kent-syd-test#

*Sep 28 19:16:34.307: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Up

*Sep 28 19:16:34.307: BGP: Incoming path from 203.194.30.62

*Sep 28 19:16:34.307: vpn: bgp_vpnv4_bnetinit: 20:1:172.17.20.3/32

*Sep 28 19:16:34.307: BGP: Accepted path from 203.194.30.62

*Sep 28 19:16:34.407: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

*Sep 28 19:16:48.579: vpn: tag_vpn_find_route_tags: 20:1:172.17.20.3

*Sep 28 19:16:48.579: vpn: intag=vpn-route, outtag=868, outtag owner=BGP

Laurent Aubert Mon, 09/28/2009 - 20:18

Ok, I triple checked everything ;-) and I think I found why it's not working.

You didn't configure route-reflector client in the MDT AF. You should have on the RR:

address-family ipv4 mdt

neighbor 203.194.30.61 activate

neighbor 203.194.30.61 send-community both

neighbor 203.194.30.61 route-reflector-client

neighbor 203.194.30.63 activate

neighbor 203.194.30.63 send-community both

neighbor 203.194.30.63 route-reflector-client

exit-address-family

!

So the update received from PE2 will be propagated to PE1.

Let me know if it's working after the change.

Thanks

Laurent.

lbrooker Mon, 09/28/2009 - 20:31

I have added the config on the RR in teh MDT family and its still not working

Correct Answer
Laurent Aubert Mon, 09/28/2009 - 20:36

Please clear the session and check with the debugs if the RR is sending the update to PE1.

Even after it's not working, last option I see before opening a TAC case is to try with SRC2 as it's the one I used in my set-up.

Laurent.

lbrooker Mon, 09/28/2009 - 20:40

nope still have the same problem

router bgp 20

bgp router-id 203.194.30.62

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 10.2.0.5 remote-as 10

neighbor 10.2.0.5 description ebgp to rrv01.syd01.test

neighbor 10.2.0.5 ebgp-multihop 255

neighbor 203.194.30.61 remote-as 20

neighbor 203.194.30.61 description BDR02-SYD

neighbor 203.194.30.61 update-source Loopback0

neighbor 203.194.30.63 remote-as 20

neighbor 203.194.30.63 description WSR17-SYD

neighbor 203.194.30.63 update-source Loopback0

!

address-family ipv4

no synchronization

no auto-summary

exit-address-family

!

address-family vpnv4

neighbor 10.2.0.5 activate

neighbor 10.2.0.5 send-community both

neighbor 203.194.30.61 activate

neighbor 203.194.30.61 send-community both

neighbor 203.194.30.61 route-reflector-client

neighbor 203.194.30.63 activate

neighbor 203.194.30.63 send-community both

neighbor 203.194.30.63 route-reflector-client

exit-address-family

!

address-family ipv4 mdt

neighbor 203.194.30.61 activate

neighbor 203.194.30.61 send-community both

neighbor 203.194.30.61 route-reflector-client

neighbor 203.194.30.63 activate

neighbor 203.194.30.63 send-community both

neighbor 203.194.30.63 route-reflector-client

exit-address-family

lbrooker Mon, 09/28/2009 - 20:43

clear with debugs

PE1)

*Sep 28 20:02:05.867: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Down Peer closed the session

*Sep 28 20:02:17.135: %BGP-5-ADJCHANGE: neighbor 203.194.30.62 Up

*Sep 28 20:02:17.135: BGP: Incoming path from 203.194.30.62

*Sep 28 20:02:17.135: BGP: Accepted path from 203.194.30.62

*Sep 28 20:02:17.135: BGP: Incoming path from 203.194.30.62

*Sep 28 20:02:17.135: vpn: tag_vpn_find_route_tags: 20:1:172.17.20.3

*Sep 28 20:02:17.135: vpn: intag=vpn-route, outtag=868, outtag owner=BGP

*Sep 28 20:02:17.235: vpn: sourced prefix 2:20:1:203.194.30.63/32 not in any VRF, not allocating local label

RR1)

6d00h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.61 VPNv4 Unicast topology base removed from session User reset

6d00h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.61 IPv4 MDT topology base removed from session User reset

6d00h: %BGP-5-ADJCHANGE: neighbor 203.194.30.61 Down User reset

6d00h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 VPNv4 Unicast topology base removed from session User reset

6d00h: %BGP_SESSION-5-ADJCHANGE: neighbor 203.194.30.63 IPv4 MDT topology base removed from session User reset

6d00h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Down User reset

6d00h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.61, 0.0.0.0] from router-id 0.0.0.0 with next-hop 0.0.0.0 : absent

6d00h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 0.0.0.0] from router-id 0.0.0.0 with next-hop 0.0.0.0 : absent

6d00h: %BGP-5-ADJCHANGE: neighbor 203.194.30.61 Up

6d00h: BGP(4): Incoming path from 203.194.30.61

6d00h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.61, 239.232.0.17] from router-id 203.194.30.61 with next-hop 203.194.30.61 : present

6d00h: %BGP-5-ADJCHANGE: neighbor 203.194.30.63 Up

6d00h: BGP(4): Incoming path from 203.194.30.63

6d00h: BGP(4): Incoming path from 203.194.30.63

6d00h: BGP(3): 3 Inform multicast system about mdt [ #0:203.194.30.63, 239.232.0.17] from router-id 203.194.30.63 with next-hop 203.194.30.63 : present

lbrooker Mon, 09/28/2009 - 20:47

Laurent

can I see a copy of your debugs when you do a clear on your RR?

Cheers

Laurent Aubert Tue, 09/29/2009 - 07:49

Hi,

RR:

AS2-RR1#sh deb

IP routing:

BGP updates debugging is on for address family: VPNv4 Unicast

AS2-RR1#clear ip bgp * so

AS2-RR1#clear ip bgp * soft out

AS2-RR1#

00:04:39: BGP:from:3 to:4 update format 2:2001:10.1.2.1/0 MDT grp 232.0.0.1 pfxptr->masklen 96

BGP: bpath->mdt 0xE8000001 232.0.0.1

00:04:39: BGP: No vrf corresponding to the MDT group 232.0.0.1 exists

00:04:39: BGP(4): 10.1.2.2 send UPDATE (format) 2:2:2001:10.1.2.1/32, next 10.1.2.1, label 0, metric 0, path Local <----- update received from PE2 translated and sent by the RR

00:04:39: BGP:from:3 to:3 update format 2:2001:10.1.2.1/32 MDT grp 232.0.0.1 pfxptr->masklen 128

00:04:39: BGP:from:3 to:4 update format 2:2000:10.1.2.2/0 MDT grp 232.0.0.1 pfxptr->masklen 96

00:04:39: BGP:from:3 to:3 update format 2:2000:10.1.2.2/32 MDT grp 232.0.0.1 pfxptr->masklen 128

00:04:39: BGP:from:3 to:4 update format 1:1011:10.1.1.1/0 MDT grp 232.0.0.1 pfxptr->masklen 96

BGP: bpath->mdt 0xE8000001 232.0.0.1

00:04:39: BGP: No vrf corresponding to the MDT group 232.0.0.1 exists

00:04:39: BGP(4): 10.1.2.2 send UPDATE (format) 2:1:1011:10.1.1.1/32, next 1.1.12.1, label 0, metric 0, path 1

00:04:39: BGP:from:3 to:3 update format 1:1011:10.1.1.1/32 MDT grp 232.0.0.1 pfxptr->masklen 128

00:04:39: BGP:from:3 to:4 update format 1:1001:10.1.1.1/0 MDT grp 239.0.0.1 pfxptr->masklen 96

BGP: bpath->mdt 0xEF000001 239.0.0.1

00:04:39: BGP: No vrf corresponding to the MDT group 239.0.0.1 exists

00:04:39: BGP(4): 10.1.2.2 send UPDATE (format) 2:1:1001:10.1.1.1/32, next 1.1.12.1, label 0, metric 0, path 1

00:04:39: BGP:from:3 to:3 update format 1:1001:10.1.1.1/32 MDT grp 239.0.0.1 pfxptr->masklen 128

00:04:39: BGP(4): 10.1.2.1 send UPDATE (format) 2:2000:172.16.20.0/24, next 10.1.2.2, label 23, metric 0, path Local, extended community RT:2:20

00:04:39: BGP(4): 10.1.2.1 send UPDATE (format) 1:1011:172.16.1.0/24, next 1.1.12.1, label 16008, metric 0, path 1, extended community RT:1:200

00:04:39: BGP(4): 10.1.2.1 send UPDATE (format) 1:1001:10.10.10.10/32, next 1.1.12.1, label 16001, metric 0, path 1 65001, extended community RT:1:300

AS2-RR1#

00:04:39: BGP(4): updgrp 1 - 10.1.2.1 updates replicated for neighbors: 10.1.2.2

AS2-RR1#

PE1:

AS2-PE20#deb ip bgp vpnv4

Tag VPN debugging is on

AS2-PE20#

AS2-PE20#

*Sep 29 15:35:10.915: BGP: Incoming path from 100.100.2.1

*Sep 29 15:35:10.915: BGP: Accepted path from 100.100.2.1

*Sep 29 15:35:10.915: BGP: Incoming path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Incoming path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Accepted path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Incoming MDT from 100.100.2.1 : present

*Sep 29 15:35:10.951: BGP: Inform multicast system about mdt 232.0.0.1 from router-id 10.1.2.1 with next-hop 10.1.2.1 : present <---- Update received and processed

*Sep 29 15:35:10.951: BGP VPNV4: MPLS label changed for prefix 2:2:2001:10.1.2.1/32

*Sep 29 15:35:10.951: BGP VPNV4: bestpath from neighbor 100.100.2.1 nexthop 10.1.2.1 new outlabel exp-null

*Sep 29 15:35:10.951: BGP: Incoming path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Accepted path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Incoming MDT from 100.100.2.1 : present

*Sep 29 15:35:10.951: BGP: Inform multicast system about mdt 232.0.0.1 from router-id 10.1.2.1 with next-hop 1.1.12.1 : present

*Sep 29 15:35:10.951: BGP VPNV4: MPLS label changed for prefix 2:1:1011:10.1.1.1/32

*Sep 29 15:35:10.951: BGP VPNV4: bestpath from neighbor 100.100.2.1 nexthop 1.1.12.1 new outlabel exp-null

*Sep 29 15:35:10.951: BGP: Incoming path from 100.100.2.1

*Sep 29 15:35:10.951: BGP: Accepted path from 100.100.2.1

AS2-PE20#

*Sep 29 15:35:10.951: BGP: Incoming MDT from 100.100.2.1 : present

*Sep 29 15:35:10.951: BGP: Inform multicast system about mdt 239.0.0.1 from router-id 10.1.2.1 with next-hop 1.1.12.1 : present

*Sep 29 15:35:10.951: BGP VPNV4: MPLS label changed for prefix 2:1:1001:10.1.1.1/32

I'm out of idea here.. I attached my configuration for your reference.

Laurent.

Attachment: 
lbrooker Tue, 09/29/2009 - 19:57

Mate you are a star :o) I have downgraded the IOS to SRC2 and this worked perfectly. I am so happy now. I was wondering if you could pass our findings onto the Developers at Cisco so they could do a bug scrub on SRC4. I am now working on the Inter-AS side now, if I hit a problem I will open a new conversation. Thanks for all your help again.

Laurent Aubert Wed, 09/30/2009 - 07:37

Hi,

I'm glad it's working now. You should anyway migrate PE1 to a release which supports MDT AF so it will make your design consistent and avoid some headache ;-)

Btw only MDT AF support Inter-AS MVPN

Laurent.

lbrooker Wed, 09/30/2009 - 14:32

Hi,

reading the documentation on Inter-AS Multicast support i understand that the typ 2 is a non transitive extended community. I am going to use Cisco design option C using RRs. looks so much easier :o)

Laurent Aubert Wed, 09/30/2009 - 17:12

You don't have the choice as 12.3 doesn't support PIM Vector as well.

I'm curious, why do you need to have both implementation of MDT in your network ? Everything would be much easier of all your PE's and RRs support MDT.

Laurent.

lbrooker Wed, 09/30/2009 - 20:25

we have a range of routers from 3660s, 7200s with NPE-300s :o( To nice 7600s, GSR and 7200 NPE-G2s :o) geographically spread across all of australia,

lbrooker Wed, 09/30/2009 - 23:20

just looked at the document again and noticed that if you have option B or C you must have the proxy vector command(either in the VRF or otherwise). However 123.22 or 123.16a don't support either command :o(

Laurent Aubert Thu, 10/01/2009 - 04:55

PIM proxy Vector is required only if the PE loopbacks of the other AS are not redistributed into your IGP.

So if you are using option C and remote AS loopbacks are learned via BGP only then you need PIM proxy Vector.

HTH

Laurent.

lbrooker Thu, 10/01/2009 - 13:53

I will open another conversation here Laurent just im case other people are looking at this :o)

Actions

This Discussion