Leaking MPLS VPN learned routes from VRF to Global

I'm trying to leak routes from a VRF to global. I can get the routes leaked from directly connected CE to the global, however I can't get the routes from remote CE's to leak in to the global routing table. Below are my configurations
RP/0/0/CPU0:B25BR1#sh run vrf TR
Wed Dec 17 22:40:33.772 UTC
vrf TR
 address-family ipv4 unicast
  import route-target
   65000:7020
  export to default-vrf route-policy TR-2-GLOBAL
  export route-target
   65000:7020
RP/0/0/CPU0:B25BR1#sh rpl route-policy TR-2-GLOBAL
Wed Dec 17 22:40:50.851 UTC
route-policy TR-2-GLOBAL
  if destination in TR-2-GLOBAL then
    pass
  endif
end-policy
RP/0/0/CPU0:B25BR1#sh rpl prefix-set TR-2-GLOBAL
Wed Dec 17 22:40:57.861 UTC
prefix-set TR-2-GLOBAL
  192.168.0.17/32,
  192.168.0.18/32,
  192.168.0.19/32,
  192.168.0.20/32
end-set
!Routes that I want to see also are  192.168.0.19/32 and 192.168.0.20/32 which are there in the VRF routing table
RP/0/0/CPU0:B25BR1#sh route vrf TR
Wed Dec 17 22:41:45.767 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR
       A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
B    10.1.0.0/30 [20/0] via 10.1.0.5, 00:14:32
C    10.1.0.4/30 is directly connected, 06:57:19, GigabitEthernet0/0/0/2
L    10.1.0.6/32 is directly connected, 06:57:19, GigabitEthernet0/0/0/2
B    10.1.128.0/30 [20/0] via 10.1.0.5, 00:14:32
B    192.168.0.17/32 [20/0] via 10.1.0.5, 00:13:56
B    192.168.0.18/32 [20/0] via 10.1.0.5, 00:13:56
B    192.168.0.19/32 [200/0] via 192.168.0.4 (nexthop in vrf default), 00:13:31
B    192.168.0.20/32 [200/0] via 192.168.0.4 (nexthop in vrf default), 00:13:31
RP/0/0/CPU0:B25BR1#sh ip rou
Wed Dec 17 22:41:50.097 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR
       A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
S    10.0.0.0/27 is directly connected, 08:04:01, Null0
O    10.0.0.4/30 [110/2] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
C    10.0.0.8/30 is directly connected, 08:04:00, GigabitEthernet0/0/0/0
L    10.0.0.10/32 is directly connected, 08:04:00, GigabitEthernet0/0/0/0
O    10.0.0.12/30 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                  [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    10.0.0.16/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    10.0.0.24/30 [110/3] via 10.0.128.9, 06:29:14, GigabitEthernet0/0/0/1
O    10.0.0.28/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
S    10.0.128.0/29 is directly connected, 08:04:01, Null0
O    10.0.128.0/30 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                   [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    10.0.128.4/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
C    10.0.128.8/30 is directly connected, 08:04:00, GigabitEthernet0/0/0/1
L    10.0.128.10/32 is directly connected, 08:04:00, GigabitEthernet0/0/0/1
S    10.1.0.4/30 is directly connected, 06:57:23, Null0
S    10.1.128.4/30 is directly connected, 08:04:01, Null0
C    10.18.0.0/16 is directly connected, 08:04:00, MgmtEth0/0/CPU0/0
L    10.18.0.9/32 is directly connected, 08:04:00, MgmtEth0/0/CPU0/0
L    127.0.0.0/8 [0/0] via 0.0.0.0, 08:04:04
O    192.168.0.1/32 [110/2] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
O    192.168.0.2/32 [110/4] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/4] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    192.168.0.3/32 [110/3] via 10.0.128.9, 08:03:40, GigabitEthernet0/0/0/1
O    192.168.0.4/32 [110/3] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    192.168.0.5/32 [110/4] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/4] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    192.168.0.6/32 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    192.168.0.7/32 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
L    192.168.0.8/32 is directly connected, 08:04:00, Loopback0
B    192.168.0.17/32 [20/0] via 10.1.0.5 (nexthop in vrf TR), 00:05:37
B    192.168.0.18/32 [20/0] via 10.1.0.5 (nexthop in vrf TR), 00:05:37
I'm only seeing the routes from the directly connected CE, but not the routes received from RR. What am I missing here?
Thanks!
-Sajith

