Next Hop and using RR with ibgp between CE-PE

Unanswered Question
Mar 14th, 2007

Hello again!. I'm setting up my internet vrf and i have a problem. I have some routers on my pop which are involved in transit and peering. By now, i cannot include them in MPLS, so I have to keep them in a pure IP environment.

To transmit internet routes, i have to set up ibgp between PE's and internet routers (working as CE's).

To avoid ibgp split horizont issues, the PE is also a route reflector, so it reflects all the routes learnt by ibgp to the others PE's.

Routes are reflected but, as route reflector rules, next-hop is unchanged, so every PE in the internet VRF receives the MP-BGP route with the correct route target and a nex-hop ip included in the internet vrf, but not in the global table, so the router does not import it to the vrf.

If I install a static route in the global routing table, it works.

does anyone have a good idea of how carring out this?

thanks in advanced

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
mheusinger Wed, 03/14/2007 - 04:50


There are two things II would suggest. Either you have all the BGP next-hop addresses in the IGP as host routes. This requires a second link or logical subinterface between PE and internet CE routers. This link would then carry all the internet traffic.

A somewhat different approach is transporting internet BGP table as address-family IPv4 on the PE routers. Your customers requiring BGP peering to the internet would have a separate link terminating in the global routing table, which can be seen as a drawback.

On the other hand you typically can not import internet routes into customer VRFs as this would create a copy of the internet BGP table per VRF, which could easily deplete the physical memory on a PE (import into ten VRFs would mean ten times full BGP table on a PE).

So typically the VRF solution also requires a separate link (or subinterface) for each customer to the internet VRF.

For customers requiring a default route, you can implement packet leaking.

Personally I would favor the latter solution, as this is pretty much standard BGP setup for internet access and also requires less memory (no RDs, RTs etc.).

Hope this helps!

Regards, Martin Wed, 03/14/2007 - 14:18

ok thanks...

only two things i don't understand.

- The scenary with default routing.. Why is so necessary to have two separate interfaces or imlementing packet leaking? if every remote office needs direct access to the internet, using public IP's, they will be exposed to the internet audience: so i maybe could use a private VPN importing default internet route from the internet VPN. Data from the offices should be enclosed to the VPN (route-driven), and only travel out the VPN (to the internet VPN) just when going to a prefix not included in the VPN. (with direct connection to the internet, they would need a firewall in every office and some strict politics)

- If two interfaces are needed: Wouldn't it be possible to use a tunnel GRE as a second (logincal) interface. Traffic between offices would use private addressing, and i would close a tunnel ending in the PE, belonging to the internet VPN and having public IP's. Even maybe i could use a loopback address and close all the tunnel ending in that address. Every client could see between them in the public addressing.... but they are connected to the internet

- By last, I think a client needing internet routes will be seen as an AS, so he would have any kind of centralized access (most of the times), so he could stablish multihop bgp sessions through a MPLS VPN with the internet POP (or better, with a router, one side connected to the pop, and the other to the different clients)

Maybe it's a very wrong vision?


mheusinger Thu, 03/15/2007 - 08:17


A1) default routing will be possible over one link. There is just a little security issue for the customer: every decent internet firewall blocks f.e. RFC1918 source IPs from the internet. This is not possible, if the link also carries internal VPN routes. So from a security perspective a separate link with a separate rule set would be better.

A2) A GRE tunnel is also OK. Speaking of a "link" I did not mean physical link, but different interface (subint, VLAN, GRE tunnel ...)

A3) multi-hop BGP would work for a BGP session, but this would potentially create the classical "BGP black hole" scenario: how would intermediate routers forward internet IP packets? Maybe a default route would help here, but you will need redundancy and default routing is very limitted when it comes to path selection.

Hope this helps!

Regards, Martin

ilya.varlashkin Thu, 03/15/2007 - 13:54


Cisco's implementation of route reflectors is in line with RFC, which says that RR should not modify next-hop, MED and AS-PATH attributes.

As mheusinger said, common solution is customers using dedicated link configured in global IPv4 address family on PE (possibly via a firewall hosted at provider site).

If you really want to go with your topology solution, just use confederation - configure your inet routers to be in different sub-AS. But this looks cumbersome to me in general (not confed but your approach of implementing inet access).


This Discussion