cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6485
Views
10
Helpful
7
Replies

L3VPN MPLS - Internal BGP between CE - PE

jkliachev
Level 1
Level 1

We are ISP which use the same autonomous system to hold External BGP  sessions and for implementing L3VPN MPLS ( as internal BGP )

We have a internal office router that receives a "default route" via IBGP from our border router.

I'll try to briefly explain the problem:

This internal router named (CE) keeps IBGP session with PE router in VRF  "def".

CE ( GlobalTable ) - PE ( vrf "DEF" )

The aim is "default route" received by IBGP from the the ISP provider to be  redistributed to PE in all vrf "DEF"

After establishing the session we observe that actualy that "default  route" is propagating successful

in whole vrf "DEF" but MPLS does not set label of this route and the  traffic is blackholed.

When using another protocol as OSPF and EIGRP everything is OK. Also when redistributing static and connected prefixes everything work fine.

We recently opened case in "Cisco TAC" but unfortunately they explained that in IOS officially is not  support using IBGP between PE and CE.

Only EBGP

I would like to know if any of you had similar issue and if there is  any workaround in Cisco platform.

I see for example Juniper has special commands for resolving this problem.

Here is the output of my configuration and applied debug commands:

# PE1 router config:

The session bellow is between PE and CE:

router bgp 1000

!

address-family ipv4 vrf DEF

  redistribute connected

  redistribute static

  neighbor 10.18.7.1 remote-as 1000

  neighbor 10.18.7.1 description to_echo-sdc_CE

  neighbor 10.18.7.1 activate

  neighbor 10.18.7.1 send-community both

  neighbor 10.18.7.1 prefix-list Permit_Default in

  neighbor 10.18.7.1 route-map NEXT-HOP-SELF in

  neighbor 10.18.7.1 route-map NEXT-HOP-SELF out

  no synchronization

exit-address-family

end

PE1#show route-map NEXT-HOP-SELF

route-map NEXT-HOP-SELF, permit, sequence 10

  Match clauses:

  Set clauses:

    ip next-hop peer-address

  Policy routing matches: 0 packets, 0 bytes

PE1#show ip bgp vpnv4 vrf DEF summary

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.18.7.1       4 1000      85      38   894079    0    0 00:00:02        1

PE1#show ip bgp vpnv4 vrf DEF neighbors 10.18.7.1 routes

   Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1000:151 (default for vrf DEF)

*>i0.0.0.0          10.18.7.1                0    120      0 i

PE1#show ip route vrf DEF

     23.0.0.0/32 is subnetted, 1 subnets

S       23.23.23.23 [1/0] via 10.18.7.1

     24.0.0.0/32 is subnetted, 1 subnets

C       24.24.24.24 is directly connected, Loopback30

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B       10.100.187.1/32 [200/0] via 10.1.7.253, 00:16:16

C       10.18.7.0/29 is directly connected, Vlan187

B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:08:40

#### PE2 is another PE router for testing which should receive and use "default route"

PE2#show ip route vrf DEF

     23.0.0.0/32 is subnetted, 1 subnets

B       23.23.23.23 [200/0] via 10.1.1.253, 1w5d

     24.0.0.0/32 is subnetted, 1 subnets

B       24.24.24.24 [200/0] via 10.1.1.253, 2w0d

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       10.100.187.1/32 is directly connected, Loopback100

B       10.18.7.0/29 [200/0] via 10.1.1.253, 1w6d

B*   0.0.0.0/0 [200/0] via 10.18.7.1, 00:02:37

### this ping is OK because 10.18.7.0/29 is connected on the PE1 router.

PE2#ping vrf DEF 10.18.7.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.18.7.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

### 212.73.140.140.190 isn't in routing table. It is direct connected network on

interface on CE and passing via "default route"

PE2#ping vrf DEF 212.73.140.190

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 212.73.140.190, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Here this is very strange:

-------------------------------------------------------------------------------------------------

## this output showing that does not have assigned MPLS label for 0.0.0.0/0

PE2#show ip cef vrf DEF 0.0.0.0/0

0.0.0.0/0

recursive via 87.121.83.25 unusable: no label

Only for static and the connected networks have assigned MPLS labels and works fine.

PE2#show ip cef vrf DEF 10.18.7.0/29

10.18.7.0/29

nexthop 10.1.7.1 Vlan15 label 76 43

-------------------------------------------------------------------------------------------------

1 Accepted Solution

Accepted Solutions

Hi,

Good to know that issue is resolved. By the way what does this command "ip next-hop peer-address" do ?

Regards # mahesh

View solution in original post

7 Replies 7

Mahesh Gohil
Level 7
Level 7

Hi,

I think cisco answer is correct. You need to have ebgp between PE1 and CE. another way if you like then you may put static default route pointing towards CE at PE1 and redistribute same in MP-IBGP between PE1 and PE2 .

And please do not forget to put more specific routes in CE for vrf routes of PE2 for reverse entry. for example if PE2 is configured with vrf having 20.20.20.1/32 as connected route then put ip route 20.20.20.1 255.255.255.255 .

Hope this helps

Regards # Mahesh

I'm glad to say that the issue has been resolved!

The aim is to use IBGP to learn "default route" dynamicaly.

Wehen using of static route, I agree that it works because then this route

is redistributing by "redistribute static" over ipv4 vrf "DEF" but this is not our goal.

First I tried to set "next-hop-self" only but unfortunately without success.

The next-hop was still 10.18.7.1.

Obviously, this feature does not work when is configured "route-reflector-client" over the session.

However when I created route-map:

route-map NEXT-HOP-SELF, permit, sequence 10

  Match clauses:

  Set clauses:

    ip next-hop peer-address

Then I configured it in address-family vpnv4

neighbor 10.1.7.253 route-map NEXT-HOP-SELF out

Also the session between PE1 and PE2 should be RR to distribute routes learned by IBGP from CE

neighbor 10.1.7.253 remote-as 1000

neighbor 10.1.7.253 description PE2_MPLS-VPN

neighbor 10.1.7.253 update-source Loopback0

address-family vpnv4

  neighbor 10.1.7.253 activate

  neighbor 10.1.7.253 send-community both

  neighbor 10.1.7.253 route-reflector-client

  neighbor 10.1.7.253 next-hop-self

  neighbor 10.1.7.253 route-map NEXT-HOP-SELF out

Now Everything seems OK!

PE1#show running-config interface loopback 0

interface Loopback0

ip address 10.1.1.253 255.255.255.255

end

PE2#show ip route vrf DEF

     23.0.0.0/32 is subnetted, 1 subnets

B       23.23.23.23 [200/0] via 10.1.1.253, 03:50:40

     24.0.0.0/32 is subnetted, 1 subnets

B       24.24.24.24 [200/0] via 10.1.1.253, 2w2d

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C       10.100.187.1/32 is directly connected, Loopback100

B       10.18.7.1/32 [200/0] via 10.1.1.253, 00:45:20

B       10.18.7.0/29 [200/0] via 10.1.1.253, 03:50:40

B*   0.0.0.0/0 [200/0] via 10.1.1.253, 00:19:14

PE2#ping vrf DEF 212.73.140.149

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 212.73.140.149, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

PE2#show ip cef vrf DEF 0.0.0.0/0

0.0.0.0/0

  nexthop 10.1.7.1 Vlan15 label 76 107

Hi,

Good to know that issue is resolved. By the way what does this command "ip next-hop peer-address" do ?

Regards # mahesh

Hi,

We can use the route-map and set ip next-hop peer-address command to tell the iBGP learn router to forward the packet to its peer address instead of the external router IP address. Check the example below for more detailed explanation.

For example:

Network 10.0.0.0/24 <--- AS100(R1) 192.168.1.1 <-> 192.168.1.2 AS200(R2)172.16.1.1 <-> 172.16.1.2 AS200(R3)

R1 advertise 10.0.0.0/24 network to R2 by EBGP.  R2 advertises this network to R3 by IBGP

However, R2 does not have the next-hop-self command configured which makes the R3 consider the R1 as the next hop address. The problem is R3 does not know how to get to R1. Therefore, R3 does not have reachability through the 10.0.0.0/24 network.

Therefore we use the next-hop peer address command in the R2 which makes R3 forward the packet destined to 10.0.0.0/24 network via its peer address which in this case is R2 address.

Hi,

Thanks for explanation.

I am trying to understand what is the real difference between 'next-hop self' and 'next-hop peer address'. Is it something like

next-hop self will advt. it's loopback used for bgp update-source to peer and next-hop peer address advt. it's connected wan ip address to peer.

If you know difference kindly let me know else will also test the same on GNS3 once get some out out of work.

Regards # mahesh

Hi,

Do not use the neighbor next-hop-self command to modify the next hop attribute for a route reflector when this feature is enabled for a route reflector client. Using the neighbor next-hop-self command on the route reflector will modify next hop attributes only for routes that are learned from eBGP peers and not the intended routes that are being reflected from the route reflector clients. To modify the next hop attribute when reflecting a route, use an outbound route map.

In general, these are the main differences.

"next-hop-self" just does not working when the command "route-reflector-client" is configured over the IBGP session for routes learned by another IBGP sessions.

It works only for routes learned by EBGP

Hi Mahesh/Javor,

You should never use "next-hop-self" on a RR because that would make it participate in the forwarding path and will soon die because of all the traffic within the AS.

An RR should only pass the control plane traffic which it would to its RR clients. Once that is done then the RR's job is done. The forwarding plane should talk directly to the next-hops which would be reachable via the IGP anyway

Regards,

Kishore

Getting Started

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: