[j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

[Doug Hanks]

The static discard works just fine, but from what from I recall a simple
static route would not insert the ATOMIC_AGGREGATE into BGP.

For example to advertise 192.168.1.0/24 with ATOMIC_AGGREGATE.

set routing-options static route 192.168.1.1/32 discard (contributing
route)   
set routing-options aggregate route 192.168.1/24 as-path atomic-aggregate
(atomic aggregate)

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 6/22/12 4:26 AM, "EXT - plunin at senetsy.ru" <plunin at senetsy.ru> wrote:

>
>
>> I have a /24 I want to announce, but I don't actually have it anywhere
>>on
>> the network. I NAT some of its IP's on the SRX that has the BGP session
>> with our providers.
>Static discard is really the best way. Aggregate/generate routes are
>also theoretically possible, but if you are not sure you really need
>some sort of external dynamism, it's better to nail it down with static
>‹ less chances to have your routes damped somewhere after an internal
>link flap.
>>
>> I've been using static routes with the discard flag, but I don't really
>> like the way the SRX handles traffic. It still creates sessions for
>>traffic
>> destined to IP's not used anywhere (hitting the static route) and can be
>> easily dos'd because of this.
>I saw such a thing a couple of times and it was not because SRX handles
>traffic wrongly, but due to some sort of misconfiguration. If a packet
>fell under the discard route, the session would not be created
>(otherwise you caught a real showstopper bug, but I don't much believe
>in this, to be honest). Moreover, in order to have a session established
>you also need a security policy permit.
>
>1. Check the route where the packets actually fall under with "show
>security flow session session-identifier <xxxx>". Very likely that your
>packets actually fall under a longer specific route. Say, automatically
>generated for proxy-arp or something like.
>
>2. Check the zones, from and to which the sessions are established,
>which policy permits the traffic. As of what you describe, policies
>should block such traffic anyway.
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp