ā11-01-2013 07:46 AM - edited ā03-04-2019 09:28 PM
Hi all,
We setup a EBGP session with external vendor and receiving multiple subnets (at 2 locations that are interconnected via L3 link).We need to redistribute this into internal OSPF.Instead of having multiple subnets, is there anyway to summarize them when receiving and then redisribute summary routes into OSPF?
Setup at each locatio: Core L3 SW --> FW --> External vendor rtr.
Core sw have BGP to External vendor and OSPF for internal networks and L3 linkt o another location.
Sample vendor route currently sen via BGP core SW (vendor does not change their standard configs):
72.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
B 72.14.32.128/26 [20/4] via 172.16.15.1, 16:30:16
B 72.14.16.128/26 [20/2] via 172.16.15.1, 16:30:16
B 72.14.103.0/27 [20/4] via 172.16.15.1, 16:30:16
B 72.14.102.0/27 [20/2] via 172.16.15.1, 16:30:16
B 72.14.5.64/26 [20/4] via 172.16.15.1, 16:30:16
B 72.14.4.64/26 [20/2] via 172.16.15.1, 16:30:16
B 72.14.5.0/26 [20/4] via 172.16.15.1, 16:30:16
B 72.14.4.0/26 [20/2] via 172.16.15.1, 16:30:16
B 72.14.1.0/26 [20/4] via 172.16.15.1, 16:30:16
B 72.14.0.0/26 [20/2] via 172.16.15.1, 16:30:16
Wondering if I can able summarize receving routes into 72.14.0.0 /16.
Then under OSPF:
router ospf 1
network <intern LAN1>
network <intern LAN2>
redistribute bgp 65000 metric-type 1 metric 2 subnets tag 222 ---> tag for just recgnition from other location.
!
Thanks in advance,
MS
Solved! Go to Solution.
ā11-01-2013 10:40 AM
Hi,
The summary-address command only injects the summary prefix if the more specific prefix is redistributed into ospf. So you need to redistribute BGP into OSPF for the summary-address command to take effect.
Regards
ā11-02-2013 04:20 AM
Hi MS,
You are right 199.105.184.0/23 is not covered by 199.105.176.0/21 (199.105.176.0 to 199.105.183.255). So 199.105.184/23 will be redistributed into OSPF unsummarized.
Regards
ā11-01-2013 08:01 AM
Hi,
You can use the summary-address command to summarize routes that you redistribute into ospf.
http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfospf.html#wp1029504
Regards
ā11-01-2013 09:42 AM
Hi Harold,
Thank you for your reply. We have more than one network advertised as subnetted network from the vendor. So rather than dealing with OSPF summary, I guess it is easy if I can have it summarized while receiving via BGP only. So, incase if I have more than one network, what is the best practice to summarise to below targetted subnets..
72.14.0.0 /16 (advertised as 12 subnets)
19.15.17.0/21 (advtd as 4 subnets)
19.15.26.0/23 (advtd as 2 subnets)
Couple of class C networks--> advertised as it is.
How can I summerise while redistributing into OSPF.
Thx
MS
ā11-01-2013 10:15 AM
Hi,
Summarizing in BGP will not be any easier. I would suggest you use multiple "summary-address" command as follow to accomplish what you want.
summary-address 72.14.0.0 255.255.0.0
summary-address 19.15.17.0 255.255.248.0
summary-address 19.15.26.0 255.255.254.0
Regards
ā11-01-2013 10:26 AM
Thank you again. So your suggestion is instead of redistributing BGP into OSPF, use summary-address < > under the OSPF process and these summary rutes will be advertised to rest of the OSPF areas?
If so, one question- If the external vendor link goes down and then BGP and advtd networks from vendor disappears from BGP table, due to summary address, tehy may still present in internal OSPF domain? We may not have this issue, if we redistribute BGP? Please clarify.
Thx
MS
ā11-01-2013 10:40 AM
Hi,
The summary-address command only injects the summary prefix if the more specific prefix is redistributed into ospf. So you need to redistribute BGP into OSPF for the summary-address command to take effect.
Regards
ā11-01-2013 01:55 PM
Hi Horald,
I just tested in lab scenario but noticed that with summary address, only one prefix is getting advertised even for different subnets. In other words...
summary-address 19.15.17.0 255.255.248.0
summary-address 19.15.25.0 255.255.254.0
Only summary-address 19.15.17.0 255.255.248.0 -> adverised to OSPF neighbor. I need to check with subnet caliculation- may be the second one falling under first subnet and that causing it.
Also, with 2 Class C- 212.135.161.0/24 and 212.184.246.0/24--> Only First one sent to neighbor.
72.14.0.0 255.255.0.0 --> worked fine.
Config:
router ospf 1
network
network
summary-address 19.15.17.0 255.255.248.0
summary-address 19.15.25.0 255.255.254.0
summary-address 72.14.0.0 255.255.0.0
summary-address 212.135.161.0 255.255.255.0
summary-address 212.1184.246.0 255.255.255.0
redistribute bgp 65000 metric-type 1 metric 2 subnets tag 222
!
I tried to remove the non advertising class C from summary list.. still no luck.
Not sure if Iam missing anything else.
Thanks again in advance.
MS
ā11-01-2013 02:31 PM
Hi MS,
> Only summary-address 19.15.17.0 255.255.248.0 -> adverised to OSPF neighbor. I need to
> check with subnet caliculation- may be the second one falling under first subnet and that causing it.
19.15.17.0 255.255.248.0, which is really 19.15.16.0 255.255.248.0, covers all prefixes in the range 19.15.16.0 to 19.15.32.255. So indeed the second prefix is covered by the first.
> Also, with 2 Class C- 212.135.161.0/24 and 212.184.246.0/24--> Only First one sent to neighbor.
You do not need a summary-address command for these routes because they are advertized as /24 via BGP. They should be redistributed as such in OSPF.
> summary-address 212.135.161.0 255.255.255.0
> summary-address 212.1184.246.0 255.255.255.0
There is a typo on the second line. This might explain why only the first class C was advertized. As per my previous comment, you should remove these two lines anyway.
Regards
ā11-01-2013 08:22 PM
Hi Harold,
Much appreciated for your time and help. My apologies, somehow I mixed up the Calss C IP range. The Class C given by vendor are different range (ex: 208.134.161.0/24 and 258.183.x.x/24). I checked on BGP routes and only one class C network subnetted in to multiple Subnets being advertised from vendor.
208.134.161.0/24 is variably subnetted, 6 subnets, 3 masks
B 208.134.161.192/26 [20/2] via 172.16.10.1, 1d08h
B 208.134.161.128/26 [20/2] via 172.16.10.1, 1d08h
B 208.134.161.64/26 [20/4] via 172.16.10.1, 1d08h
B 208.134.161.43/32 [20/4] via 172.16.10.1, 1d08h
B 208.134.161.0/26 [20/4] via 172.16.10.1, 1d08h
So, with summary route its working correct, I guess.
As far as the other IPs, the real IPs given were :199.105.176.0 /21 (advtd as 4 subnets) and 199.105.184.0/23 (2subnets). I checked with online subnet caliculator but 199.105.184.0/23 does not look like covered by /21 range. Can you correct me on that?
Thanks,
MS
ā11-02-2013 04:20 AM
Hi MS,
You are right 199.105.184.0/23 is not covered by 199.105.176.0/21 (199.105.176.0 to 199.105.183.255). So 199.105.184/23 will be redistributed into OSPF unsummarized.
Regards
ā11-03-2013 01:38 PM
Hi Harold,
Thank you vey much. I just ran the tests and noticed that 199.105.184.0/23 not being advertised by ext vendor via BGP at this time. That is why iam not seeing. Also, I guess tag keyword (tag 222) not doing anything ( 'Show ip ospf ext database' showing tag vlaue '0') as Iam not adding any route-maps with this tag. I may take out the 'tag' keyword.
So at both locations with BGP (locations intercinnected via L3 link/ospf), I recieve BGP routes (will all subnets 2 or 4 metric) with EBGP AD 20.
Main site:
BGP routes received on core --> redistributed to OSPF with metric 5 type1
DR site:
BGP routes received on core --> redistributed to OSPF with metric 10 type1
1. In this scenario for Main/DR site: As local EBGP routes received are with AD20 and redistributed OSPF (Main-> DR and DR->Main) have AD 110, local subnets at Main and DR site use BGP routes to access ext vendor n/w. EBGP path over OSPF E1.
2.At mainsite/DR site, if BGP goes down, then redistributed routes will be used.
3. Other remote sites conneced via OSPF p2p links, will use redistributed routes based on received metric.
4. We have few easyVPN routes being learned via OSPF E2, and as long as ext vendor routes existing in OSPF database, there should not be an issue for those cleints.
5. I don't think I need to use distance-external command at any locations to control preferred path.
Hope my conclusion is not confusing.
Thanks
MS
ā11-06-2013 09:18 AM
Hi Harold,
All looks working as planned. I did summary on DR end and let subnet populate from Main location in redistribution. All looks fine. Thanks for your time and suggestions.
Thx
MS
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide