07-31-2018 10:57 AM
Hello,
I have a L3 switch that is doing BGP peering with two other routers, RouterA and RouterB. I am learning a default route (via BGP) from RouterA and devices that use my L3 switch as their default gateway are able to reach the Internet without issue.
Now, I am trying to "re-advertise" the default route I am learning from RouterA and push that into the BGP routing table running on RouterB. On my L3 switch, if I go into my BGP routing instance and configure "default-information originate", and then if I do "show ip bgp neighbor RouterB advertised-routes", I see a default route being pushed to RouterB. But, the tech that manages RouterB says he doesn't see a default route come in from my L3 switch. If I configure a static 0.0.0.0 route on my L3 switch and then do "redistribute static" in my BGP routing process, RouterB starts to pick up the default route from my L3 switch but at the same time, I create a routing loop between my L3 switch and RouterA and so I lose my Internet connection.
I'm hoping someone can help me sort this out.
Thank you!
Daniel
08-03-2018 09:41 AM
08-02-2018 10:35 AM
Daniel
Thank you for the drawing and for the configuration of BGP from your switch. It is good to see these. The BGP config is pretty straightforward and does not show anything that would interfere with your advertisement of the default route. So it is especially important that we see the appropriate parts of the config from router B.
I do wonder about the static route entries for 3 networks with a next hop of router B. It appears that there are network statements (with mask) in your BGP config for these networks. With no filtering in your config for advertised routes it appears that you will be advertising to B these networks which are reached through B. It sounds like it could be the beginning of a loop. If you advertise to B that they can reach x.x.9.0 through you then they might send traffic for x.x.9.0 to you and then you will send it back to them.
HTH
Rick
08-03-2018 09:46 AM - edited 08-03-2018 09:49 AM
Rick,
Yes, thank you for very much for pointing out those static routes. When I began troubleshooting this a while back, I realized that my branch networks (9.x, 14.x, and 21.x) were able to trace to the L3Switch_IP but they were not able to trace all the way to RouterA's IP. I then added those three networks in my BGP config and also added the three static routes to those pointing back to RouterB and then my branch subnets were able to trace all the way to RouterA. But then subsequent troubleshooting allowed me to see that the RouterB (and the routers behind it) weren't picking up that default route information and so now I see that I do not need those networks and static routes in my L3 switch config so I will be removing those. Again, thank you for pointing those out and reminding me to get those out of there!
Daniel
08-03-2018 11:49 AM
Daniel
Thanks for the update. You are welcome about the static routes and network statements. I do not think that they are related to the problem with the default route. But they do need to be cleaned up.
Have you heard anything about getting config information from router B?
HTH
Rick
08-06-2018 07:38 AM
All,
The admin for RouterB finally sent me his BGP config this morning. I see that he has a route-map applied inbound and the route map shows three different elements. The second element appears to be accepting a default route but I'm not sure how to interpret the rest. It seems like the problem may be somewhere in the route-map config but I'm not sure.
neighbor <MyL3Switch_IP> remote-as 65410
neighbor <MyL3Switch_IP> local-as 65200
neighbor <MyL3Switch_IP> soft-reconfiguration inbound
neighbor <MyL3Switch_IP> route-map L3Switch-In in
<RouterB>#sh route-map L3Switch-In
route-map L3Switch-In, permit, sequence 10
Match clauses:
ip address (access-lists): ops-out
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map L3Switch-In, permit, sequence 20
Match clauses:
ip address prefix-lists: DefaultOnly
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map L3Switch-In, permit, sequence 30
Match clauses:
ip address prefix-lists: client.internal
Set clauses:
Policy routing matches: 0 packets, 0 bytes
<RouterB>#sh ip prefix-list DefaultOnly
ip prefix-list DefaultOnly: 1 entries
seq 5 permit 0.0.0.0/0
<RouterB>#sh ip prefix-list client.internal
ip prefix-list client.internal: 6 entries
seq 5 permit x.x.0.0/16 le 32
seq 10 permit y.y.0.0/16 le 32
<RouterB>#sh ip access-lists ops-out
Standard IP access list ops-out
10 permit z.z.0.0, wildcard bits 0.0.63.255 (210 matches)
Thanks!
Daniel
08-06-2018 09:26 AM
The route-map in looks okay to me. I am not too familiar with the local-as flag, but based upon my limited understanding your router and this router are eBGP neighbors given that command, so the default route should propagate by default.
-> Please check the BGP communities on the default route you are receiving on *your L3 router* to ensure the "no-export" community is not set. "show ip bgp 0.0.0.0" - and look for "Community".
08-06-2018 10:37 AM
Daniel,
Thank you for providing the configuration for RouterB. Could the admin make a slight change on RouterB route-map configuration as follows?
route-map L3Switch-In permit 10
match ip address prefix DefaultOnly
route-map L3Switch-In permit 20
match ip address prefix client.internal
!
ip prefix-list DefaultOnly seq 5 permit 0.0.0.0/0
!
ip prefix-list client.internal seq 5 permit x.x.0.0/16 le 32
ip prefix-list client.internal seq 10 permit y.y.0.0/16 le 32
ip prefix-list client.internal seq 15 permit z.z.0.0/18 le 32
!
HTH,
Meheretab
08-08-2018 09:22 AM
Daniel
It is good to see some of the information from router B. It is not clear what the issues are but there are some possibilities and some suggestions, particularly as relates to the route map used on router B.
The output you post seems to indicate that the first stanza of the route map is using a standard access list. I have seen many configs that use access lists in route maps to control BGP advertisements. But the ones I have seen use extended access lists and not standard. I can not say that it is problematic to use a standard access list. But I sure would like to see what happens if that part of the route map is changed. Perhaps change the order of the route map so that this is the last stanza rather than the first. Or perhaps change the standard access list to an extended access list. Or perhaps combine this network zz.0.0 with the other networks in the prefix list as suggested by Meheretab.
I would also like to know if the networks x.x.0.0/16 and y.y.0.0/16 are successfully received. If they are not successfully received then it reinforces my doubts about using the standard access list in the first match statement. If they are successfully received then the standard access list is less likely an issue and we need to look for something else as the problem.
HTH
Rick
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