05-07-2007 02:54 AM
Is there any way to implement inter-AS mVPN without mdt address-familly support on PE routers?
05-08-2007 09:10 AM
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.... ;-)
05-08-2007 10:09 AM
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,
05-08-2007 10:21 AM
Oops,
I should have been more specific. It won't be an issue if you are doing InterAs with option 10c.
Hope this helps,
05-08-2007 08:02 PM
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.
05-09-2007 03:14 AM
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,
05-09-2007 03:23 AM
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,
05-08-2007 09:57 AM
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,
05-08-2007 11:24 AM
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#
05-08-2007 02:19 PM
Interesting. Can you please post the entire config for R4.
Thanks,
05-09-2007 06:51 AM
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,
05-09-2007 07:42 AM
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 :-(
05-09-2007 07:52 AM
Ales,
Glad you solved the issue. Thanks for the feedback.
05-09-2007 11:03 AM
Thank you for your help.
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: