[j-nsp] Troubleshooting BGP
Stevanus
stevanus at datacomm.co.id
Wed Oct 7 22:28:26 EDT 2009
Try to set advertise-inactive in bgp configuration setting
- Stevanus -
Jason Lixfeld wrote:
> 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?
>
> user at 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
>
> user at 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 <jason at 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:
>>>
>>> user at router> show route advertising-protocol bgp 38.104.158.173 |
>>> match 69.57
>>>
>>> user at router>
>>>
>>> I see the prefix has been received from the iBGP router:
>>>
>>> user at 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
>>>
>>> user at 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.
>>>
>>> user at 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;
>>> }
>>>
>>> user at 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;
>>> }
>>>
>>> user at 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:
>>>
>>> user at router> show configuration policy-options | match 21949:70
>>> community LOCAL members 21949:70;
>>>
>>> user at 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 at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>>
>> --
>> Stefan Fouant
>>
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> .
>
>
--
More information about the juniper-nsp
mailing list