Blocking local routes advertised to BGP

[PeteW]

Hey guys,

I have an issue in that I am advertising the private subnets into BGP from my J4350 to our Cisco 7206 routers.

I want to block this traffic and was under the impression that the following would suffice?

protocols BGP:

local-address 83.x.x.x;
log-updown;
damping;
export next-hop-self;  <-- only exporting the i/f address
graceful-restart;
neighbor 83.x.x.x {
        local-preference 150;
    peer-as x.x.x.x;
}
neighbor 83.x.x.x {
        local-preference 150;
    peer-as x.x.x.x;
}
 

But when I check the cisco routers I see the 10.x.x.x addresses being seen as advertised via BGP from the juniper 83.x.x.x i/f. Am I missing something here? It's as if redistribute static is on by default?

How can I block the local 10.0.0.0/8 subnet (mgmt i/f) from being advertised?

Pete

[davidjdv]

Hello Pete,

The default behaviour is for BGP to advertise routes learned via BGP (not static, nor direct/connected routes).

The export next-hop-self simply means that you have an export policy called "next-hop-self"... we need to see what is configured there to comment further.

Can you please send 'show configuration policy-options' ?

Regards,

/david 

[PeteW]

Thanks for the response David please see requested info.

policy-statement load-balancing {
    then {
        load-balance per-packet;
    }
}
policy-statement next-hop-self {
    then {
        next-hop self;
        accept;
    }
}
policy-statement nomartians {
    term martians {
        from {
            route-filter 0.0.0.0/8 orlonger reject;
            route-filter 10.0.0.0/8 orlonger reject;
            route-filter 127.0.0.0/8 orlonger reject;
            route-filter 169.254.0.0/16 orlonger reject;
            route-filter 172.16.0.0/12 orlonger reject;
            route-filter 192.0.2.0/24 orlonger reject;
            route-filter 192.168.0.0/16 orlonger reject;
            route-filter 198.18.0.0/15 orlonger reject;
            route-filter 224.0.0.0/3 orlonger reject;
        }
    }
    then accept;
}
policy-statement noprivates {
    from as-path private;
    then reject;
}
policy-statement nosmallprefixes {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
    }
}
policy-statement our-routes {
    term our-routes {
        from {
            prefix-list our-routes;
        }
        then accept;
    }
    then reject;
}
community all members *:*;
as-path private 64512-65535;

[davidjdv]

I have to say I find this config a bit confusing...

All 'next-hop self' does is, for the matching routes (all in this case) it sets the next-hop to that used by the router. This is not necessary on a EBGP session since this is the default behaviour.

Now, if you are advertising 10.x subnets, I can only assume you are learning them through BGP... do you have IBGP sessions configured too ?

Can you send a 'show route 10/8' ? And if possible, the rest of the config as well... What is the nomartians policy meant to do ? Is it applied somewhere ? This policy rejects private addresses (although I would not call them "martians"  )

Regards,

/david 

[PeteW]

David,

show route 10/8

inet.0: 22 destinations, 29 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.200.1.0/24      *[Direct/0] 3d 04:33:56
                    > via ge-0/0/0.0
10.200.1.248/32    *[Local/0] 3d 04:34:00
                      Local via ge-0/0/0.0

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.1/32        *[Direct/0] 3d 04:34:02
                    > via lo0.16385
10.0.0.16/32       *[Direct/0] 3d 04:34:02
                    > via lo0.16385

The martians config is applied to another BGP group and is not affected by the config supplied so far. The config I supplied was for an iBGP session between the juniper and cisco routers.

The other bgp session thats currently inactive uses the following:

import [ linx-peer-nap-in nomartians nosmallprefixes noprivates ];
export [ our-routes next-hop-self ];

I do find it quite bizarre that the local private IP'd interface is being advertised to BGP when clearly this shouldn't happen by default

[PeteW]

This is a tad weird ...

show route 10.200.1.248/32 detail

inet.0: 22 destinations, 29 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
10.200.1.248/32 (1 entry, 1 announced)
        *Local  Preference: 0
                Next hop type: Local
                Next-hop reference count: 4
                Interface: ge-0/0/0.0
                State: <Active NoReadvrt Int>   <--- it shouldn't be advertised with this flag being set?
                Local AS: X.X.X.X
                Age: 3d 4:52:57
                Task: IF
                Announcement bits (1): 3-Resolve tree 1
                AS path: I

I was under the impression that NoReadvrt forced it to not be advertised?

Message Edited by PeteW on 04-09-2009 06:28 AM

[davidjdv]

This is expected, we automatically mark the host routes corresponding to our own physical interfaces as NoReadvrt because it is expected that we advertise the subnet instead.

Can you send the complete BGP config ? 'show config proto bgp'

For IBGP sessions, the "best practice" is to configure 'type internal' and not specify a peer-as... although I doubt this is causing the problem.

Can you also please send 'show route advertising-protocol bgp <peer_ip_address>' for both IBGP neighbours ? 

[PeteW]

David, as requested.

traceoptions {
    file bgp_log size 50000 world-readable;
    flag update;
    flag route;
}
log-updown;
family inet {
    any {
        prefix-limit {
            maximum 100000;
            teardown 80;
        }
    }
}
inactive: group XXXX {
    type external;
    description "XXXX specific BGP peering";
    damping;
    import [ nomartians nosmallprefixes noprivates ];
    export [ our-routes next-hop-self ];
    neighbor x.x.x.x {
        peer-as xxxx;
    }
    neighbor x.x.x.x {
        peer-as xxxx;

}

group IBGP-JUNIPER {
    type internal;
    log-updown;
    damping;
    export next-hop-self;
    graceful-restart;
    neighbor 83.x.x.105 {
        description "INT-RTR-01 Gi0/3.706";
        local-preference 150;
        peer-as XXXX;
    }
    neighbor 83.x.x.106 {
        description "RTR-02 Gi0/3.706";
        local-preference 150;
        peer-as XXXX;
    }
}

JRT-03> show route advertising-protocol bgp 83.x.x.105

inet.0: 22 destinations, 29 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               Self                         150        I
* 10.200.1.0/24           Self                         150        I
* 83.x.x.104/29           Self                         150        I

JRT-03> show route advertising-protocol bgp 83.x.x.106

inet.0: 22 destinations, 29 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               Self                         150        I
* 10.200.1.0/24           Self                         150        I
* 83.x.x.104/29           Self                         150        I

JRT-03>

[davidjdv]

OK - I guess I figured out where the problem is coming from...

Your 'next-hop-self' policy is basically implicitly accepting all active routes in the routing table and setting the next-hop to "self".

Next-hop-self is only really necessary in an IBGP export policy for routes learned via an EBGP session.

What are the routes that you want to advertise ?

You should remove the next-hop-self policy from the export list to the EBGP neighbor and then modify the policy as follows:

term only-EBGP-routes { 

    from { 

        protocol bgp; 

        neighbor x.x.x.x;  # EBGP neighbour

    } 

    then { 

        next-hop self; 

    }

}

term private-routes {

    from {

        route-filter 10/8 orlonger;

    } 

    then {

        reject;

    }

} 

term remaining-routes {

    then accept;

} 

Message Edited by davidjdv on 04-09-2009 04:36 PM

[PeteW]

David,

I've removed the export statement on the iBGP group and the routes are no longer advertised. I'll reconfigure as requested and advise once we can test this hopefully next week.

Thanks for your assistance on this, much appreciated.

Pete