I have two BGP routers connecting to same ISP (MPLS/VPN), more than 500 routes are learnt from the PE router, I am running OSPF as IGP. Now I need to redistribute BGP into OSPF, but I need the neighbor OSPF router to know exact routes learnt from BGP. and don't want any downstream routers know any redistributed routes.
have thought about
1. distribution list - cannot stop sending out or receiving LSA
2. summary - on ASBR only (first OSPF router wouldn't be able to see routes)
| BGP |
OSPF \ / OSPF
R3 <-need to see all redistributed routes
R4 <-NO need to see all redistributed routes(saving resource)
The distribute-list solution is clearly inferior - while it will prevent external routes from entering the routing table on R4, the LSA-5 will still be flooded towards R4 and installed into its LSDB. The summarization on R1/R2 will make the LSDB and the routing tables smaller but will break your requirement that R3 needs to see all redistributed routes.
My immediate idea is to put R4 into a separate stubby or totally stubby area and making R3 the ABR. With R4 placed into a stubby/totally stubby area, LSA-5 will not be flooded to it, and instead, all redistributed routes will be automatically replaced with a default route.
I am afraid that if you can not afford to move the R4 and the routers behind it into a separate stubby area or perform summarization on R1/R2 then OSPF is not going to give us any more help. Link state routing protocols flood topological elements (LSAs), not prefixes. That makes the filtering very difficult, as topological details can not be tampered with, and much less flexible than in distance vector protocols. In OSPF, LSAs generated by a router may not be modified by any other router. That means that LSA-5 originated at R1 and R2 will not be modified (i.e. summarized or filtered) by any other router except an ABR towards a stubby area, and because of its domain-wide flooding scope, it will be flooded to all regular areas.
What I suggest is a different approach here: do not redistribute BGP into OSPF. Rather, run BGP also on R3 and create iBGP peerings between R3 and R1/R2. This will allow R3 to know about every network that would otherwise be redistributed into OSPF. In addition, configure R1 and R2 to inject a default route into OSPF (make sure it does not get advertised back to BGP in case of OSPF-to-BGP redistribution). This will make all routers behind and including R4 to forward packets towards R3, and assuming that R3 will have more specific subnets towards the destinations learned via iBGP, it will properly choose R1 or R2 as the next hop.
Alternatively, R3 could also be configured to inject a default route into OSPF. With iBGP between R3 and R1/R2, the OSPF between R1, R2 and R3 is basically useless - you could redistribute OSPF into BGP on R3.
given your requirements I agree that a possible option is to have iBGP sessions between R3-R2 and R3-R1 without redistributing BGP into OSPF, or all OSPF domain will know about the redistributed routes.
R1 and R2 should inject an OSPF default route conditioned to the fact that PE-CE eBGP session is up. This can be done with a route-map that checks specific BGP routes and the BGP next-hop. OSPF default route should be of type O E1 because there are two exit points from OSPF domain.
The route-map is invoked in OSPF process in default-information originate command.
All this under the hyphotesis that injecting a default route at R1, R2 does not cause problems (for example competition with an indipendent internet access).
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...