I'm trying to leak routes from a VRF to global. I can get the routes leaked from directly connected CE to the global, however I can't get the routes from remote CE's to leak in to the global routing table. Below are my configurations
RP/0/0/CPU0:B25BR1#sh run vrf TR
Wed Dec 17 22:40:33.772 UTC
vrf TR
 address-family ipv4 unicast
  import route-target
   65000:7020
  export to default-vrf route-policy TR-2-GLOBAL
  export route-target
   65000:7020
RP/0/0/CPU0:B25BR1#sh rpl route-policy TR-2-GLOBAL
Wed Dec 17 22:40:50.851 UTC
route-policy TR-2-GLOBAL
  if destination in TR-2-GLOBAL then
    pass
  endif
end-policy
RP/0/0/CPU0:B25BR1#sh rpl prefix-set TR-2-GLOBAL
Wed Dec 17 22:40:57.861 UTC
prefix-set TR-2-GLOBAL
  192.168.0.17/32,
  192.168.0.18/32,
  192.168.0.19/32,
  192.168.0.20/32
end-set
!Routes that I want to see also are  192.168.0.19/32 and 192.168.0.20/32 which are there in the VRF routing table
RP/0/0/CPU0:B25BR1#sh route vrf TR
Wed Dec 17 22:41:45.767 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR
       A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
B    10.1.0.0/30 [20/0] via 10.1.0.5, 00:14:32
C    10.1.0.4/30 is directly connected, 06:57:19, GigabitEthernet0/0/0/2
L    10.1.0.6/32 is directly connected, 06:57:19, GigabitEthernet0/0/0/2
B    10.1.128.0/30 [20/0] via 10.1.0.5, 00:14:32
B    192.168.0.17/32 [20/0] via 10.1.0.5, 00:13:56
B    192.168.0.18/32 [20/0] via 10.1.0.5, 00:13:56
B    192.168.0.19/32 [200/0] via 192.168.0.4 (nexthop in vrf default), 00:13:31
B    192.168.0.20/32 [200/0] via 192.168.0.4 (nexthop in vrf default), 00:13:31
RP/0/0/CPU0:B25BR1#sh ip rou
Wed Dec 17 22:41:50.097 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR
       A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
S    10.0.0.0/27 is directly connected, 08:04:01, Null0
O    10.0.0.4/30 [110/2] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
C    10.0.0.8/30 is directly connected, 08:04:00, GigabitEthernet0/0/0/0
L    10.0.0.10/32 is directly connected, 08:04:00, GigabitEthernet0/0/0/0
O    10.0.0.12/30 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                  [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    10.0.0.16/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    10.0.0.24/30 [110/3] via 10.0.128.9, 06:29:14, GigabitEthernet0/0/0/1
O    10.0.0.28/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
S    10.0.128.0/29 is directly connected, 08:04:01, Null0
O    10.0.128.0/30 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                   [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    10.0.128.4/30 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
C    10.0.128.8/30 is directly connected, 08:04:00, GigabitEthernet0/0/0/1
L    10.0.128.10/32 is directly connected, 08:04:00, GigabitEthernet0/0/0/1
S    10.1.0.4/30 is directly connected, 06:57:23, Null0
S    10.1.128.4/30 is directly connected, 08:04:01, Null0
C    10.18.0.0/16 is directly connected, 08:04:00, MgmtEth0/0/CPU0/0
L    10.18.0.9/32 is directly connected, 08:04:00, MgmtEth0/0/CPU0/0
L    127.0.0.0/8 [0/0] via 0.0.0.0, 08:04:04
O    192.168.0.1/32 [110/2] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
O    192.168.0.2/32 [110/4] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/4] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    192.168.0.3/32 [110/3] via 10.0.128.9, 08:03:40, GigabitEthernet0/0/0/1
O    192.168.0.4/32 [110/3] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    192.168.0.5/32 [110/4] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/4] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
O    192.168.0.6/32 [110/2] via 10.0.128.9, 08:03:51, GigabitEthernet0/0/0/1
O    192.168.0.7/32 [110/3] via 10.0.0.9, 08:03:10, GigabitEthernet0/0/0/0
                    [110/3] via 10.0.128.9, 08:03:10, GigabitEthernet0/0/0/1
L    192.168.0.8/32 is directly connected, 08:04:00, Loopback0
B    192.168.0.17/32 [20/0] via 10.1.0.5 (nexthop in vrf TR), 00:05:37
B    192.168.0.18/32 [20/0] via 10.1.0.5 (nexthop in vrf TR), 00:05:37
I'm only seeing the routes from the directly connected CE, but not the routes received from RR. What am I missing here?
Thanks!
-Sajith

