Re: [j-nsp] Generating routes from inactive/hidden contributors

[Alexander Arseniev]

They will be - in .inet.0 virtual router, where the 
BGP session terminates.



On 05/03/2017 14:53, Chuck Anderson wrote:

Last time I checked the contributing routes have to be in the
destination RIB for the aggregate/generate to go active.

On Sun, Mar 05, 2017 at 11:26:18AM +, Alexander Arseniev wrote:

Hello,

Have You tried putting all routes from that peer in a routing-instance?

Then configure aggregate|generate in that instance and leak it into
inet.0|whereever the other peers sit.

You can leak the whole table from that peer as well, but that
amounts to 2x route memory consumption by that peer.

HTH

Thx

Alex


On 03/03/2017 15:07, Tore Anderson wrote:

Hi,

* adamv0...@netconsultings.com


Interesting,
There appears to be no cmd to override the default, "contributing route has
to be active", requirement. (the "from state inactive" attachment point is
only the export policy).
I'm just thinking whether it's not working simply because the inactive
routes wouldn't be advertised anyways -so why to bother aggregating them
right?

True, but this is a generated route, not an aggregated route. They're
quite similar, but the generated routes can have next-hops (copied from
a contributing route), which means you don't really need the
contributing routes themselves to be active or even non-hidden to
actually forward packets somewhere useful.

Aggregated routes are on the other hand discard only, so then you need
the more-specific contributing routes with their next-hops to avoid
blackholing traffic.

(AIUI, anyway.)


But maybe if you enable "advertise-inactive" towards your iBGP -maybe
then the aggregation starts to work?

Perhaps, but if both the generated route and its contributors are
indeed inactive in the RIB and thus not found in the FIB, then I don't
think the router would be able to forward the packets it attracts to
where it should.


Alternatively, I'm thinking of something along the lines of making the
prefixes active (to allow the aggregate to be advertised), but use
them only for routing not for forwarding -so that FIB on a local
router is not skewed.

Yep, something like that would probably do the trick. I was hoping to
keep them out of the RIB in the first place though, to avoid having to
explicitly filter them on export to the FIB and iBGP peers, but maybe
there's no way around it.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Generating routes from inactive/hidden contributors

[Chuck Anderson]

Last time I checked the contributing routes have to be in the
destination RIB for the aggregate/generate to go active.

On Sun, Mar 05, 2017 at 11:26:18AM +, Alexander Arseniev wrote:
> Hello,
> 
> Have You tried putting all routes from that peer in a routing-instance?
> 
> Then configure aggregate|generate in that instance and leak it into
> inet.0|whereever the other peers sit.
> 
> You can leak the whole table from that peer as well, but that
> amounts to 2x route memory consumption by that peer.
> 
> HTH
> 
> Thx
> 
> Alex
> 
> 
> On 03/03/2017 15:07, Tore Anderson wrote:
> >Hi,
> >
> >* adamv0...@netconsultings.com
> >
> >>Interesting,
> >>There appears to be no cmd to override the default, "contributing route has
> >>to be active", requirement. (the "from state inactive" attachment point is
> >>only the export policy).
> >>I'm just thinking whether it's not working simply because the inactive
> >>routes wouldn't be advertised anyways -so why to bother aggregating them
> >>right?
> >True, but this is a generated route, not an aggregated route. They're
> >quite similar, but the generated routes can have next-hops (copied from
> >a contributing route), which means you don't really need the
> >contributing routes themselves to be active or even non-hidden to
> >actually forward packets somewhere useful.
> >
> >Aggregated routes are on the other hand discard only, so then you need
> >the more-specific contributing routes with their next-hops to avoid
> >blackholing traffic.
> >
> >(AIUI, anyway.)
> >
> >>But maybe if you enable "advertise-inactive" towards your iBGP -maybe
> >>then the aggregation starts to work?
> >Perhaps, but if both the generated route and its contributors are
> >indeed inactive in the RIB and thus not found in the FIB, then I don't
> >think the router would be able to forward the packets it attracts to
> >where it should.
> >
> >>Alternatively, I'm thinking of something along the lines of making the
> >>prefixes active (to allow the aggregate to be advertised), but use
> >>them only for routing not for forwarding -so that FIB on a local
> >>router is not skewed.
> >Yep, something like that would probably do the trick. I was hoping to
> >keep them out of the RIB in the first place though, to avoid having to
> >explicitly filter them on export to the FIB and iBGP peers, but maybe
> >there's no way around it.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Alexander Arseniev]

Hi,

Is that a copper SFP?

Then try to do series of rapid long pings across this link with any 
applicable policers/shapers deactivated.


If You see missed packets, replace this SFP and a patch cable as well.

HTH
Thx
Alex

On 05/03/2017 11:40, Mohammad Khalil wrote:

admin@CR02# run show interfaces diagnostics optics ge-2/1/0
Physical interface: ge-2/1/0
Optical diagnostics   :  N/A

On 5 March 2017 at 13:23, Alexander Arseniev > wrote:


Hello,

Check Your laser light levels :

show interfaces diagnostics optics ge-x/y/z

HTH

Thx
Alex


On 05/03/2017 10:51, Mohammad Khalil wrote:

As well , I have checked the log messages , and I can see the below message:
RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake

BR,
Mohammad

On 5 March 2017 at 12:24, Mohammad Khalil 
  wrote:


Hi
I have removed the whole filter from the lo0 interface and the same applies

BR,
Mohammad

On 5 March 2017 at 12:03,   
wrote:


I have a BFD session between two routers (which was working normally)
Currently , the session is down from one side and init from the other

side

The ISIS adjacency is up
What could be the issue?

Check if you you have firewall filter on lo0 which blocks UDP port 3784
or 3785.

Steinar Haug, Nethelp consulting,sth...@nethelp.no 



___
juniper-nsp mailing listjuniper-...@puck.nether.net 

https://puck.nether.net/mailman/listinfo/juniper-nsp




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Mohammad Khalil]

admin@CR02# run show interfaces diagnostics optics ge-2/1/0
Physical interface: ge-2/1/0
Optical diagnostics   :  N/A

On 5 March 2017 at 13:23, Alexander Arseniev 
wrote:

> Hello,
>
> Check Your laser light levels :
>
> show interfaces diagnostics optics ge-x/y/z
>
> HTH
>
> Thx
> Alex
>
> On 05/03/2017 10:51, Mohammad Khalil wrote:
>
> As well , I have checked the log messages , and I can see the below message:
> RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
>
> BR,
> Mohammad
>
> On 5 March 2017 at 12:24, Mohammad Khalil  
>  wrote:
>
>
> Hi
> I have removed the whole filter from the lo0 interface and the same applies
>
> BR,
> Mohammad
>
> On 5 March 2017 at 12:03,   wrote:
>
>
> I have a BFD session between two routers (which was working normally)
> Currently , the session is down from one side and init from the other
>
> side
>
> The ISIS adjacency is up
> What could be the issue?
>
> Check if you you have firewall filter on lo0 which blocks UDP port 3784
> or 3785.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
>  ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Generating routes from inactive/hidden contributors

[Alexander Arseniev]

Hello,

Have You tried putting all routes from that peer in a routing-instance?

Then configure aggregate|generate in that instance and leak it into 
inet.0|whereever the other peers sit.


You can leak the whole table from that peer as well, but that amounts to 
2x route memory consumption by that peer.


HTH

Thx

Alex


On 03/03/2017 15:07, Tore Anderson wrote:

Hi,

* adamv0...@netconsultings.com


Interesting,
There appears to be no cmd to override the default, "contributing route has
to be active", requirement. (the "from state inactive" attachment point is
only the export policy).
I'm just thinking whether it's not working simply because the inactive
routes wouldn't be advertised anyways -so why to bother aggregating them
right?

True, but this is a generated route, not an aggregated route. They're
quite similar, but the generated routes can have next-hops (copied from
a contributing route), which means you don't really need the
contributing routes themselves to be active or even non-hidden to
actually forward packets somewhere useful.

Aggregated routes are on the other hand discard only, so then you need
the more-specific contributing routes with their next-hops to avoid
blackholing traffic.

(AIUI, anyway.)


But maybe if you enable "advertise-inactive" towards your iBGP -maybe
then the aggregation starts to work?

Perhaps, but if both the generated route and its contributors are
indeed inactive in the RIB and thus not found in the FIB, then I don't
think the router would be able to forward the packets it attracts to
where it should.


Alternatively, I'm thinking of something along the lines of making the
prefixes active (to allow the aggregate to be advertised), but use
them only for routing not for forwarding -so that FIB on a local
router is not skewed.

Yep, something like that would probably do the trick. I was hoping to
keep them out of the RIB in the first place though, to avoid having to
explicitly filter them on export to the FIB and iBGP peers, but maybe
there's no way around it.

Tore
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Alexander Arseniev]

Hello,

Check Your laser light levels :

show interfaces diagnostics optics ge-x/y/z

HTH

Thx
Alex


On 05/03/2017 10:51, Mohammad Khalil wrote:

As well , I have checked the log messages , and I can see the below message:
RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake

BR,
Mohammad

On 5 March 2017 at 12:24, Mohammad Khalil  wrote:


Hi
I have removed the whole filter from the lo0 interface and the same applies

BR,
Mohammad

On 5 March 2017 at 12:03,  wrote:


I have a BFD session between two routers (which was working normally)
Currently , the session is down from one side and init from the other

side

The ISIS adjacency is up
What could be the issue?

Check if you you have firewall filter on lo0 which blocks UDP port 3784
or 3785.

Steinar Haug, Nethelp consulting, sth...@nethelp.no




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Mohammad Khalil]

admin@CR03# run show interfaces ge-2/0/0 | grep MTU
  Link-level type: 52, MTU: 1600, Speed: 1000mbps, BPDU Error: None,
Protocol bridge, MTU: 1600
Protocol inet, MTU: 1578
Protocol iso, MTU: 1575
Protocol inet6, MTU: 1578
Protocol mpls, MTU: 1566
Protocol multiservice, MTU: Unlimited
Protocol multiservice, MTU: Unlimited

On 5 March 2017 at 13:19, Mohammad Khalil  wrote:

> The inet MTU shows as 1578 , so I have pinged as below:
> run ping 10.0.0.10 size 1550 do-not-fragment
> sometime it shows packet loss and sometimes no
>
> On 5 March 2017 at 13:00,  wrote:
>
>> > As well , I have checked the log messages , and I can see the below
>> message:
>> > RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
>>
>> In which case it sounds like ISIS is also having problems. Can you
>> ping across the link with full MTU (inet MTU - 28, physical interface
>> - 42, both assuming no VLAN) and do-not-fragment? And no packet loss?
>>
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>>
>> >
>> > BR,
>> > Mohammad
>> >
>> > On 5 March 2017 at 12:24, Mohammad Khalil  wrote:
>> >
>> > > Hi
>> > > I have removed the whole filter from the lo0 interface and the same
>> applies
>> > >
>> > > BR,
>> > > Mohammad
>> > >
>> > > On 5 March 2017 at 12:03,  wrote:
>> > >
>> > >> > I have a BFD session between two routers (which was working
>> normally)
>> > >> > Currently , the session is down from one side and init from the
>> other
>> > >> side
>> > >> > The ISIS adjacency is up
>> > >> > What could be the issue?
>> > >>
>> > >> Check if you you have firewall filter on lo0 which blocks UDP port
>> 3784
>> > >> or 3785.
>> > >>
>> > >> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>> > >>
>> > >
>> > >
>>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Mohammad Khalil]

The inet MTU shows as 1578 , so I have pinged as below:
run ping 10.0.0.10 size 1550 do-not-fragment
sometime it shows packet loss and sometimes no

On 5 March 2017 at 13:00,  wrote:

> > As well , I have checked the log messages , and I can see the below
> message:
> > RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
>
> In which case it sounds like ISIS is also having problems. Can you
> ping across the link with full MTU (inet MTU - 28, physical interface
> - 42, both assuming no VLAN) and do-not-fragment? And no packet loss?
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> >
> > BR,
> > Mohammad
> >
> > On 5 March 2017 at 12:24, Mohammad Khalil  wrote:
> >
> > > Hi
> > > I have removed the whole filter from the lo0 interface and the same
> applies
> > >
> > > BR,
> > > Mohammad
> > >
> > > On 5 March 2017 at 12:03,  wrote:
> > >
> > >> > I have a BFD session between two routers (which was working
> normally)
> > >> > Currently , the session is down from one side and init from the
> other
> > >> side
> > >> > The ISIS adjacency is up
> > >> > What could be the issue?
> > >>
> > >> Check if you you have firewall filter on lo0 which blocks UDP port
> 3784
> > >> or 3785.
> > >>
> > >> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> > >>
> > >
> > >
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Mohammad Khalil]

As well , I have checked the log messages , and I can see the below message:
RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake

BR,
Mohammad

On 5 March 2017 at 12:24, Mohammad Khalil  wrote:

> Hi
> I have removed the whole filter from the lo0 interface and the same applies
>
> BR,
> Mohammad
>
> On 5 March 2017 at 12:03,  wrote:
>
>> > I have a BFD session between two routers (which was working normally)
>> > Currently , the session is down from one side and init from the other
>> side
>> > The ISIS adjacency is up
>> > What could be the issue?
>>
>> Check if you you have firewall filter on lo0 which blocks UDP port 3784
>> or 3785.
>>
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[Mohammad Khalil]

Hi
I have removed the whole filter from the lo0 interface and the same applies

BR,
Mohammad

On 5 March 2017 at 12:03,  wrote:

> > I have a BFD session between two routers (which was working normally)
> > Currently , the session is down from one side and init from the other
> side
> > The ISIS adjacency is up
> > What could be the issue?
>
> Check if you you have firewall filter on lo0 which blocks UDP port 3784
> or 3785.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BFD Session

[sthaug]

> I have a BFD session between two routers (which was working normally)
> Currently , the session is down from one side and init from the other side
> The ISIS adjacency is up
> What could be the issue?

Check if you you have firewall filter on lo0 which blocks UDP port 3784
or 3785.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] BFD Session

[Mohammad Khalil]

Hi all
I have a BFD session between two routers (which was working normally)
Currently , the session is down from one side and init from the other side
The ISIS adjacency is up
What could be the issue?

BR,
Mohammad
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp