inter-AS mVPN

[starman10]

Is there any way to implement inter-AS mVPN without mdt address-familly support on PE routers?

[mikedavi1]

I'd assumed you meant mGRE. The mGRE build is a function of vrf/mdt config, not MDT AFI support. So, it seems to me that you don't need to know the other PE IP addresses, just throw all mcast traffic down the tunnel and it should arrive, no?

At least that's my theory.... ;-)

[Harold Ritter]

Mike,

The RPF check should not be an issue as long as the multicast traffic source address is known via a BGP NH equal to neighbor address on the tunnel interface. You do not need to configure a static mroute for this to work.

Hope this helps,

[Harold Ritter]

Oops,

I should have been more specific. It won't be an issue if you are doing InterAs with option 10c.

Hope this helps,

[mikedavi1]

The issue I'm getting at is where the pim neighbor address seen in the vrf (remote PE global Loopback) fails rpf. For example, R6 receives pim hellos from 17.17.0.4 via the mdt interface. Since 17.17.0.4 is not known in the vrf, rpf for the neighbor fails.

So my suggested mroute on R6 would be something like:

ip mroute vrf ABC2 17.17.0.4 255.255.255.255 tun1 where tun1 is the mdt on R6.

Hope this makes more sense.

[Harold Ritter]

Mike,

This is exactly the scenario I had in mind when I said it is not an issue if you are using InterAS with option 10c. The BGP next-hop of your VPNv4 prefix should be the same as your PIM neighbor address on the tunnel interface.

Obviously, this is different if you use option 10a or 10b as 17.17.0.4 is most probably not known to the egress PE.

Cheers,

[Harold Ritter]

Sorry,

I misunderstood your point. You are referring to the RPF check failure on default MDT itself (p-domain) rather than on the customer traffic (c-domain). Again this will not be an issue if you are doing option 10c as the egress PE learns loopback interfaces addresses for PEs in the remote AS.

This is obviously an issue if you deploy option 10a or 10b without the MDT SAFI.

Cheers,

[Harold Ritter]

Ales,

Thanks for the info. I just wanted to make sure you had a configured RP.

Does R4 register? R6 should indeed register as soon as you configure the MDT default. Can you do a "show ip pim rp map" on R4.

Thanks,

[starman10]

R6 did register, but R4 didn't:

r6#sh ip mro

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 230.1.1.1), 00:00:04/00:02:55, RP 17.17.0.2, flags: SJCZ

Incoming interface: FastEthernet0/0.26, RPF nbr 17.17.26.2, Mroute

Outgoing interface list:

MVRF ABC1, Forward/Sparse, 00:00:04/00:02:55

(*, 224.0.1.40), 00:00:04/00:02:55, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Loopback0, Forward/Sparse, 00:00:04/00:02:55

r6#

r4#sh ip mro

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 1d02h/00:03:02, RP 17.17.0.4, flags: SJCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Loopback0, Forward/Sparse, 1d02h/00:02:08

FastEthernet0/0.45, Forward/Sparse, 1d02h/00:03:02

r4#

R4 has statically configured RP, R6 in another AS has dynamically assigned RP:

r6#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 17.17.0.2 (?), v2

Info source: 17.17.0.2 (?), via bootstrap, priority 0, holdtime 210

Uptime: 4d03h, expires: 00:03:24

r6#ő

r4#

r4#sh ip pim rp ma

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

RP: 17.17.0.4 (?)

r4#

[Harold Ritter]

Interesting. Can you please post the entire config for R4.

Thanks,

[Harold Ritter]

Ales,

Could you confirm whether the tunnel interface was created or not (sh ip int brief and then show int tuX for the specific tunnel).

Thanks,

[starman10]

Tunnel interface was not created.

Anyway, I found the solution. I changed the IOS sw of R4 to the one of R6 and R4 registered to MDT default normally :-) So it was the IOS sw issue :-(

[Harold Ritter]

Ales,

Glad you solved the issue. Thanks for the feedback.

[starman10]

Thank you for your help.