Routing

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

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 

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;

 

 

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 

 

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

 

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?

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 ? 

 

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>

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;

} 

 

 

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

OK - but I suppose that no routes are advertised at all now (since the EBGP group is inactive) 

You can double-check this with the 'show route advertising-protocol bgp ...' commands described above.

 

Please let us know exactly what you want to advertise (and/or block) and we can help you with the config.

 

Cheers,

/david 

Yep, thats ok and I appreciate that there are no routes advertised currently. It alleviates the current problem until we can work out the routes that "should" be advertised via iBGP.

 

Pete 

 

 

Hi PeteW,

 

 As David pointed out, you may want to alter your import/export policies to cover 'safety' mechanisms

as the first couple of terms, like the following example:

 

policy-statement ebgp-export {
    term no-small-prefixes {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /25-/32;
        }
        then reject;
    }
    term no-martians {
        from {
            route-filter 0.0.0.0/8 orlonger;
            route-filter 10.0.0.0/8 orlonger;
            route-filter 127.0.0.0/8 orlonger;
            route-filter 169.254.0.0/16 orlonger;
            route-filter 172.16.0.0/12 orlonger;
            route-filter 192.0.2.0/24 orlonger;
            route-filter 192.168.0.0/16 orlonger;
            route-filter 198.18.0.0/15 orlonger;
            route-filter 224.0.0.0/3 orlonger;
        }
        then reject;
    }
    term no-privates {
        from as-path private;
        then reject;
    }
    term accepted-prefixes { ## <<< this is where you start 'accepting'

       then accept;
    }
}

 

Applying similar import policies to your ebgp sessions (e.g. start with rejecting the 'usual suspects' then accept what you want later) might be a good idea as well.

 

I had read somewhere that paranoia was one's best friend while configuring BGP, and I still do believe that 🙂

 

Cheers,

Erdem

Many thanks for your assistance guys, the issue is now resolved and all appropriate routes are being advertised