Small ISP peering with upstream (ATT) and a customer to act as redundant link for that customer. I am getting routes from customer and I am advertising them to AT&T. AT&T tech says their side shows a problem with the route map but can provide no other details. They are set to accept the subnet as well as my other subnets and receive my other subnets just fine. I've been over it and over it, hopefully it's something obvious...
The 65.x.x.0 network is the one in question. The other subnets are on my network. I have routes for all of mine, but no "ip route" statements for the 65.x.x.0 as it is acquired by BGP.
router bgp xxxx1
network 65.x.x.0 mask 255.255.255.0
network 67.x.x.0 mask 255.255.255.0
network 68.1x.x.0 mask 255.255.255.0
network 68.2x.x.0 mask 255.255.255.0
network 68.3x.x.0 mask 255.255.255.0
network 70.x.x.0 mask 255.255.254.0
network 72.x.x.0 mask 255.255.254.0
neighbor 67.x.x.8 remote-as xxxx3
neighbor 67.x.x.8 version 4
neighbor 67.x.x.8 prefix-list Cust in
neighbor 68.x.x.9 remote-as xxxx5
neighbor 68.x.x.9 version 4
neighbor 68.x.x.9 route-map bellout out
ip as-path access-list 1 permit ^$
ip prefix-list Cust seq 5 permit 65.x.x.0/24
access-list 1 permit 67.x.x.0 0.0.0.255
access-list 1 permit 68.1x.x.0 0.0.0.255
access-list 1 permit 68.2x.x.0 0.0.0.255
access-list 1 permit 68.3x.x.0 0.0.0.255
access-list 1 permit 65.x.x.0 0.0.0.255
access-list 1 permit 70.x.x.0 0.0.1.255
access-list 1 permit 72.x.x.0 0.0.1.255
route-map bellout permit 10
match ip address 1
route-map bellout permit 20
match as-path 1
Solved! Go to Solution.
1-ip prefix-list Cust seq 5 permit 65.x.x.0/24 ==> u accept prefix from customer.
2-network 65.x.x.0 mask 255.255.255.0 ==>u advertsie prefix via BGP.
3-route-map bellout permit 10
match ip address 1 ==> u control advertisement by route map.
all looks fine so far. so the only only thing I can think off is, do u have 65.x.x.x/24 installed in your routing table ( not BGP table).
unless it is there, it wont be advertised.
show ip bgp 65.x.x.x would show more info.
also, sh ip bgp neighbor x.x.x.x advertise-prefixes will show what is being sent out.
All good points, except that the network statement is not required for 65.x.x.0/24 as it is received via BGP from customer.
It shouldn't cause any issue as such. Just pointing out the fact that it is not necessary in this specific scenario.
OK, I've taken out the network line and verified ip route and what I'm advertising and they all look right. AT&T still not seeing the 65.x.x.0 network. What about a "redistribute" command?
it looks like that ATT is only accepting IP prefixes with AS path = Your ASN only.
The customer prefix 65.x.x.0/24 should be seen by ATT with an AS path attribute of = 'YourASN CustomerASN'
So if ATT has a policy that accepts only an AS path made of ^YourASN$ it is filtering the 65.x.x.0/24 IP prefix.
Ask them to verify their incoming policy and to update it if necessary.
Another possible reason could be an unknown BGP next hop verify what is the BGP next hop for prefix 65.x.x.0/24 when advertising to ATT.
Hope to help
Output from bgp...
tripgw1#sho ip bgp 65.x.x.0
BGP routing table entry for 65.x.x.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
67.x.x.78 from 67.x.x.78 (67.x.x.78)
Origin IGP, metric 0, localpref 100, valid, external, best
tripgw1#sho ip bgp nei 68.x.x.9 adv
BGP table version is 10, local router ID is 68.x.x.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 65.x.x.0/24 67.x.x.78 0 0 custASN i
*> 67.x.x.0/24 0.0.0.0 0 32768 i
*> 68.x.x.0/24 0.0.0.0 0 32768 i
*> 70.x.x.0/23 68.x.x.5 0 32768 i
*> 72.x.x.0/23 68.x.x.5 0 32768 i
Will forward to ATT...