cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1609
Views
0
Helpful
9
Replies

eBGP Issue - Administrative Distance

caiobomani
Level 1
Level 1

Dear team,

 

I'm in an unusual scenario:

 

I currently got 4 routers (2 in each data center). They all form iBGP adjacencies.

Each one connects to one carrier (A and B on each site).

 

One of the routers (with carrier B) is establishing the adjacency (as all the others) but for some reason, BGP is not learning the default route from it with AD 20. Instead, it learns the default rout from OSPF (that I use for another purpose).

 

All other connections (including this same carrier on the other site) works as it is supposed to.

 

Follow is the show ip bgp summary, show ip bgp and show ip route (with my OSPF process shut down):

 

show ip bgp summary
BGP router identifier 10.134.65.13, local AS number 267352
BGP table version is 343646972, main routing table version 343646972
760141 network entries using 188514968 bytes of memory
2928408 path entries using 351408960 bytes of memory
438573/110891 BGP path/bestpath attribute entries using 108766104 bytes of memory
218792 BGP AS-PATH entries using 10982148 bytes of memory
1 BGP ATTR_SET entries using 40 bytes of memory
403 BGP community entries using 27664 bytes of memory
30 BGP extended community entries using 1362 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 659701206 total bytes of memory
BGP activity 8241675/7481532 prefixes, 159982356/157053952 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.134.1.12 4 267352 27172950 30499819 343646978 0 0 8w4d 721256
10.134.1.13 4 267352 27328481 30499834 343646978 0 0 8w4d 726700
10.134.65.12 4 267352 13447452 80353056 343646978 0 0 30w0d 753743
201.48.13.242 4 16735 915110 6811 343646977 0 0 2d04h 726704

 

 

show ip bgp
BGP table version is 343647571, local router ID is 10.134.65.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* i 0.0.0.0 189.125.13.221 0 100 0 3549 ?
* i 200.186.135.9 0 100 0 3549 i
* 201.48.13.242 48 0 16735 i
*>i 200.146.208.166 8 100 0 16735 i

 

show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 200.146.208.166 to network 0.0.0.0

B* 0.0.0.0/0 [200/8] via 200.146.208.166, 00:26:10

 

Whenever I bring up the OSPF process, the OSPF route gets injected in the table the BGP crying baby puts its default routes in the rib-failure state (since it should learn from BGP as AD 20 but it is considering it as higher then 110 for some reason):

 

show ip bgp
BGP table version is 343649699, local router ID is 10.134.65.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
r i 0.0.0.0 189.125.13.221 0 100 0 3549 ?
r i 200.186.135.9 0 100 0 3549 i
r 201.48.13.242 48 0 16735 i
r>i 200.146.208.166 8 100 0 16735 i

 

ADQ-TRJ-RT-FP-I4331-INET-02#show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
0.0.0.0 200.146.208.166 Higher admin distance n/a

 

 

show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 45.233.233.249 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 45.233.233.249, 00:00:57, GigabitEthernet0/0/0.810

 

Any thoughts on why I'm considering the routes from my eBGP peer with an administrative distance higher then 20? I just got one filter (prefix list) in the outbound direction to make sure I wont redistribute the prefixes learned from other carriers and circuit back to the ISP.

 

1 Accepted Solution

Accepted Solutions

caiobomani
Level 1
Level 1

Problem solved.

 

The carrier is using Juniper to peer with my devices. For some reason Juniper is unable to originate a default route, so they are redestributing them on both peers and adding weight on the peering with site B (which seems that they are not allowed to remove).

 

In order to fix the issue (of prefering the default via IGP/iBGP instead of eBGP) I've added a prefix-list matching the default and attached a route map to it with weight 100.

 

Thanks everyone for the inputs that lead me to this conclusion.

View solution in original post

9 Replies 9

 

On show ip route when OSPF is shutdown, I saw that the AD is 200 (iBGP) through 200.146.208.166. As a result, when OSPF is ON, the default route through OSPF will be selected as its AD is 110. That is what happened, as expected. 

 

The question is where you did receive the default route with 200.146.208.166 next-hop (it seems from an iBGP peer) and/or why you did lower the local-preference on the route from 201.48.13.242 neighbor. The default route with next-hop 200.146.208.166 has higher local-preference (100) than with the eBGP 201.48.13.242 (48). As a result, it is chosen as best path in the BGP table. If you want the default-route from eBGP neighbor 201.48.13.242 to be the best path, change the local-preference (>=100) for the route.

 

HTH,

Meheretab

HTH,
Meheretab

The original poster has given outputs of show commands that illustrate the results but has not given any of the configs that might show why it gets those results. Can we see the configs also?

 

HTH

 

Rick

HTH

Rick

My bad.

 

Here are the BGP configuration on the router that is learning the default route as if it is an iBGP not an eBGP prefix:

 

router bgp 267352
bgp log-neighbor-changes
redistribute static route-map StatictoBGP
neighbor 10.134.1.12 remote-as 267352
neighbor 10.134.1.12 password *******
neighbor 10.134.1.12 update-source Loopback0
neighbor 10.134.1.12 soft-reconfiguration inbound
neighbor 10.134.1.13 remote-as 267352
neighbor 10.134.1.13 password *******
neighbor 10.134.1.13 update-source Loopback0
neighbor 10.134.1.13 soft-reconfiguration inbound
neighbor 10.134.65.12 remote-as 267352
neighbor 10.134.65.12 password ******
neighbor 10.134.65.12 update-source Loopback0
neighbor 10.134.65.12 soft-reconfiguration inbound
neighbor 201.48.13.242 remote-as 16735
neighbor 201.48.13.242 password ********
neighbor 201.48.13.242 update-source GigabitEthernet0/0/1
neighbor 201.48.13.242 soft-reconfiguration inbound
neighbor 201.48.13.242 prefix-list Permit_AS_267352 out

 

The prefix list contains my AS prefixes.

 

(thats all the BGP config I have on that device)

Thanks for posting the configuration information. Perhaps the key question is about the advertised default route from 200.146.208.166. Who is this and why is its local preference set better than the EBGP neighbor?

 

HTH

 

Rick

 

 

 

HTH

Rick

Indeed that's what I've questioned my ISP. They said "everything is normal".

Seems that they are redistributing this default route from iBGP instead of generating a default for me, as is in the other peer adjacency I establish with them.

 

I'll have to got for another round with them.

 

Is there any command that would actually show the administrative distance of an incoming route from a specific peer?

Indeed Meheretab that is the issue:

 

I'm establishing an eBGP adjacency with my carrier and, for some reason, the routes learned from them are getting to the router as iBGP, not eBGP as it should.


You need to check with your carrier why you are receiving the route with AD 200 with next-hop of 200.146.208.166. You also need to check why the local-preference is set to 48 (as the default local-preference is 100 on Cisco routers) on the default route from your neighbor 201.48.13.242.

HTH,
Meheretab
HTH,
Meheretab

Thank you.

 

Indeed that's what I'm going to do.

 

About the MED, seems tha the carrier do that with their default route from any location other than their headquarters. Not quite sure why.

 

Thanks,

 

caiobomani
Level 1
Level 1

Problem solved.

 

The carrier is using Juniper to peer with my devices. For some reason Juniper is unable to originate a default route, so they are redestributing them on both peers and adding weight on the peering with site B (which seems that they are not allowed to remove).

 

In order to fix the issue (of prefering the default via IGP/iBGP instead of eBGP) I've added a prefix-list matching the default and attached a route map to it with weight 100.

 

Thanks everyone for the inputs that lead me to this conclusion.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card