Similar Messages

  • Problem leaking route from VRF to global table on CSR 1000V

    Hi Guys,
    So I have a problem with VRF's on a CSR 1000V, specifically exporting a connected subnet from a VRF into the global routing table.
    My config, very abbreviated, is as follows:
    Router:
    GE1: 10.0.0.1/31 VRF TEST
    GE2: 172.30.20.1/24 (No VRF, BGP neighbor to 172.30.20.2, receiving 0.0.0.0/0 (default route))
    Now sh ip route displays:
    0.0.0.0/0 (BGP)
    172.30.20.1/24 (Connected)
    sh ip route vrf TEST displays:
    0.0.0.0/0 (BGP)
    10.0.0.1/31 connected
    My VRF config is as follows:
    ip vrf TEST
    rd 1:1
    import ipv4 unicast map GLOBAL
    export ipv4 unicast map CONNECTED-SUBNET
    ip prefix-list CONNECTED seq 1 permit 10.0.0.1/31
    ip prefix-list DEFAULT   seq 1 permit 0.0.0.0/0
    route-map CONNECTED-SUBNET permit 10
     match ip address prefix-list CONNECTED
    route-map GLOBAL permit 10
     match ip address prefix-list DEFAULT
    Now my import command works perfectly (0.0.0.0/0 is imported from BGP into the VRF's routing table), however my export command does not function - seemingly at all.
    Even though my prefix list is an exact match, I do not see 10.0.0.1/31 appearing in the global routing table, or the BGP table at all (show ip bgp 10.0.0.1 shows only the 0.0.0.0/0 default route)
    Any thoughts on what is going on here? Am I misunderstanding the export command for VRF's? I was under the impression this will export directly to the BGP table, and then be imported to the global routing table if applicable?
    Any thoughts/input would be appreciated!

    Hello
    "GE1: 10.0.0.1/31 VRF TEST
    GE2: 172.30.20.1/24 (No VRF, BGP neighbor to 172.30.20.2, receiving 0.0.0.0/0 (default route))"
    I must have misunderstood somewhere  I was assuming you had no vrf bgp between GE1-2 , and just vrf on subnet 10.0.0.0/x which needed to be advertised in the global routing table hence my last post suggested you redistribute into bgp,
    So assuming you are accepting a default route from GE2 it went like this
    GE1
    int fa0/1
    ip vrf forwading TEST
    ip addresses 10.0.0.1 255.255.255.255
    int xx
    ip address 172.30.20.1 255.255.255.0
    router bgp xy
    neighbour 172.30.20.2 remote-as yx
    redistribute static ( to advertised the vrf subnet to GE2)
    ip route 10.0.0.1 255.255.255.255 fa0/1 ( this is tell the global rib where to go for the vrf route)
    ip prefix-list VRF  permit 0.0.0.0/0
    route-map VRF_rm
    match ip address prefix VRF ( match on the default route advertised from GE2 which is in the global rib)
    ip vrf TEST
    import-map ipv4 vrf VRF-rm ( import the default from global rib into the vrf rib)
    res
    Paul

  • Route leaking from VRF to Global on same router with VLAN interface

    Hi all,
    I would like to do some route leaking from VRF to Global and Global to VRF on the same router. Here is an output of the config:
    interface FastEthernet4
    description ***Connection to WAN***
    ip vrf forwarding FVRF
    ip address 10.0.0.6 255.255.255.0
    interface Vlan100
    description ***LAN***
    ip address 192.168.227.1 255.255.255.0
    So what I want is to import 192.168.227.0 /24 into FVRF and import 10.0.0.0 /24 into the global routing table.
    I though I could do that config but it is not possible:
    (config)#ip route vrf FVRF 192.168.227.0 255.255.255.0 vlan 100
    % For VPN or topology routes, must specify a next hop IP address if not a point-to-point interface
    OR
    DK-SLVPN(config)#ip route vrf FVRF 192.168.227.0 255.255.255.0 vlan 100 192.168.227.1 global
    %Invalid next hop address (it's this router)
    Any ideas are really welcome.
    Best regards,
    Laurent

    Hi,
    I have tried the following solution:
    Add 10.0.0.0 /24 From VRFto Global:
    ip route 10.0.0.0 255.255.255.0 FastEthernet4
    Add 192.168.227.0 /24 from Global to VRF:
    router bgp 64512
    bgp log-neighbor-changes
    address-family ipv4
      no synchronization
      redistribute connected
      no auto-summary
    exit-address-family
    ip prefix-list Global-VRF seq 5 permit 192.168.227.0/24
    route-map Global permit 10
    match ip address prefix-list Global-VRF
    ip vrf FVRF
      rd 1:1
      import ipv4 unicast map Global
    So now the VRF table looks like that:
    #      sh ip route vrf FVRF
    C        10.0.0.0/24 is directly connected, FastEthernet4
    S        10.0.0.1/32 [254/0] via 10.0.0.1, FastEthernet4
    L        10.0.0.6/32 is directly connected, FastEthernet4
    B     192.168.227.0/24 is directly connected, 00:15:12, Vlan100
    The Global table looks like this:
    #sh ip route
    Gateway of last resort is 10.1.0.107 to network 0.0.0.0
    D*    0.0.0.0/0 [90/1709056] via 10.1.0.107, 3d02h, Tunnel1
           10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
    S        10.0.0.0/24 is directly connected, FastEthernet4
    C        10.1.0.0/24 is directly connected, Tunnel1
    L        10.1.0.227/32 is directly connected, Tunnel1
    C        10.2.0.0/24 is directly connected, Tunnel2
    L        10.2.0.227/32 is directly connected, Tunnel2
    C        10.10.10.227/32 is directly connected, Loopback100
           192.168.227.0/24 is variably subnetted, 2 subnets, 2 masks
    C        192.168.227.0/24 is directly connected, Vlan100
    L        192.168.227.1/32 is directly connected, Vlan100
    But When I try to ping it still doesn´t work:
    #ping vrf FVRF 192.168.227.1 source fastEthernet 4
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.227.1, timeout is 2 seconds:
    Packet sent with a source address of 10.0.0.6
    Success rate is 0 percent (0/5)
    #ping 10.0.0.1 source vlan 100
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
    Packet sent with a source address of 192.168.227.1
    Success rate is 0 percent (0/5)
    Any ideas?
    Regards,
    Laurent

  • Redundant access from MPLS VPN to global routing table

    Several our customers have MPLS VPNs deployed over our infrastructure. Part of them requires access to Internet (global routing table in our case).
    As I'm not aware of any methods how to dynamicaly import/export routes between VRF/Global routing tables, at the moment there are static routes configured - one inside VRF pointing to global next hop, another one in global routing table, pointing to interface inside VRF.
    Task is to configure redundant access to Internet. By redundancy I mean using several exit points (primary and backup), what physically represents separate boxes.
    Here comes tricky part - both global static routes (on both boxes, meaning) are valid and reachable in all cases - no matter if specific prefix is reachable in VRF or not. What I'd like to achieve is that specific static route becomes valid only if specific prefix is reachable inside VRF. Yea, sounds like dynamic routing :), I know
    OK, hope U got the idea. Any solutions/recommendations ? Running all Internet routing inside VRF isn't an option, at least for now :(

    Hi Andris,
    I did not mean to have a VRF on the CE. The CE would have both PVCs in the global routing table - his ONLY routing table in fact. One PVC would be used to announce routes into the customer specific VPN (VRF configured on the PE). The other PVC would allow for internet access through the PE (global IP routing table on the PE).
    dot1q will be ok as well.
    This way the CE can be a normal BGP peer to the PE, i.e. there is no MPLS VPN involved here. This allows all options of customer-ISP connectivity.
    Example:
    PE config:
    interface Serial0/0
    encapsulation frame-relay
    interface Serial0/0.1 point-to-point
    description customer VPN access
    ip vrf customer
    ip address 10.1.1.1 255.255.255.252
    interface Serial0/0.2 point-to-point
    description customer Internet access
    ip address 192.168.1.1 255.255.255.252
    router rip
    address-family ipv4 vrf customer
    version 2
    network 10.0.0.0
    no auto-summary
    redistribute bgp 65000 metric 5
    router bgp 65000
    neighbor 192.168.1.2 remote-as 65001
    address-family ipv4 vrf customer
    redistribute rip
    CE config:
    interface Serial0/0
    encapsulation frame-relay
    interface Serial0.1 point-to-point
    description VPN access
    ip address 10.1.1.2 255.255.255.252
    interface Serial0.2 point-to-point
    description Internet access
    ip address 192.168.1.2 255.255.255.252
    router bgp 65001
    neighbor 192.168.1.1 remote-as 65000
    router rip
    version 2
    network 10.0.0.0
    no auto-summary
    Of course you can replace RIP with whatever is suitable for you. And don´t sue me when you do not apply required BGP filters for internet access... ;-)
    The other option ("mini internet") would be feasible as well. Just make sure your BGP filters are NEVER messed up and additionally apply a limit on the numbers of prefixes in your VRF mini-internet.
    Regards
    Martin

  • Selective Route Import/Export in MPLS VPN

    Champs
    I have multiple brach locations and 3 DC locations.DC locations host my internal applications , DC's  also have central Internet breakout for the region. My requirement is to have full mesh MPLS-VPN but at same time brach location Internet access should be from nearest IDC in the region  if nearest IDC is not availalbe it should go to second nearest DC for internet.I have decided which are primary and seconday DC for Internet breakout. How can this be achieved in MPLS-VPN scenario.Logically i feel , i have to announce specific LAN subnet and default route(with different BGP attribute like AS Path)  from all 3 DCs. Spokes in the specific region should be able to import default route  from primary DC and secondary DCs only  using some route filter?
    Regards
    V

    Hello Aaron,
    the route example works for all routers except the one, where the VRF vpn2 is configured. What you can do for management purposes is either to connect through a neighbor router using packet leaking or configure another Loopback into VRF vpn2.
    The last option (and my recommendation) is to establish another separate IP connection from your NMS to the MPLS core. Once VRFs are failing (for whatever reason, f.e. erroneously deleted) you might just not get connectivity to your backbone anymore to repair what went wrong.
    So I would create an "interconnection router" with an interface in the VRF vpn2 and one interface in global IP routing table. This way you will still be able to access PEs, even if VRFs or MBGP is gone.
    Hope this helps! Please rate all posts.
    Regards, Martin

  • Injecting Global default Routes into a MPLS VPN

    Hi,
    I have a PE router running MPBGP which receives two default routes to the internet through an IPV4 BGP session. I need to import these routes in to a VRF and export them to different customer VRFs so that these VRFs are able to access Internet.
    I have used the feature called "BGP Support for IP Prefix Import from Global Table into a VRF Table" (URL:http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00803b8db9.html#wp1063870)
    and imported these routes into a VRF.
    The issue is these routes are not propagated to any of the other PE routers which has customer VRFs configured.
    Has anybody tried this or a similar method to inject a dynamic default route into a MPLS VPN.
    Any suggestions would be highly appreciated.
    Thanks
    Subhash

    Hi Subhash,
    is there anything preventing you from terminating your internet BGP sessions in a VRF? Then everything should go smoothly, i.e. standard VRF import/export.
    So possibility A) create a VRF Internet, move bgp neighbor commands there and use filters preventing anything but the default route, then use route targets to distribute the default route into other VRFs.
    Possibility B) use static routing with packet leaking. Could look like this:
    ip route vrf Internet 0.0.0.0 0.0.0.0 global
    ip route vrf Internet 0.0.0.0 0.0.0.0 global 250
    ip route Serial0/0 !assuming this is where the customer router connects.
    Note: the BGP peer IP does not have to be directly connected! There has to be a LDP label for it though. so include your BGP peers network into your IGP and the backup will work, when you loose the link to the peer.
    Hope this helps! Please rate all posts.
    Regards, Martin

  • Please Help!! - Ping to and from MPLS/VPN

    I am having strange ping results and cannot understand why. My gut feeling is that this stems from a lack of understanding of the technology.
    First, I have leaked a Vrf subnet into the global vrf so that I can have reachability to some devices in the vrf and the devices themselves can have reachability to services outside of the cloud.
    I know this design is going to seem a little convoluted so bear with me. I have built a model of my providers network whereby the connected routes between the CE and PE are public addresses, the internal routes are private addresses in the 10.0.0.0/8 network. I am running BGP between the PE and CE, and then redistributing static routesinto OSPF for the actual MPLS network routing.
    Then of the backbone (Area 0) of the OSPF network, I have a connection to what I will call my Services network where resources such as DNS/DHCP, Internet, and Call Manager reside.(See diagram).
    What happens is that on the PE that is directly connected to the CE, I cannot ping the network contained in the CE unless I actually specify an interface other than the address of the directly connected interface.
    If I go to the P router I can ping just fine. Even if I go to the Services network I am successful so I know that I have been somewhat successful in leaking the subnet located in the VPN vrf.
    On the flip side, When I am in the CE, I cannot ping to the Services network, or any network that is in the 10.0.0.0/8 space, so I am almost certain there is a routing principle that I am missing here.
    Sorry for the long post, but I am trying to include the pertinent information that I hope will lead to some assistance.

    Lejoe,
    You were correct in discovering that the route was missing from the 3750 metro point back to the connected route between the PE and CE. I added this and I am not able to ping the services network from the CE router. Thanks very much for this. I am glad it was a simple resolution.
    As far as the duplicate address on the 3750 Metro and the PE, the interface on the 3750 was left over from a previous design and is inactive. Thanks for catching as I would need to clean it up regardless.
    You were also correct in saying that if I source the ping from within the vrf, then I am able to ping. However, I thought that I took care of this by leaking the route to the global config. Here is the global ruoting table on the PE router.
    S 68.139.201.28/30 is directly connected, FastEthernet1/0
    C 68.1.1.4/30 is directly connected, FastEthernet0/0
    O IA 68.2.1.4/30 [110/12] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.1.2.4/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.1.0.1/32 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0
    C 68.1.1.1/32 is directly connected, Loopback0
    O IA 68.0.1.0/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.2.1.1/32 [110/13] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.0.2.0/30 [110/3] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.2.0.1/32 [110/3] via 68.1.1.5, 23:30:42, FastEthernet0/0
    O IA 68.255.1.0/30 [110/2] via 68.1.1.5, 23:30:42, FastEthernet0/0
    10.0.0.0/16 is subnetted, 1 subnets
    S 10.152.0.0 [1/0] via 68.139.201.30, FastEthernet1/0
    O*E2 0.0.0.0/0 [110/1] via 68.1.1.5, 23:30:42, FastEthernet0/0
    If you take a look at the configs, I have placed the directly connected route into the global table by using a static route on the PE router:
    ip route 68.139.201.28 255.255.255.252 FastEthernet1/0
    I would like to understand why I cannot ping the directly connected route from the PE, especially when it is in the routing table. Would you know why this is?

  • GRE with VRF on MPLS/VPN

    Hi.
    Backbone network is running MPLS/VPN.
    I have one VRF (VRF-A) for client VPN network.
    One requirement is to configure another VRF (VRF-B) for this client for a separate public VRF connection.
    Sub-interfacing not allowed on CE-to-PE due to access provider limitation.
    So GRE is our option.
    CE config:
    Note: CE is running on global. VRF-A is configured at PE.
    But will add VRF-B here for the  requirement.
    interface Tunnel0
      ip vrf forwarding VRF-B
    ip address 10.12.25.22 255.255.255.252
    tunnel source GigabitEthernet0/1
    tunnel destination 10.12.0.133
    PE1 config:
    interface Tunnel0
    ip vrf forwarding VRF-B
    ip address 10.12.25.21 255.255.255.252
    tunnel source Loopback133
    tunnel destination 10.12.26.54
    tunnel vrf VRF-A
    Tunnel works and can ping point-to-point IP address.
    CE LAN IP for VRF-B  is configured as static route at PE1
    PE1:
    ip route vrf VRF-B 192.168.96.0 255.255.255.0 Tunnel0 10.12.25.22
    But from PE2 which is directly connected to PE1 (MPLS/LDP running), connectivity doesnt works.
    From PE2:
    - I can ping tunnel0 interface of PE1
    - I cant ping tunnel0 interface of CE
    Routing is all good and present in the routing table.
    From CE:
    - I can ping any VRF-B loopback interface of PE1
    - But not VRF-B loopback interfaces PE2 (even if routing is all good)
    PE1/PE2 are 7600 SRC3/SRD6.
    Any problem with 7600 on this?
    Need comments/suggestions.

    Hi Allan,
    what is running between PE1 and PE2 ( what I mean is any routing protocol).
    If No, then PE2 has no ways of knowing GRE tunnel IP prefixes and hence I suppose those will not be in its CEF table...
    If Yes, then check are those Prefixes available in LDP table...
    Regards,
    Smitesh

  • Managing Route-Map based MPLS VPN

    1) How to derive the VPN information of the MPLS VPN configured using route-maps? As I understand, stitching route-maps information to derive VPN is complex as it is difficult to derive & correlate the filters tied to each of the route-maps that are tied to a VRF :(
    2) Is there any MIB to get from the MIB
    a) Route-maps tied to each VRF
    b) What is the filter associated with each route-map?
    c) Definition of each of the above filter
    It would have been nice if the route-maps' name had global-significance within AS, so that we could have treated route-maps, pretty much like the route-tragets. Alas, I doubt it is :(
    It should be noted here that if the MPLS VPN is configured using route targets, the VPN information derivation is fairly straight forward throught MplsVpn MIB.
    So, the question is what is the simplest way to derive the MPLS VPN info given that they are configured using route-maps in BGP for labelled-route-distribution & for the pkt association with the VRFs.
    Thanks,
    Suresh R

    Each CE in a customer VPN is also added to the management VPN by selecting the Join the management VPN option in the service request user interface.
    The function of the management route map is to allow only the routes to the specific CE into the management VPN. The Cisco IOS supports only one export route map and one import route map per VRF.
    http://www.cisco.com/en/US/products/sw/netmgtsw/ps4748/products_user_guide_chapter09186a0080353ac3.html

  • Filtering OSPF routes from MPBGP to BGP speaker in the same VRF

    I'm wondering if anyone has some ideas they an share on this.
    Assume the following:
    - CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
    - PE1 is mutually redistributing CE1's OSPF table with MPBGP
    - PE1 exchanges MPBGP routes with PE2.
    - PE2 is mutually redistributing CE2's OSPF table with MPBGP
    - CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo
    So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process.  Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.
    Is there any way to filter those out?  I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.

    are you sure you are using iBGP on both sides and not eBGP?
    I'm asking because routes learnt by PE1 from CE via iBGP ( meaning same BGP AS number on CE1 and PE1 vrf foo) will not be propagated to CE2, because an iBGP route learned by a BGP speaker in not pushed to another iBGP speaker.
    So it means that a show ip bgp neighbor vrf foo advertised routes on PE2 shall  show that no routes from CE1 are being advertised to CE2.
    As mentionned earlier, changing BGP admin distance is an option. Let BGP have a better distance on your CEs and this should do the trick :
    router bgp xxx
    distance bgp 20 20 20
    Then after clearing bgp session, the rib failures are gone as OSPF is AD 110 and BGP is now AD 20 ( also remember that BGP does not annouces rib failure routes to other BGP peers)
    cheers

  • Filtering methods inside a VRF in MPLS VPN

    Hi,
    we have a network with MPLS VPN and several VRFs involved.
    Inside a certain VRF I need to avoid that two particular networks can talk to each other.
    Can you give me a hint of what can be a solution to implement this ?
    Thanks
    Regards
    Marco

    Hi Marco,
    To prevent connectivity between two networks where a MPLS VPN is involved you can apply the same methods as in a "normal" router network. Just think of the complete MPLS VPN (PE to PE) as being one big "router simulator".
    You could either implement ACLs on the interfaces connecting to the PE or filter routing updates between sites - depending on your topology. When filtering routing updates seems the way to go, you should also have a look into selective import or export. With the help of a route-map one can selectively insert single networks into a VPN by selectively attaching route-targets to BGP updates.
    Regards, Martin

  • Configuring MPLS VPN using static routing

    Hi,
    I am managed to set up a BGP/MPLS VPN in a laboratory using CS3620 routers running IOS 12.2(3) with ISIS. I am thinking of using static routes among the PE and P routers instead of a IGP. Does anyone know if Cisco routers supports static configuration of LSP? I have tried but could not get it work.

    You can very well run MPLS with static routing in the core, as in Cisco we have to meet 2 criterias to have a MPLS forwarding Table.
    1) Creating the LIB
    This thing lies in having LDP neighborship netween two peers and you have Label bindings.
    This is irrespective of what is the best next hop to reach the advertising peers LDP_ID.
    2) Creating the LFIB
    Now after considering all the Label bindings, the LDP_ID which can be reached out an interface
    as a next hop, those Label bindings get installed in the LFIB.
    So considering the above two points, we have to be careful in static routes
    only for interfaces like Ethernet (Multiaccess Segments).
    As in CEF when you give a static route pointing to an Ethernet Interface, CEF creates a
    GLean Adjacency (Meaning there could be multiple hosts as the next hop on this segement, and it will glean for the right next-hop)
    Now you may observe that when you give a static route only pointing to an Ethernet interface,
    you LDP adjacency may come up and you may exchange the bindings with each other. But the Label Forarding Table is not created. This is bcos of this being a Multiaccess interface. And you have
    Glean For it. If its a Normal WAN interface like Serial or POS, then there is no problem of
    GLean and you would have a Valid Cached Adjacency.
    So to avoid probelems with Ethernet interfaces you can simply specify the next-hop-ip address.
    For Eg: ip route 10.10.31.250 255.255.255.255 10.10.31.226 (Without the Interface)
    ip route 10.10.31.250 255.255.255.255 fa0/0 10.10.31.226 (Or with the Interface)
    Only Difference in both is in the first one it has to do a recursive lookup for the outgoing interface. Otherwise both work well. And you can have static routes in your network
    running MPLS.
    And doing this CEF would would work as it should and you would have a Valid Cached Adjacency.
    So this is applicable for Cisco devices which use CEF, including 6500 with SUP720.
    HTH-Cheers,
    Swaroop

  • SUP720 MPLS support only 700 routes per VRF?

    In following document i found that SUP720 supporting only 700 router per 1 VRF. Am i right?
    http://www.cisco.com/en/US/partner/products/hw/modules/ps4835/products_data_sheet09186a0080159856.html

    There is no such thing as a limit of 700 routes per VRF. What is described in this URL is that scalability testing has been performed with 1024 VRFs with 700 routes each (1024*700=716800 routes total).
    You could go way beyond 700 routes per VRF if you don't plan to provision that many VRFs.
    Let me know if I answered your question,

  • MPLS VPN L3 BGP to Customer CPE

    Hello,
    I am learning how to setup MPLS VPN L3. I am running OSPF in the MPLS Core and have configured MP-BGP between PE. I am running BGP between the PE and CPE in my lab, and I can see redistributed routes from the CPE in the vrf routing table for that customer on the PE router. My question is how to reditribute the vrf routes into my MPLS core to transmit the traffic to the customer other site on the same vpn. Below is what my config looks like.
    PE
    ip vrf customerA
    rd 100:101
    route-target export both 100:1000
    int fa0/0
    ip vrf forwarding customerA
    ip address x.x.x.x x.x.x.x
    router ospf 1
    loopback  in area0
    networks in area0
    router bgp 65000
    neighbor to other PE routers in AS 65000 (MPLS Network)
    address family vpn4
    neighbor other PE routers activate
    neighbor other PE routers send community
    ip address ipv4 vrf customerA
    neighbor to customerA in AS 55000
    CPE
    router ospf 1
    loopback in area 0
    networks in area 0
    router bgp 55000
    neighbor to PE router in AS 65000
    redistribute ospf 1

    Hi
    You dont have to redistribute your routes into mpls core. The vpnv4 bgp session that you have has already sent your ce routes to the remote pe router, provided you have the vrf configured on the other end.
    For more detaiked explanation please check a presentation available in the current running Ask The Expert event in the support community.

  • MPLS-VPN Label

    In MPLS-VPN the forward of packets based on the LFIB tabel and the first label (NextHope)
    label is advertised through the LDP and the second label (VPN label) is annouced via
    MP-BGP, the problem is that when i check the FIB tabel of the customer VRF i can see both labels
    but when i check the customer LFIB i did't see the second label=VPN!! so is that the VPN labels stors
    only in the FIB and if right how is that while the forward always based on the LFIB
    kindly advice
    Router#show ip cef vrf cust det
    10.10.44.0/30, version 1499, epoch 0, cached adjacency to Switch1.2
    0 packets, 0 bytes
    tag information set
    local tag: VPN-route-head
    fast tag rewrite with Sw1.2, point2point, tags imposed: {83 544}
    via x.x.x.x, 0 dependencies, recursive
    next hop x.x.x.x, Switch1.2 via x.x.x.x/32
    Router#show tag for vrf cust
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    126 Untagged 10.10.52.8/29[V] 55708 Sw1.87 point2point
    253 Untagged 10.10.52.4/30[V] 0 Sw1.87 point2point
    263 Aggregate 10.10.52.0/30[V] 0
    284 Untagged 10.230.52.0/22[V] 8616469838 Sw1.87 point2point

    Hello,
    the command "show mpls forwarding-table vrf cust" asks for a list of all locally assigned VPN labels! As the network 10.10.44.0/30 is learned via BGP, there is no locally assigned VPN label - hence it will not show up in the LFIB.
    Another explanation would be: traffic towards 10.10.44.0/30 is received from the CE in the form of IP packets. So the PE has to perform an IP lookup and that means it is the FIB´s "business" to attach labels. LFIB has nothing to do with it. As you have seen the FIB however "knows" what to do, so everything is fine - cust is happy ;-)
    Hope this helps! PLease rate all posts.
    Regards, Martin

Maybe you are looking for