BGP Communities - routes reside inside the local AS

Setting the NO-EXPORT BGP community 

BGP communities are attributes that maybe added to every prefix we choose. This is very interesting if one wants to logically separate incoming and outgoing traffic. With communities we have more granular control over the data plane inside our Autonomus system. 

The communities attribute is a way to group destinations into communities and apply routing decisions based on the communities. This method simplifies the configuration of a BGP speaker that controls distribution of routing information.

The communities attribute is an optional, transitive, global attribute in the numerical range from 1 to 4,294,967,200. Along with Internet community, there are a few predefined, well-known communities, as follows:

• internet—Advertise this route to the Internet community. All routers belong to it.
• no-export—Do not advertise this route to eBGP peers.
• no-advertise—Do not advertise this route to any peer (internal or external).
• local-as—Do not advertise this route to peers outside the local autonomous system. This route will not be advertised to other autonomous systems or sub-autonomous systems when confederations are configured.

In this small case scenario we have a customer AS 100 that does not want some prefixes to be advertised outside his own AS. Maybe the prefixes are malicious, or they have no agreement with the ISP companies or within any other reason this can be done with using the BGP default community NO-EXPORT. Let us take a look into the diagram.

In our small example we will be looking at the CX1 router and some of the ISP routing tables. First let us take a look at the BGP configs of the CX1 router, and the BGP table of the ISP2 router.

We can see that the ISP2 router has the two prefixes inside the RIB table. Those the prefixes we do not want to advertise outside the AS100. This is achieved via a simple route-map and an ACL that is associated with the desired traffic.

CX1#sh ip access-lists

Standard IP access list 1

    10 permit 44.44.44.0, wildcard bits 0.0.1.255 (2 matches)

CX1#sh route-map

route-map NO-EXPORT, permit, sequence 10

  Match clauses:

    ip address (access-lists): 1

  Set clauses:

    community no-export

  Policy routing matches: 0 packets, 0 bytes

CX1

neighbor 16.1.1.2 send-community both

 neighbor 16.1.1.2 route-map NO-EXPORT out

We have an ACL that is used to capture source of loopback address advertised with the prefixes 44.44.44.0/24 and 44.44.45.0/24. After that I have created an route-map called NO-EXPORT that uses the acl 1 and sets the community no-export on those prefixes. Then we have applied this route map to the neighbor inside the AS100.

Now let us see the RIB table of the ISP2 router.

And it is working fine, we do not see the prefixes we stopped to advertise. We can verify this further on the edge router of the AS100. 

CUSTOMER#sh ip bgp neighbors 172.16.1.2 advertised-routes

BGP table version is 11, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 1.1.1.1/32       0.0.0.0                  0         32768 i

*> 2.2.2.2/32       192.168.1.2              0             0 200 i

*> 3.3.3.3/32       172.16.1.2               0             0 300 i

*>i5.5.5.5/32       17.1.1.2                 0    100      0 i

We can see that the prefixes are not being advertised to the eBGP neighbor as we intended. Down following we can see the BGP table of the AS100 edge router.

Total number of prefixes 4

CUSTOMER#sh ip bgp 44.44.44.0

BGP routing table entry for 44.44.44.0/24, version 10

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)

  Not advertised to any peer

  Local

    16.1.1.1 from 16.1.1.1 (4.4.4.4)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      Community: no-export

The prefix 44.44.44.0 is in the routing table but it has the no-export community attached to the route. Thus the prefix is not being exported to the eBGP neighbors. Very simple and clean.

Feel free to comment.

Junos eBGP basic

Simple basic Junos BGP configuration

As in the other networking vendor designs, Juniper has similar checklist in configuring basic eBGP:

• You have to identify the AS to which each of the peering routers belongs. Every AS in the world is uniquely identified by an AS number.

• You have to decide on a group for the peering session. BGP groups everything so that you can have logical sets of connections that all behave more or less the same way.

• You must know the specific IP address of the interface to which you’re connecting. This address is the neighbor address, as it’s the neighboring interface with which you are peering.

In this simple scenario we are starting out with two AS numbers in our lab 100 and 200 with directly connected eBGP neighbors. The routers Junos01 and Junos02 have startup configs of the interface IP adresses and routes. 

Here is the basic diagram:

First we setup the interface IP addresses for both the routers so we can achieve connectivity.

< JUNOS01 >

interfaces {

    em0 {

        unit 0 {

            family inet {

                address 12.12.12.1/24;

            }

        }

    }

    em1 {

        unit 0 {

            family inet {

                address 111.111.111.111/24;

            }

        }

    }

    lo0 {

        unit 0 {

            family inet {

                address 1.1.1.1/24;

                address 11.11.11.11/24;

            }

        }

    }

}

< JUNOS02 >

interfaces {

    em0 {

        unit 0 {

            family inet {

                address 12.12.12.2/24;

            }

        }

    }

    em1 {

        unit 0 {

            family inet {

                address 222.222.222.222/24;

            }

        }

    }

    lo0 {

        unit 0 {

            family inet {

                address 2.2.2.2/24;

                address 22.22.22.22/24;

            }

        }

    }

}

After setting the IP addresses we define the Autonomous system and the Router ID number which will be used to recognize the routers in BGP update negotiation.

< JUNOS01 >

routing-options {

    router-id 1.1.1.1;

    autonomous-system 100;

}

< JUNOS02 >

routing-options {

    router-id 2.2.2.2;

    autonomous-system 200;

}

We use the IP addresses of the loopbacks as the router ID , for a natural reason of loopbacks being always active and in case of dropping the links we could achieve BGP reachability. 

Next step is setting the BGP external groups with the type option and defining the peer address.

As this sounds very simple we will complicate the basic eBGP setup with another simple policy that is exporting directly attached interfaces to the BGP updates. This is a common thing an eBGP scenarios which is helpful in providing the reachability of the next hop address.

< JUNOS01 >

protocols {

    bgp {

        export EXP_LOOP;

        group eBGP {

            type external;

            peer-as 200;

            neighbor 12.12.12.2;

        }

    }

}

policy-options {

    policy-statement EXP_LOOP {

        term T1 {

            from protocol direct;

            then accept;

        }

    }

}

< JUNOS02 >

protocols {

    bgp {

        export EXP_LOOPS;

        group eBGP {

            type external;

            peer-as 100;

            neighbor 12.12.12.1;

        }

    }

}

policy-options {

    policy-statement EXP_LOOPS {

        term T1 {

            from protocol direct;

            then accept;

        }

    }

}

In the eBGP group statement we define the group as external eBGP and the peer Autonomous system. Also we should not forget the neighbor IP address. 

One more thing to do is to log on to the Junos01 router and see if the eBGP session is active and if the neighbors are seeing each other.

root@JUNOS1# run show bgp neighbor

Peer: 12.12.12.2+52301 AS 200  Local: 12.12.12.1+179 AS 100

  Type: External    State: Established    Flags: <ImportEval Sync>

  Last State: OpenConfirm   Last Event: RecvKeepAlive

  Last Error: Cease

  Export: [ EXP_LOOP ]

  Options: <Preference PeerAS Refresh>

  Holdtime: 90 Preference: 170

  Number of flaps: 0

  Error: 'Cease' Sent: 1 Recv: 0

  Peer ID: 2.2.2.2          Local ID: 1.1.1.1          Active Holdtime: 90

  Keepalive Interval: 30         Peer index: 0

  BFD: disabled, down

  Local Interface: em0.0

  NLRI for restart configured on peer: inet-unicast

  NLRI advertised by peer: inet-unicast

  NLRI for this session: inet-unicast

  Peer supports Refresh capability (2)

  Restart time configured on the peer: 120

  Stale routes from peer are kept for: 300

  Restart time requested by this peer: 120

  NLRI that peer supports restart for: inet-unicast

  NLRI that restart is negotiated for: inet-unicast

  NLRI of received end-of-rib markers: inet-unicast

  NLRI of all end-of-rib markers sent: inet-unicast

  Peer supports 4 byte AS extension (peer-as 200)

  Peer does not support Addpath

  Table inet.0 Bit: 10000

    RIB State: BGP restart is complete

    Send state: in sync

    Active prefixes:              4

    Received prefixes:            5

    Accepted prefixes:            5

    Suppressed due to damping:    0

    Advertised prefixes:          4

  Last traffic (seconds): Received 13   Sent 15   Checked 44

  Input messages:  Total 23     Updates 2       Refreshes 0     Octets 525

  Output messages: Total 25     Updates 1       Refreshes 0     Octets 578

  Output Queue[0]: 0

The output of the show command tells us that the session is active and that the EXP_LOOPS policy is working fine. We are advertising loopback prefixes to our neighbors as we mentioned before.

Future Junos labs comming up.