cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
942
Views
0
Helpful
2
Replies

MSDP peering issue when using VRF between different AS.

unfraget1
Level 1
Level 1

Hi all!

I have a problem with MSDP peering between AS in VRF

i using MSDP and e(M)MGP to interconnect PIM(SM)domain. for pim router i use cisco 7606MSDP.jpg

 

 

 

 

config on our side:

ip vrf Server_Cleaning
 description IPTV_sources
 rd 100:10721
 route-target export 100:10721
 route-target import 100:10721

interface Vlan1617
 description 354501
 ip vrf forwarding Server_Cleaning
 ip address 172.16.198.53 255.255.255.252
 no ip redirects
 ip pim dr-priority 0
 ip pim sparse-mode
 ip multicast boundary Telecom-2
 load-interval 30
end

router bgp 100
 address-family ipv4 multicast vrf Server_Cleaning
  neighbor 172.16.198.54 remote-as 200
  neighbor 172.16.198.54 update-source Vlan1617
  neighbor 172.16.198.54 activate
 exit-address-family

ip msdp vrf Server_Cleaning peer 172.16.198.54 connect-source Vlan1617 remote-as 200
ip msdp vrf Server_Cleaning description 172.16.198.54 Telecom
ip msdp vrf Server_Cleaning sa-filter in 172.16.198.54 list 157

Equipment and version OS

sh mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL124590U8
  2   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL09337HAN
  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL1025RZ00
  4    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SAD112307DN
  5    2  Route Switch Processor 720 (Active)    RSP720-3C-GE       JAE142107QC
  6    2  Route Switch Processor 720 (Hot)       RSP720-3C-GE       JAE14130EYO

Mod MAC addresses                       Hw   Fw            Sw           Status
--- ---------------------------------- ----- ------------- ------------ -------
  1  0021.a04a.b8e8 to 0021.a04a.b917  3.0   12.2(18r)S    15.4(3)      Ok
  2  0014.f2f9.98dc to 0014.f2f9.990b  2.3   12.2(14r)S    15.4(3)      Ok
  3  0018.1854.e62c to 0018.1854.e65b  2.5   12.2(14r)S    15.4(3)      Ok
  4  001b.d4ab.866c to 001b.d4ab.866f  2.6   12.2(14r)S    15.4(3)      Ok
  5  0023.eb0e.36e4 to 0023.eb0e.36e7  5.9   12.2(33r)SRD  15.4(3)      Ok
  6  0023.eb0d.e4e8 to 0023.eb0d.e4eb  5.9   12.2(33r)SRD  15.4(3)      Ok


isco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 15.4(3)S, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Sun 27-Jul-14 14:14 by prod_rel_team

ROM: System Bootstrap, Version 12.2(33r)SRD5, RELEASE SOFTWARE (fc1)
BOOTLDR: Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 15.4(3)S, RELEASE SOFTWARE (fc3)

 

signaling protocol is up

MSDP Peer 172.16.198.54 (?), AS 200(configured AS)
  Connection status:
    State: Up, Resets: 7, Connection source: Vlan1617 (172.16.198.53)
    Uptime(Downtime): 00:01:32, Messages sent/received: 2/13
    Output messages discarded: 0
    Connection and counters cleared 1d02h    ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Number of connection transitions to Established state: 8
    Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled
  Message counters:
    RPF Failure count: 12
    SA Messages in/out: 12/0
    SA Requests in: 0
    SA Responses out: 0
    Data Packets in/out: 0/0

sh ip pim vrf Server_Cleaning neighbor  | i 172.16.198.54
172.16.198.54     Vlan1617                 00:00:56/00:01:18 v2    1 / DR P G

bgp peer from AS200 announces to me prefix by RP and source network

sh bgp vpnv4 multicast vrf Server_Cleaning *> xx.xx.0.0/29 172.16.198.54 0 200 500i *> xxx.xx.238.111/32 172.16.198.54 0 200 500i routes installed into MRIB
sh ip route multicast vrf Server_Cleaning bgp xx.xx.0.0/29 is subnetted, 1 subnets B xx.xx.154.0 [20/0] via 172.16.198.54 (Server_Cleaning), 00:01:06 xx.xx.238.0/32 is subnetted, 1 subnets B xx.xx.238.111 [20/0] via 172.16.198.54 (Server_Cleaning), 00:01:06

however MSDP the RPF check fails?

 

172.16.198.54: Received 164-byte msg 42157 from peer
172.16.198.54: SA TLV, len: 164, ec: 13, RP: xx.xx.238.111
172.16.198.54: Peer RPF check failed for xx.xx.238.111, used IBGP route's peer 0.0.0.0

 

Why is this happening?
all the conditions

Rule 2 of RPF Checking of SA Messages in MSDP
Rule 2 of RPF checking in MSDP is applied when the sending MSDP peer is also an e(M)BGP peer. When Rule 2 is applied, the RPF check proceeds as follows:

The peer searches the BGP MRIB for the best path to the RP that originated the SA message. If a path is not found in the MRIB, the peer then searches the URIB. If a path is still not found, the RPF check fails.
If the previous search succeeds (that is, the best path is found), the peer then examines the path. If the first autonomous system in the best path to the RP is the same as the autonomous system of the e(M)BGP peer (which is also the sending MSDP peer), then the RPF check succeeds; otherwise it fails.
Implications of Rule 2 of RPF Checking on MSDP
The MSDP topology must mirror the (M)BGP topology. In general, wherever there is an e(M)BGP peer connection between two routers, an MSDP peer connection should be configured. As opposed to Rule 1, the IP address of the far-end MSDP peer connection does not have to be the same as the far-end e(M)BGP peer connection.The reason that the addresses do not have to be identical is that BGP topology between two e(M)BGP peers is not described by the AS path.

are met

 

2 Replies 2

unfraget1
Level 1
Level 1

in the debug output msdp show "IBGP route's peer 0.0.0.0"

really default route learned through IBGP have in URIB vrf table, but the RFP must first check the MRIB first and if route to RPnot found then check URIB.
likely that RPF perform prefix lookup in URIB (and of course it was not found) and don't look up in MRIB. 

You any suggestions on this issue?