cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
655
Views
0
Helpful
3
Replies

Why should CSC-CE advertise internal Routes?

HI All,

          I will appreciate if anyone could help with a  thourough educative explanation as to why the CSC-CE should advertise it local internal routes?.

It became confusing because it link to the CSC-PE (IGP-LDP) already made the CSC-CE (local-AS) internal routes available on the CSC-PE.

I reralised the two ASBRs at either sites could see and peer (iBGP/VPNV4) relationship once the CSC PE and CE are properly configured.

I trust someone will be able to clarify my concerns or let me if some authors are just overzealous with their publication?.

Thanking you all in Advance,

O.A

3 REPLIES 3
Giuseppe Larosa
Hall of Fame Master

Hello Olugbenga,

You are referring to Carrier Supporting Carrier scenario with IGP+LDP.

The final target of the CSC scenario is to allow the Customer SP to deploy MPLS services between customer SP islands going through the Top SP backbone.

C1 --- CSC-CE1 --- CSC-PE1 --- Top SP cloud ---- CSC-PE2 --- CSC-CE2 --- C2

                    IGP+LDP                                               IGP+LDP

                               |  ---- CSC-PE1 to CSC-PE2 LSP --- |

| ------------------------------ C1 to C2 LSP ---------------------------------------------------------- |

To provide MPLS based services between customer SP islands, end-to-end LSPs between C1 and C2 have to be built.

For this to happen CSC-CE1 and CSC-CE2 have to advertise in routing protocol and LDP ( or BGP with labels) the loopback addresses of MPLS nodes C1 and C2.

Actually CSC-CE1 has to advertise all the internal routes of site 1 to the CSC-PE1 and has to provide label bindings for all the loopback addresses of nodes like C1 that are internal to site 1.

At the same time CSC-CE2 has to advertise to CSC-PE2 all the internal routes of site 2 and to provide label bindings for all the loopback addresses of nodes like C2 that are internal to site 2.

At the same time, CSC-PE1 has to provide to CSC-CE1 the routes of site2 and label bindings for all the loopback addresses of nodes that are internal to site2. The routes are necessary to build the MP BGP sessions between C1 and C2 nodes.

The label bindings are necessary to build a C1 to C2 end to end LDP LSP that is tunneled within CSC-PE1 to CSC-PE2 LSP.

CSC-CE1 propagates routing information and its own LDP bindings for the C2 loopback to the C1 node.

At the same time. CSC-PE2 has to provide to CSC-CE2 the routes of site 1 in IGP, and label bindings for all loopback addresses of nodes internal to site1 like C1.

In this way, in the opposite direction the C2 to C1 end to end LSP can be built tunneled via the CSC-PE2 to CSC-PE1 LSP.

To deploy MPLS based services like L3 VPN  an MP BGP session between C1 and C2 is necessary.

Customer SP L3 VPN traffic will use a VPN label that C2 has advertised in MP BGP to C1 in VPNv4 NLRI

The VPN traffic from C1 to C2 is placed within the C1 to C2 end to end LSP using a label depth of 3 in Top SP cloud (when it is tunneled into CSC-PE1 to CSC-PE2 LSP).

There is no need for CSC-CE1 to advertise internal routes of site1 to CSC-CE2 over a BGP session

I agree on this if this is your doubt.

see

http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ias_and_csc/configuration/15-0sy/mp-carrier-ldp-igp.html#GUID-A882034D-3CBB-4CE8-9AB5-2F2ADE4F8A82

Hope to help

Giuseppe

Hi Giuseppe,

                    I am most grateful for taken your precious time to respond to my query.

Taking the opportunity of having you around, please allow me to ask for a further clarification.

       CE     SITE-A          |                    |                              CE

          |                          |                    |           SITE_B          |

       PE                         |                    |                              PE

         |                           |                     |                                |

CSC-CE1 --- CSC-PE1 --- Top SP cloud ---- CSC-PE2 --- CSC-CE2

         |                           |                    |                                |                                                                          

      ASBR                      |                    |                            ASBR

           |                         |                   |                               |

        CE                                             |                             CE

Expanding on your diagram above, all the dramas that happened at each site was well understood, in this case The ASBRs at each sites provides VPN services to the CEs likewise the PEs, who are also RR-client to the ASBRs.

At each site in this topology the CSC-CEs are only P routers to their respectful sites.

THE CONFUSION:

After the CSC-CE has established an IGP-LDP with the CSC-PE (vrf) which invariably gives the CSC-PEs reachability to the internal routes at each site, of course the CSC-PEs are M-BGP (VPNV4) peer, why then does the CSC-CE still needs to advertise their respective internal routes?.

Once again, sorry for bothering you further,

Regards,

O.A

Hello Olugbenga,

>> why then does the CSC-CE still needs to advertise their respective internal routes?.

I guess you are referring to the  CSC-CEi to CSC-PEi routing and LDP relationships.

I understand that ASBR nodes for you are the RR servers in each site.

You cannot solve the routing and label binding problem only with a BGP session between the ASBR.

It is not enough to advertise ASBR loopback addresses from CSC-CEi node to CSC- PEi.

This might be your doubt I'm not sure.

Even if each ASBR is the RR server for its own site a BGP session between them fixes the control plane, but it does not provide a working forwarding plane via TOP SP cloud,  that requires working end-to-end LSPs between each possible pair of PE nodes taken from site1 and site2.

To build LSPs the host routes for the loopbacks have to be present in the routing table of the CSC-PEi nodes or the label binding is ignored and not installed in MPLS forwarding table.

IT is the same root cause that doesn't allow to aggregate PE loopback addresses between different OSPF areas to make an example.

And we need to take in account that RR servers do not change the BGP next-hop so VPNv4 routes are propagated with the BGP next-hop unchanged.

It is for building the correct end-to-end LSPs that CSC-CEi nodes need to :

advertise all site i internal routes  (all PE loopback addresses actually not all internal routes to be honest)

provide MPLS LDP label binding for each PE loopback internal to site i

Hope to help

Giuseppe

Content for Community-Ad

This widget could not be displayed.