cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3682
Views
5
Helpful
6
Replies

neighbor next-hop-unchanged

kent.plummer
Level 1
Level 1

Hi all,

Wondering if anyone has successfully used "neighbour next-hop-unchanged"?

I'm attempting to use the BGP "neighbour next-hop-unchanged" but Im still seeing a change in the next hop IP address.  I have this specified on the bgp peer facing CE1.

The setup is per below using eBGP for the PE to CE routing protocol for MPLS VPN customers.

10.88.88.0/24---CE1 ---eBGP -----PE2 ------- PE1

CE1 has eBGP session with PE1

CE1 is in a VRF hence the BGP session on PE1 is a vpnv4 peer

PE1 is a route-reflector.

PE2 is the RR client or PE1

PE2 BGP table for this vrf sees 10.88.88.0 via PE1 as PE has changed the next hop from the CE1 wan address to PE1's address upon reflecting the route back to PE2.  This seems against the eBGP next hop rules to me??  ie don't change next hop for an eBGP learnt route.

PE1 BGP table for this vrf sees 10.88.88.0 via PE2 - hence I end up with a loop and TTL expired packets.

For various reasons we have all customer devices BGP peer with two specific routers, not their directly connected PE and I wish to continue with this design.

From the command lookup tool.  It warns against doing what I am doing here (using neighbour next-hop-self on a RR) but no reasoning behind this...

"The neighbor next-hop-unchanged command is used to configured the propagate the next hop unchanged for multihop eBGP peering sessions. This command should not be configured on a route reflector, and the neighbor next-hop-self command should not be  used to modify the next hop attribute for a route reflector when this  feature is enabled for a route reflector client."

Appreciate your thoughts.

Regards,

Kent.

2 Accepted Solutions

Accepted Solutions

Hello Kent,

>> Is there any other possible way to achieve this - or am I going to have to have all BGP talking CE's directly peer with their terminating PE?

this is the basis of MPLS L3 VPN the so called peer model where each CE just needs to peer with local PE node.

this is not an overlay VPN where you need a PVC between each CE pair, SP signalling  plane provides all you need.

>> This approach isnt so desirable as we really like the flexibility of being able to move PPP subscribers to a different LAC/LNS without having to change any of the routing or reconfigure the CE.

you probably need to do this at L2TP version 2 level not at IP routing level. I'm not sure how it can be done. It would require additional thinking.

Hope to help

Giuseppe

View solution in original post

Hi Kent

As shivlu told the solution is perfecet for you.

See the below detail : -

CE1 ------ PE2-- xconnect ----------PE1

                                                      |

                                                      |

                                          Fa0/0 - Fa1/0 --fa2/0

                                                           |____|

                                                   Loop between interface

Here is the config of PE2 that face to customer router. ( This is base config you need additional config )

This one is normal config as you config for VPWS.


pseudowire-class l2tp
encapsulation l2tpv3
ip local interface Loopback1
!
!

interface Loopback1
ip address 2.2.2.2 255.255.255.255


interface FastEthernet1/0.100
description ***** Connected CE  *****
no ip address
duplex auto
speed auto
no cdp enable
xconnect 1.1.1.1 100 pw-class l2tp

PE-1 Router that connect to PE2

pseudowire-class l2tp
encapsulation l2tpv3
ip local interface Loopback1
!
!

interface Loopback1
ip address 1.1.1.1 255.255.255.255


interface FastEthernet1/0.00
description ***** Layer 2 interface Connect to CE  *****
no ip address
duplex auto
speed auto
no cdp enable
xconnect 2.2.2.2 100 pw-class l2tp


interface fastinterface2/0.100
description ** Layer 3 interface that connect to CE **
ip vrf forwarding Cust_A
ip address x.x.x.x x.x.x.x

In above config you need three interface in PE1 Router .For Example

Fa0/0 -----Connect to PE2

Fa1/0 -----Connect to Fa2/0 to same router  fa2/0( Loop between interface )

Fa2/0 ----- Connect to Fa1/0  to same router fa1/0

The PE2 xconnect map with PE1 fa1/0 & fa1/0 is looped with fa2/0 were L3 interface is configured.

Here CE will connect directly to PE1 the layer three interface is configured on PE1 itself , and From PE2 to PE1 it act as P2P connectivity.

Regards

Chetan Kumar

View solution in original post

6 Replies 6

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Kent,

I'm afraid you cannot use the command in a VPNv4 context.

The BGP next-hop cannot be left unchanged because it is part of a VRF routing table (CE1 IP address)

From the point of view of remote PE connecting to remote VRF site the VPNv4 route is received with a BGP next-hop = PE1 loopback automatically with no need for additional commands.

PE2 imports the VPNv4 route because the route-target value matches the import rules of locally defined VRF, the RD is removed and the IPv4 prefix is installed in the VRF routing table as iBGP with admin distance 200 and BGP next-hop = PE1 loopback address

On advertising the route to CE2 router the BGP next-hop is changed in PE2's ip address and also this is needed as CE2 doesn't have access to PE1's loopback IP address.

This is important because the BGP next-hop is used to select the MPLS LSP (external label) so you cannot manipulate the BGP next-hop it needs to be PE1 loopback address.

So what is you is correct, the command neighbor next-hop-unchanged can be used only on an EBGP session in global routing table not within a VRF mapped session.

Hope to help

Giuseppe

Thanks for the explanation Giuseppe.

Is there any other possible way to achieve this - or am I going to have to have all BGP talking CE's directly peer with their terminating PE?  This approach isnt so desirable as we really like the flexibility of being able to move PPP subscribers to a different LAC/LNS without having to change any of the routing or reconfigure the CE.

FYI - we are using BGP as the CE- PE routing protocol for customers who have two services at a site configured for dynamic failover.

Regards,

Kent.

Hello Kent,

>> Is there any other possible way to achieve this - or am I going to have to have all BGP talking CE's directly peer with their terminating PE?

this is the basis of MPLS L3 VPN the so called peer model where each CE just needs to peer with local PE node.

this is not an overlay VPN where you need a PVC between each CE pair, SP signalling  plane provides all you need.

>> This approach isnt so desirable as we really like the flexibility of being able to move PPP subscribers to a different LAC/LNS without having to change any of the routing or reconfigure the CE.

you probably need to do this at L2TP version 2 level not at IP routing level. I'm not sure how it can be done. It would require additional thinking.

Hope to help

Giuseppe

Hi

Giuslar has given a good hint which is l2tpv3. I can tell you how to achieve the solution. What you can do, ON pe1, which is RR, simply loop two ports back to back. Lets assume you are having fa2/0 and fa2/1. Loop these ports with cross cable. Now create a one l2tpv3 from PE2 to PE1 fa2/0.

How to create l2tpv3, please check http://www.mplsvpn.info/2009/02/l2vpn-over-ipmpls.html

After doing this, add fa2/1 in vrf. Then you can assign /30 pool from PE2-fa2/1 to CPE. For them it is like a point to point connection.

regards

Shivlu Jain     

Hi Kent

As shivlu told the solution is perfecet for you.

See the below detail : -

CE1 ------ PE2-- xconnect ----------PE1

                                                      |

                                                      |

                                          Fa0/0 - Fa1/0 --fa2/0

                                                           |____|

                                                   Loop between interface

Here is the config of PE2 that face to customer router. ( This is base config you need additional config )

This one is normal config as you config for VPWS.


pseudowire-class l2tp
encapsulation l2tpv3
ip local interface Loopback1
!
!

interface Loopback1
ip address 2.2.2.2 255.255.255.255


interface FastEthernet1/0.100
description ***** Connected CE  *****
no ip address
duplex auto
speed auto
no cdp enable
xconnect 1.1.1.1 100 pw-class l2tp

PE-1 Router that connect to PE2

pseudowire-class l2tp
encapsulation l2tpv3
ip local interface Loopback1
!
!

interface Loopback1
ip address 1.1.1.1 255.255.255.255


interface FastEthernet1/0.00
description ***** Layer 2 interface Connect to CE  *****
no ip address
duplex auto
speed auto
no cdp enable
xconnect 2.2.2.2 100 pw-class l2tp


interface fastinterface2/0.100
description ** Layer 3 interface that connect to CE **
ip vrf forwarding Cust_A
ip address x.x.x.x x.x.x.x

In above config you need three interface in PE1 Router .For Example

Fa0/0 -----Connect to PE2

Fa1/0 -----Connect to Fa2/0 to same router  fa2/0( Loop between interface )

Fa2/0 ----- Connect to Fa1/0  to same router fa1/0

The PE2 xconnect map with PE1 fa1/0 & fa1/0 is looped with fa2/0 were L3 interface is configured.

Here CE will connect directly to PE1 the layer three interface is configured on PE1 itself , and From PE2 to PE1 it act as P2P connectivity.

Regards

Chetan Kumar

Thank you for the suggestions all.

I agree that the xconnect proposed approach is one possible solution.  We current make use of a very similar setup to deliver L2 ethernet services to customers.  However this does increase the complexity - and does not cater for PPP based services (non point to point /30 services)

Applying the KISS principle the best way forward looks to be to change the design and have the CPE peer directly with the edge PE where the customer physically connects to our network.

If only next-hop-unchanged worked for VPNv4 routes all would be a lot easier.

Great suggestions from everyone. Thank you for the input.

Cheers

Kent.

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: