Re: [j-nsp] MX204 and IPv6 BGP announcements

[Lee Starnes via juniper-nsp]

All very good information. Thanks guys for all the replies. very helpful.

On Thu, Feb 8, 2024 at 6:42 AM Mark Tinka  wrote:

>
>
> On 2/8/24 16:29, Saku Ytti wrote:
>
> In absence of more specifics, junos by default doesn't discard but
> reject.
>
>
> Right, which I wanted to clarify if it does the same thing with this
> specific feature, or if it does "discard"
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Mark Tinka via juniper-nsp]

On 2/8/24 16:29, Saku Ytti wrote:


In absence of more specifics, junos by default doesn't discard but
reject.


Right, which I wanted to clarify if it does the same thing with this 
specific feature, or if it does "discard"


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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Saku Ytti via juniper-nsp]

On Thu, 8 Feb 2024 at 16:07, Mark Tinka via juniper-nsp
 wrote:

> So internally, if it attracts any traffic for non-specific destinations,
> does Junos send it /dev/null in hardware? I'd guess so...

In absence of more specifics, junos by default doesn't discard but
reject. There is essentially implied 0/0 static route to reject
adjacency. This can be changed to be discard, or you can just nail
down default discard.


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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Jeff Haas via juniper-nsp]

Correcting myself, yes, it’s discard.

-- Jeff




Juniper Business Use Only
From: Mark Tinka 
Date: Thursday, February 8, 2024 at 9:07 AM
To: Jeff Haas , Lee Starnes , 
"juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] MX204 and IPv6 BGP announcements

[External Email. Be cautious of content]


On 2/8/24 15:48, Jeff Haas wrote:
It’s rib-only.  If you wanted the usual other properties, you’d use the usual 
other features.

So internally, if it attracts any traffic for non-specific destinations, does 
Junos send it /dev/null in hardware? I'd guess so...

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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Mark Tinka via juniper-nsp]

On 2/8/24 15:48, Jeff Haas wrote:

It’s rib-only.  If you wanted the usual other properties, you’d use 
the usual other features.




So internally, if it attracts any traffic for non-specific destinations, 
does Junos send it /dev/null in hardware? I'd guess so...


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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Jeff Haas via juniper-nsp]

It’s rib-only.  If you wanted the usual other properties, you’d use the usual 
other features.

-- Jeff




Juniper Business Use Only
From: Mark Tinka 
Date: Thursday, February 8, 2024 at 12:14 AM
To: Jeff Haas , Lee Starnes , 
"juniper-nsp@puck.nether.net" 
Subject: Re: [j-nsp] MX204 and IPv6 BGP announcements

[External Email. Be cautious of content]


On 2/6/24 19:42, Jeff Haas wrote:



And for situations where you need it nailed up:



https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bgp-static-edit-routing-options.html

Interesting, never knew about this BGP-specific feature.

What does the router do with this in FIB? Same as a a regular static route 
pointing to 'discard'? Or does it just stay in RIB?

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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Mark Tinka via juniper-nsp]

On 2/6/24 19:42, Jeff Haas wrote:


And for situations where you need it nailed up:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bgp-static-edit-routing-options.html


Interesting, never knew about this BGP-specific feature.

What does the router do with this in FIB? Same as a a regular static 
route pointing to 'discard'? Or does it just stay in RIB?


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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Jeff Haas via juniper-nsp]

On 2/6/24, 11:55 AM, "juniper-nsp on behalf of Mark Tinka via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:
> Typically, BGP will not originate a route to its neighbors unless it
> already exists in the routing table through some source. If it is an
> aggregate route, a hold-down pointing to "discard" (Null0 in Cisco) is
> enough. If it is a longer route assigned to a customer, that route
> pointing to the customer will do.

And for situations where you need it nailed up:

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/bgp-static-edit-routing-options.html


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

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Lee Starnes via juniper-nsp]

Thanks Mark for the quick reply. That was the validation I was looking for.
The TAC tech was really unsure about what he was doing and I had to guide
him through things, So this is very helpful.

Thanks again.

-Lee


On Tue, Feb 6, 2024 at 8:54 AM Mark Tinka  wrote:

>
>
> On 2/6/24 18:48, Lee Starnes via juniper-nsp wrote:
>
> > Hello everyone,
> >
> > I was having difficulty in getting an announcement of a IPv6 /32 block
> > using prefix-lists rather than redistribution of the IP addresses in from
> > other protocols. We only have a couple /64 blocks in use at the moment
> but
> > want to be able to announce the entire /32. In cisco, that would just be
> a
> > holddown route and then announce. Not sure how it works to Juniper.
> >
> > I configured a prefix-list that contained the /32 block in it. Then
> created
> > a policy statement with term 1 from prefix-list  and then term 2
> then
> > accept. Set the export in BGP protocol peer of this policy statement and
> it
> > just ignores it.
> >
> > Now this same setup in IPv4 works fine.
> >
> > After a week of going round and round with Juniper TAC, they had me
> setup a
> > rib inet6 aggregate entry for the /32 and then use that in the policy
> > statement.
>
> This is the equivalent of the "hold-down" route you refer to in
> Cisco-land. Useful if the route does not exist in the RIB from any other
> source.
>
> I'm guessing your IPv4 route just works without a hold-down route
> because it is being learned from somewhere else (perhaps your IGP, iBGP
> or a static route), and as such, already exists in the router's RIB for
> your export policy to pick it up with no additional fiddling.
>
> Typically, BGP will not originate a route to its neighbors unless it
> already exists in the routing table through some source. If it is an
> aggregate route, a hold-down pointing to "discard" (Null0 in Cisco) is
> enough. If it is a longer route assigned to a customer, that route
> pointing to the customer will do.
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and IPv6 BGP announcements

[Mark Tinka via juniper-nsp]

On 2/6/24 18:48, Lee Starnes via juniper-nsp wrote:


Hello everyone,

I was having difficulty in getting an announcement of a IPv6 /32 block
using prefix-lists rather than redistribution of the IP addresses in from
other protocols. We only have a couple /64 blocks in use at the moment but
want to be able to announce the entire /32. In cisco, that would just be a
holddown route and then announce. Not sure how it works to Juniper.

I configured a prefix-list that contained the /32 block in it. Then created
a policy statement with term 1 from prefix-list  and then term 2 then
accept. Set the export in BGP protocol peer of this policy statement and it
just ignores it.

Now this same setup in IPv4 works fine.

After a week of going round and round with Juniper TAC, they had me setup a
rib inet6 aggregate entry for the /32 and then use that in the policy
statement.


This is the equivalent of the "hold-down" route you refer to in 
Cisco-land. Useful if the route does not exist in the RIB from any other 
source.


I'm guessing your IPv4 route just works without a hold-down route 
because it is being learned from somewhere else (perhaps your IGP, iBGP 
or a static route), and as such, already exists in the router's RIB for 
your export policy to pick it up with no additional fiddling.


Typically, BGP will not originate a route to its neighbors unless it 
already exists in the routing table through some source. If it is an 
aggregate route, a hold-down pointing to "discard" (Null0 in Cisco) is 
enough. If it is a longer route assigned to a customer, that route 
pointing to the customer will do.


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

[j-nsp] MX204 and IPv6 BGP announcements

[Lee Starnes via juniper-nsp]

Hello everyone,

I was having difficulty in getting an announcement of a IPv6 /32 block
using prefix-lists rather than redistribution of the IP addresses in from
other protocols. We only have a couple /64 blocks in use at the moment but
want to be able to announce the entire /32. In cisco, that would just be a
holddown route and then announce. Not sure how it works to Juniper.

I configured a prefix-list that contained the /32 block in it. Then created
a policy statement with term 1 from prefix-list  and then term 2 then
accept. Set the export in BGP protocol peer of this policy statement and it
just ignores it.

Now this same setup in IPv4 works fine.

After a week of going round and round with Juniper TAC, they had me setup a
rib inet6 aggregate entry for the /32 and then use that in the policy
statement.

It seemed kinda clugy, so just wanted to ask here if this is the typical
way of going about this or is there a better more accepted way of doing
this?

Thanks,

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