If I'm reading this correctly, the router is preferring the OSPF route
over the BGP route, which makes sense because OSPF has a lower
administrative distance (is that a Juniper term too, or just a Cisco
term?) than iBGP. This shouldn't prevent the route from being
announced to eBGP peers (at least it doesn't in Cisco land, but maybe
there are differences in how J and C work in this regard which I'm
missing) should it?
u...@router> show route 69.57.14.0 detail
inet.0: 296972 destinations, 664182 routes (296971 active, 0 holddown,
1 hidden)
69.57.14.0/24 (2 entries, 1 announced)
*OSPF Preference: 150
Next hop type: Router, Next hop index: 530
Next-hop reference count: 1262
Next hop: 72.15.49.21 via ge-2/0/1.0, selected
State: <Active Int Ext>
Local AS: 21949
Age: 1:11:22 Metric: 2020 Tag: 0
Task: OSPFv2
Announcement bits (2): 0-KRT 5-Resolve tree 1
AS path: I
BGP Preference: 170/-791
Next hop type: Indirect
Next-hop reference count: 1
Source: 72.15.48.2
Next hop type: Router, Next hop index: 530
Next hop: 72.15.49.21 via ge-2/0/1.0, selected
Protocol next hop: 206.223.182.67
Indirect next hop: 155101d4 1048579
State: <Int Ext>
Inactive reason: Route Preference
Local AS: 21949 Peer AS: 21949
Age: 1:11:27 Metric: 0 Metric2: 2020
Task: BGP_21949.72.15.48.2+179
AS path: I (Originator) Cluster list: 66.207.194.20
AS path: Originator ID: 72.15.48.6
Communities: 21949:70 21949:790
Localpref: 790
Router ID: 66.207.194.20
u...@router>
On 2009-10-07, at 7:42 PM, Stefan Fouant wrote:
You may have received the route via your iBGP peer, but is it active?
Do a 'show route x.x.x.x detail' to see if that particular route is
active in the routing table and post your results here...
On 10/7/09, Jason Lixfeld <ja...@lixfeld.ca> wrote:
I'm pretty new to JunOS and I'm running up against an issue that I'm
not sure how to troubleshoot or debug.
I have an iBGP prefix that is being learned by my M120/9.1R1.8 box,
but it's not being announced to eBGP peers:
u...@router> show route advertising-protocol bgp 38.104.158.173 |
match 69.57
u...@router>
I see the prefix has been received from the iBGP router:
u...@router> show route receive-protocol bgp 72.15.48.2 extensive
69.57.14.0/24
inet.0: 296881 destinations, 664001 routes (296880 active, 0
holddown,
1 hidden)
69.57.14.0/24 (2 entries, 1 announced)
Nexthop: 72.15.48.6
MED: 0
Localpref: 790
AS path: I (Originator) Cluster list: 66.207.194.20
AS path: Originator ID: 72.15.48.6
Communities: 21949:70 21949:790
u...@router>
Looking at the configuration for this particular eBGP peer, it's
configured to announce prefixes tagged with one of the communities
attached to this route, 21949:70. I've also verified that there are
other prefixes with the same communities as above being announced to
this eBGP peer without incident.
u...@router> show configuration protocols bgp group paidpeers
type external;
mtu-discovery;
import PP-NA-TOR-FRONT-GENERIC-IN;
export PP-GENERIC-OUT;
neighbor 38.104.158.173 {
family inet {
unicast;
}
peer-as 174;
}
u...@router> show configuration policy-options policy-statement PP-
GENERIC-OUT
term transit-routes {
from community TRANSIT;
then reject;
}
term peering-routes {
from community PEERING;
then reject;
}
term paidpeering-routes {
from community PAIDPEERING;
then reject;
}
term local-routes {
from community LOCAL;
then {
community delete all;
accept;
}
}
term customer-routes {
from community CUSTOMER;
then {
community delete all;
accept;
}
}
term backbone-static {
from {
protocol static;
route-filter 72.15.48.0/20 exact;
}
then accept;
}
term default {
then reject;
}
u...@router> show configuration policy-options community LOCAL
members 21949:70;
Just to be sure there aren't any typos in the community lists, there
is only one that has 21949:70 as a member:
u...@router> show configuration policy-options | match 21949:70
community LOCAL members 21949:70;
u...@router>
I'm at a loss to understand why or how this prefix is any different
than any of the others that match the same community string. I've
tried to monitor bgp traceoptions flag update and while I see updates
coming through, I don't see anything for this specific prefix even if
I withdraw it from iBGP (I'd expect to see an update because the
prefix is certainly withdrawn from the BGP table on the router as I
remove it from BGP on the originating router).
Anyone have any ideas on either the issue itself or how I can get
some
more debugging/troubleshooting info out of the box?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Stefan Fouant
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
