[j-nsp] optimized switchover
Matthias Gelbhardt
matthias at commy.de
Tue Sep 8 07:07:12 EDT 2009
Hi!
I see now only outgoing BFD packets... Perhaps I should better think
about using an IGP for the internal communication.
Matthias
Matthias Gelbhardt schrieb:
> Hi!
>
> I do not understand why, but I do not see packets on the other router.
> But there is no icmp either, when I ping the other side. The ES is on
> one router, but in routermode. But I have explicitly allowed BFD now.
> Strange, I do not understand, why the tcpdump is not working correctly.
>
> Matthias
>
> Nilesh Khambal schrieb:
>> Hi Matthias,
>>
>> I am no expert on J-Seris, but looking at BFD state, I feel that there
>> is an
>> issue sending or receiving BFD packets on your Router B. AdminDown state
>> here may mean that no packets were ever received from Router A. If you
>> are
>> running a Junos Enhanced Services version on these J-Series routers,
>> can you
>> check if any specific policy needs to be created to allow these BFD
>> packets
>> (UDP/3784)? Also, check if any firewall filters blocking BFD packets.
>> Try to
>> run tcpdump on both routers to see if BFD packets are being received
>> or not.
>>
>>
>> Thanks,
>> Nilesh.
>>
>>
>> On 9/8/09 1:40 AM, "Matthias Gelbhardt" <matthias at commy.de> wrote:
>>
>>> Hi!
>>>
>>> No, actually they are directly connected, so I do not know, why there is
>>> a multihop output. Perhaps somehow he thinks to be not directly
>>> connected and that is the problem?
>>>
>>> Both routers are J6350.
>>>
>>> Regards,
>>>
>>> Matthias
>>>
>>> Nilesh Khambal schrieb:
>>>> Hi Matthias,
>>>>
>>>> Are these peers established over a directly connected IPs or is this an
>>>> indirect session?
>>>>
>>>> The session shows multihop on both routers from the show output
>>>> provided
>>>> below.
>>>> What is the router platform on both sides?
>>>>
>>>> Thanks,
>>>> Nilesh
>>>>
>>>> On 9/8/09 1:25 AM, "Matthias Gelbhardt" <matthias at commy.de> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> That is the doc I have used for configuring.
>>>>>
>>>>> Both routers are Juniper routers over a Laver 2 Link directly
>>>>> connected.
>>>>> One router is 9.3R2.8 The other 9.4R2.9.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Matthias
>>>>>
>>>>> Nilesh Khambal schrieb:
>>>>>> Hi Matthias,
>>>>>>
>>>>>> What JUNOS version are you running on this router? Is other end
>>>>>> router also
>>>>>> a Juniper router? Are both peers directly connected or is this a
>>>>>> multihop
>>>>>> session?
>>>>>>
>>>>>> Try this doc link see if it can help.
>>>>>>
>>>>>>
>> http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-routing/i>>>>
>>
>> d
>>>>>> -13279139.html#id-13279139
>>>>>>
>>>>>> Thanks,
>>>>>> Nilesh.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/8/09 12:53 AM, "Matthias Gelbhardt" <matthias at commy.de> wrote:
>>>>>>
>>>>>>> Has no one an idea? It seems, that I am really stuck here. Do I
>>>>>>> have to
>>>>>>> activate something on the other side (hence the AdminDown status?)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Matthias
>>>>>>>
>>>>>>> Matthias Gelbhardt schrieb:
>>>>>>>> Hello David,
>>>>>>>>
>>>>>>>> great tip. Unfortunatly BFD for BGP - though detailed documented
>>>>>>>> - has
>>>>>>>> no examples flying around. Perhaps I am missing something here.
>>>>>>>>
>>>>>>>> I have two routers connected via iBGP. I have tried to make the
>>>>>>>> configuration rather simple (only the important parts, BGP
>>>>>>>> session is up
>>>>>>>> and running):
>>>>>>>>
>>>>>>>> This is the same on both sides (change in the IP-addresses of
>>>>>>>> course)
>>>>>>>>
>>>>>>>> protocols bgp {
>>>>>>>> group internal {
>>>>>>>> type internal;
>>>>>>>> neighbor 91.190.xxx.xxx {
>>>>>>>> local-address 91.190.xxx.xxx;
>>>>>>>> bfd-liveness-detection {
>>>>>>>> minimum-interval 1000;
>>>>>>>> multiplier 3;
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Router A:
>>>>>>>> show bfd session extensive
>>>>>>>> Detect Transmit
>>>>>>>> Address State Interface Time Interval
>>>>>>>> Multiplier
>>>>>>>> 91.190.xxx.xxx Init 3.000
>>>>>>>> 1.000 3
>>>>>>>> Client BGP, TX interval 1.000, RX interval 1.000
>>>>>>>> Session down time 00:00:04
>>>>>>>> Local diagnostic CtlExpire, remote diagnostic None
>>>>>>>> Remote state Down, version 1
>>>>>>>> Min async interval 1.000, min slow interval 1.000
>>>>>>>> Adaptive async TX interval 1.000, RX interval 1.000
>>>>>>>> Local min TX interval 1.000, minimum RX interval 1.000,
>>>>>>>> multiplier 3
>>>>>>>> Remote min TX interval 1.000, min RX interval 1.000, multiplier 3
>>>>>>>> Local discriminator 1, remote discriminator 1
>>>>>>>> Echo mode disabled/inactive, no-absorb, no-refresh, update-adj
>>>>>>>> Multi-hop, min-recv-TTL 0, route table 0, local-address
>>>>>>>> 91.190.xxx.xxx
>>>>>>>>
>>>>>>>> 1 sessions, 1 clients
>>>>>>>> Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
>>>>>>>>
>>>>>>>> Router B:
>>>>>>>> show bfd session extensive
>>>>>>>> Detect Transmit
>>>>>>>> Address State Interface Time Interval
>>>>>>>> Multiplier
>>>>>>>> 91.190.xxx.xxx Down 0.000
>>>>>>>> 1.000 3
>>>>>>>> Client BGP, TX interval 1.000, RX interval 1.000
>>>>>>>> Local diagnostic None, remote diagnostic None
>>>>>>>> Remote state AdminDown, version 1
>>>>>>>> Min async interval 1.000, min slow interval 1.000
>>>>>>>> Adaptive async TX interval 1.000, RX interval 1.000
>>>>>>>> Local min TX interval 1.000, minimum RX interval 1.000,
>>>>>>>> multiplier 3
>>>>>>>> Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
>>>>>>>> Local discriminator 1, remote discriminator 0
>>>>>>>> Echo mode disabled/inactive, no-absorb, no-refresh
>>>>>>>> Multi-hop route table 0, local-address 91.190.xxx.xxx
>>>>>>>>
>>>>>>>> 1 sessions, 1 clients
>>>>>>>> Cumulative transmit rate 1.0 pps, cumulative receive rate 0.0 pps
>>>>>>>>
>>>>>>>> I see the diagnostic on router A but do not understand it. I
>>>>>>>> thought the
>>>>>>>> minimum-interval might be too low, so I set it up to a thousand.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>> David Ball schrieb:
>>>>>>>>> There are likely several answers to that, all dependant on your
>>>>>>>>> topology and protocol use. But, a good place to start would be BFD
>>>>>>>>> (bidirectional forwarding detection). Juniper has decent
>>>>>>>>> support for
>>>>>>>>> it working with other protocols (OSPF, ISIS, BGP, RIP),
>>>>>>>>> notifying them
>>>>>>>>> that something may be wrong, allowing them to then make a decision
>>>>>>>>> (support may differ from protocol to protocol). That may be a
>>>>>>>>> good
>>>>>>>>> start point.
>>>>>>>>>
>>>>>>>>> http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/
>>>>>>>>>
>>>>>>>>> sw
>>>>>>>>> co
>>>>>>>>> nfig-routing-IX.html#B
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David B
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/9/6 Matthias Gelbhardt <matthias at commy.de>:
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I wonder what the best practices for optimized switchovers
>>>>>>>>>> would be?
>>>>>>>>>> I mean
>>>>>>>>>> fast comprehension of failed BGP connections? A fibre cut or
>>>>>>>>>> something like
>>>>>>>>>> that, how can I be sure, that my routers are detecting the failed
>>>>>>>>>> session as
>>>>>>>>>> soon as possible? What would be the best practices fpr that?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Matthias
>>>>>>>>>> _______________________________________________
>>>>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>> _______________________________________________
>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> 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