09-04-2018 06:20 PM - edited 03-05-2019 10:53 AM
I have inherited a piecemeal network that has many things I haven't figured out yet. I'm no network engineer so I lean of the TAC for most complex changes.
I have an issue with our BGP changing routes today for some reason and I'm trying to figure out how I can fix it and prevent it from happening again.
At some point today our BGP on our edge router (CORE-RTR1) connected to our ISP changed it default route and Gateway of Last Resort from our ISP to another router (OLD-RTR1) on our network that USED TO have a redundant internet connection.
This cause a loop where the other two rouers were just sending traffic back and forth to one another. During this - I realized I need to reset/recalculate the routes. In a hurry - I rebooted CORE-RTR1. This fixed this routing issue but I'm pretty sure caused me to lose as information which would have let me see the reason for the route change.
My BGP routes are correct now but I want to prevent them from changing again.
The BGP section on the two routers is below. Please let me know what additional info would be helpful.
CORE-RTR1
core-rtr2#show run | sec bgp
router bgp 33394
bgp router-id 192.168.255.21
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.200.1.11 remote-as 65001
neighbor 10.200.1.11 description BGP Peering across MOE to Northcreek
neighbor 67.131.8.149 remote-as 209
neighbor 192.168.255.103 remote-as 33394
neighbor 192.168.255.103 update-source Loopback0
neighbor 192.168.255.104 remote-as 33394
neighbor 192.168.255.104 update-source Loopback0
!
address-family ipv4
network 67.131.8.148 mask 255.255.255.252
neighbor 10.200.1.11 activate
neighbor 10.200.1.11 route-map RM_NorthCreek_In in
neighbor 67.131.8.149 activate
neighbor 67.131.8.149 route-map RM_CLINK out
neighbor 192.168.255.103 activate
neighbor 192.168.255.104 activate
distance bgp 20 105 200
exit-address-family
OLD-RTR1
OLD-RTR1#show run | sec bgp
router bgp 65001
bgp router-id 192.168.255.22
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.11.254.2 remote-as 65001
neighbor 10.200.1.1 remote-as 33394
neighbor 63.156.111.189 remote-as 209
!
address-family ipv4
neighbor 10.11.254.2 activate
neighbor 10.11.254.2 next-hop-self
neighbor 10.200.1.1 activate
neighbor 63.156.111.189 activate
neighbor 63.156.111.189 route-map RM_CLINK out
distance bgp 20 105 200
exit-address-family
Solved! Go to Solution.
09-04-2018 09:25 PM - edited 09-04-2018 09:29 PM
The relevant route-map here is RM_NorthCreek_In, which is used against routes received from OLD-RTR1 and it doesn't block the default route. You could actually add the following configuration to make sure the default route is not learnt from OLD-RTR1:
route-map RM_NorthCreek_In deny 5
match ip address prefix-list default-route
ip prefix-list default-route seq 10 permit 0.0.0.0/0
I would strongly recommend cleaning these configurations up as soon as possible.
Regards,
09-04-2018 08:48 PM
What function serves this OLD-RTR1?
Why does it still have the peer configuration to AS 209?
The simplest thing you could do, if you are not expecting to receiving the default route from that OLD-RTR1, would be to update the route-map RM_NorthCreek_In to block the reception of the default route.
Regards,
09-04-2018 09:06 PM
I do not expect to ever receive a default egress route from OLD-RTR1.
How would I block it from being the default route? It's still got old configs because the old network engineer left things half finished.
I've at a CCENT level while he was at CCNP level and implemented many thinngs I'm not comfortable with changing.
It seems like it may already be blocked.
CORE-RTR1#show route-map route-map RM_CLINK, permit, sequence 10 Match clauses: ip address prefix-lists: PL_Default Set clauses: local-preference 999 Policy routing matches: 0 packets, 0 bytes route-map RM_CLINK, deny, sequence 1000 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RM_NorthCreek_In, permit, sequence 10 Match clauses: Set clauses: local-preference 90 Policy routing matches: 0 packets, 0 bytes route-map RM_NorthCreek_In, deny, sequence 1000 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes CORE-RTR1#
09-04-2018 09:25 PM - edited 09-04-2018 09:29 PM
The relevant route-map here is RM_NorthCreek_In, which is used against routes received from OLD-RTR1 and it doesn't block the default route. You could actually add the following configuration to make sure the default route is not learnt from OLD-RTR1:
route-map RM_NorthCreek_In deny 5
match ip address prefix-list default-route
ip prefix-list default-route seq 10 permit 0.0.0.0/0
I would strongly recommend cleaning these configurations up as soon as possible.
Regards,
09-04-2018 09:35 PM
Thank you Harold.
Does this look right?
#show route-map route-map RM_CLINK, permit, sequence 10 Match clauses: ip address prefix-lists: PL_Default Set clauses: local-preference 999 Policy routing matches: 0 packets, 0 bytes route-map RM_CLINK, deny, sequence 1000 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RM_NorthCreek_In, deny, sequence 5 Match clauses: ip address prefix-lists: default-route Set clauses: Policy routing matches: 0 packets, 0 bytes route-map RM_NorthCreek_In, permit, sequence 10 Match clauses: Set clauses: local-preference 90 Policy routing matches: 0 packets, 0 bytes route-map RM_NorthCreek_In, deny, sequence 1000 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes #show ip pref #show ip prefix-list ip prefix-list PL_Default: 1 entries seq 5 permit 0.0.0.0/0 ip prefix-list default-route: 1 entries seq 10 permit 0.0.0.0/0
09-04-2018 09:37 PM
Yes, it does.
Regards,
09-04-2018 09:41 PM
Thanks so much!
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