IEOC - Internetwork Expert's Online Community

in option 2b, we need to use "redis connected" in order to have the ASBR be able to access the next-hop due to a /32 interface route is generated. But why a /32 interface route is generated?

Thanks,

Bo

Hi, this is because an end-to-end LSP is required for the inter-AS MPLS VPN to work.

As the routes learnt from the remote AS are learnt vie eBGP the next-hop will be set to that ASBR's IP address. The PE's in the local AS need a label for that next-hop so the /32 connected route provides a simple way to get this label into the local AS.

Alternatively, you can use next-hop-self on the local ASBR iBGP sessions (Towards the local PE's/RR's) so that the far end PE will see the local ASBR as the next-hop and will already have a label.

HTH

Nick

bozhang:

in option 2b, we need to use "redis connected" in order to have the ASBR be able to access the next-hop due to a /32 interface route is generated. But why a /32 interface route is generated?

Thanks,

Bo

In order to avoid popping the label (PHP) a hop too soon i think

There are two suboptions when using the vpnv4 ASBR peering option for Inter-AS VPN. Both need a transport LSP to be constructed between the PEs. With Option 2, this LSP is normally segmented on local and non-local (remote AS) parts. The suboptions differ in the way the two segements are "stitched".

1) The local segment transport LSP terminates at the local ASBR. This requires changing vpnv4 next-hop to self on the local ASBR. Unidirectional Inter-AS switching is performed based on the vpnv4 labels, which must be installed in local ASBR's LFIB.

2) The transport LSP terminates at the remote ASBR. This requires a /32 prefix for the remote ASBR to be either redistributed into IGP/labeled via LDP or propagated via BGP/labeled via BGP. Unidirectional Inter-AS switching is performed based on the transport label shared by all vpnv4 prefixes. This option reduces the amount of LFIB states that need to be kept in the local ASBR, though the amount of BGP information remains the same.

To make (2) possible, every time you create a vpnv4 eBGP peering session, an /32 prefix for the remote transport IP address is inserted in the local RIB. This will extend the local transport LSP segment up to the remote ASBR.

HTH

Thanks guys