I'm working away at redistributing routes from OSPF/statics into BGP, and a thought popped up - when should I use "network" statements, when should I use "redistribute <OSPF|static>", and when should I use "redistribute <OSPF|static> route-map ..."?
One of the concepts we discussed in a BGP 3.2 course I attended was to divorce BGP from the IGP. Thus, I think it's a bad idea to use "redistribute <OSPF|static" on its own, but to use the more restricted form where I filter routes using route maps and access-control lists.
So, why use "network" statements instead of "redistribute ... route-map", or vice-versa?
In my particular instance, I'm using BGP across our WAN which is a VPN within carrier IP/MPLS environments - no Internet stuff, so it's tempting at times to ignore advice and use "redistribute <OSPF|static>" on its own without route filtering.
We use BGP to peer with an SP's MPLS cloud and we use network statements to do this. This gives us more conrol over which networks we advertise to other sites. We considered using redistribution but chose not to as we redistribute routes received from BGP into our IGP (EIGRP) and we wanted to avoid any mutual redistribution problems.
Because we summarise most of our networks we can add a /25 vlan within one of our sites and there is no need to update the BGP advertisements but obviously if you add an entirely new range then you must remember to update the BGP network statements which you wouldn't have to do if you dynamically redistributed them.
If you do use redistribution into BGP it would be a good idea to use aggregate addressing in your advertisements. Without this a link flapping within one of your areas would get propogated to every other BGP router.
And as the previous poster mentioned, if you redistribute OSPF into BGP and BGP into OSPF then you shoudl utilise route-maps to enusre you do not create any routing loops in your network.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...