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

[Morgan Mclean]

What protocol do these aggregates show up under? Not static?

Morgan

Sent from my iPhone

On Jun 22, 2012, at 9:15 AM, Doug Hanks <dhanks at juniper.net> wrote:

> 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
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp