Showing posts with label Routing. Show all posts
Showing posts with label Routing. Show all posts

Monday, September 2, 2013

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.

Friday, August 30, 2013

MultiProtocol BGP meshed IPv6 and IPv4

Implementing MP-BGP in a SP IPv6 and IPv4 network


The multiprotocol BGP (MBGP) feature adds capabilities to BGP to enable multicast routing policy throughout the Internet and to connect multicast topologies within and between BGP autonomous systems. In other words, multiprotocol BGP (MBGP) is an enhanced BGP that carries IP multicast routes. BGP carries two sets of routes, one set for unicast routing and one set for multicast routing. The routes associated with multicast routing are used by the Protocol Independent Multicast (PIM) to build data distribution trees.
The only three pieces of information carried by BGP-4 that are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI(expressed as IPv4 address prefixes). Any BGP speaker, including MBGP speakers, has to have an IPv4 address, which will be used, among other things, in the AGGREGATOR attribute. To enable BGP-4 to support routing for multiple Network Layer protocols the only two things that have to be added to BGP-4 are (a) the ability to associate a particular Network Layer protocol with the next hop information, and (b) the ability to associated a particular Network Layer protocol with NLRI.

MP-BGP is an extension to the BGP protocol that has an objective to carry routing information about:
  • other protocols
  • Multicast
  • MPLS VPN
  • IPv6
  • 6PE
  • CLNS
Exchange of Multi-Protocol NLRI must be negotiated at session set up.
For some practical presentation of the MP-BGP protocol I have created a small ISP lab with couple of UPSTREAM providers that will use the IPv6 and IPv4 prefix routing at the same time. This is a common practice nowadays in the ISP enviroment. 

We have a small ISP with two routers the are iBGP speakers and couple of eBGP peers with upstream connections. For those that are familiar with the IPV6 setup and address space this will come easy. I am using /127 networks for the WAN links to simulate only two IP address space in the peer connection. On the same physical link I am using also the IPv4 address to peer with the BGP speaking router. Now let us look at the configs, I will try to clarify every command. For more on MP-BGP protocol , one can read a RFC on that subject - RFC2858.

ISP1
ipv6 unicast-routing    >> important to turn on because by default IPV6 routing is disabled 
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 no ip address
 ipv6 address 2030:1::1/64   >> I have defined a couple of /64 networks to propagate to AS100
 ipv6 address 2030:2::1/64
 ipv6 address 2030:3::1/64
 ipv6 enable
!
interface FastEthernet0/0   >> dual IP stack  IPv4 and IPv6 address on the WAN link
 ip address 10.0.0.2 255.255.255.252  
 duplex auto
 speed auto
 ipv6 address 2005:1::/127   << /127 networks allows only two IPv6 hosts
 ipv6 enable          << on some routers this is enabled after entering the IP address
!
router bgp 100
 bgp router-id 1.1.1.1
 no bgp default ipv4-unicast  << I have disabled the default behaviour of BGP , as we are using
 bgp log-neighbor-changes          address family concept  >>
 neighbor 10.0.0.1 remote-as 100
 neighbor 2005:1::1 remote-as 100
 ! 
 address-family ipv4          << the address family model for IPV4
  neighbor 10.0.0.1 activate  
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv6
  neighbor 2005:1::1 activate
  network 2030:1::1/64          << advertising loopback 1 subnets into BGP
  network 2030:2::1/64
  network 2030:3::1/64
 exit-address-family

The Cisco BGP address family identifier (AFI) model was introduced with multiprotocol BGP and is designed to be modular and scalable, and to support multiple AFI and subsequent address family identifier (SAFI) configurations.
As we can see I have defined two address families IPv4 and IPv6 for the BGP peerings. We must use the activate command on every neighbor for the family, or the peer group to make it easier to manage. We must add the peer address and the AS number under the global BGP process, and further activate the neighbor under the family model. 
Now let us look at the rest of the router config, they are pretty much the same.

ISP2
ipv6 unicast-routing
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
 no ip address
 ipv6 address 2010:1::1/64
 ipv6 address 2010:2::1/64
 ipv6 address 2010:3::1/64
 ipv6 enable
!
interface Loopback2
 ip address 22.22.22.1 255.255.255.0 secondary
 ip address 22.22.24.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.252
 duplex auto
 speed auto
 ipv6 address 2005:1::1/127
 ipv6 enable
!
interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 duplex auto
 speed auto
 ipv6 address 2001:1::/127
 ipv6 enable
!
interface FastEthernet2/0
 ip address 173.16.1.1 255.255.255.252
 duplex auto
 speed auto
 ipv6 address 2002:1::/127
 ipv6 enable
!
router bgp 100
 bgp router-id 2.2.2.2
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 100
 neighbor 2001:1::1 remote-as 200
 neighbor 2002:1::1 remote-as 300
 neighbor 2005:1:: remote-as 100
 neighbor 172.16.1.2 remote-as 200
 neighbor 173.16.1.2 remote-as 300
 !
 address-family ipv4
  neighbor 10.0.0.2 activate
  neighbor 172.16.1.2 activate
  neighbor 173.16.1.2 activate
  no auto-summary
  no synchronization
  network 22.22.22.0 mask 255.255.255.0
  network 22.22.24.0 mask 255.255.255.0
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:1::1 activate
  neighbor 2002:1::1 activate
  neighbor 2005:1:: activate
  neighbor 2005:1:: next-hop-self
  network 2010:1::1/64
  network 2010:2::1/64
  network 2010:3::1/64
 exit-address-family

UPSTREAM1
ipv6 unicast-routing
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
 no ip address
 ipv6 address 2006:1::1/64
 ipv6 address 2006:2::1/64
 ipv6 address 2006:3::1/64
 ipv6 address 2006:4::1/64
!
interface Loopback2
 ip address 55.55.56.1 255.255.255.0 secondary
 ip address 55.55.55.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 172.16.1.2 255.255.255.252
 duplex auto
 speed auto
 ipv6 address 2001:1::1/127
 ipv6 enable
!
router bgp 200
 bgp router-id 5.5.5.5
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001:1:: remote-as 100
 neighbor 172.16.1.1 remote-as 100
 !
 address-family ipv4
  neighbor 172.16.1.1 activate
  no auto-summary
  no synchronization
  network 55.55.55.0 mask 255.255.255.0
  network 55.55.56.0 mask 255.255.255.0
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:1:: activate
  network 2006:1::1/64
  network 2006:2::1/64
  network 2006:3::1/64
  network 2006:4::1/64
 exit-address-family

UPSTREAM2
ipv6 unicast-routing
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface Loopback1
 no ip address
 ipv6 address 2020:1::1/64
 ipv6 address 2020:2::1/64
 ipv6 address 2020:3::1/64
 ipv6 address 2020:4::1/64
 ipv6 enable
!
interface Loopback2
 ip address 66.66.67.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 173.16.1.2 255.255.255.252
 duplex auto
 speed auto
 ipv6 address 2002:1::1/127
 ipv6 enable
!
router bgp 300
 bgp router-id 6.6.6.6
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2002:1:: remote-as 100
 neighbor 173.16.1.1 remote-as 100
 !
 address-family ipv4
  neighbor 173.16.1.1 activate
  no auto-summary
  no synchronization
  network 66.66.66.0 mask 255.255.255.0
  network 66.66.67.0 mask 255.255.255.0
 exit-address-family
 !
 address-family ipv6
  neighbor 2002:1:: activate
  network 2020:1::1/64
  network 2020:2::1/64
  network 2020:3::1/64
  network 2020:4::1/64
 exit-address-family

To see the BGP table we must use some different syntax on the IPV6 address family. First let us look at the BGP table on the ISP2 router, that interconnects every other router in our small topology.

ISP2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
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
*> 22.22.22.0/24    0.0.0.0                  0         32768 i
*> 22.22.24.0/24    0.0.0.0                  0         32768 i
*> 55.55.55.0/24    172.16.1.2               0             0 200 i
*> 55.55.56.0/24    172.16.1.2               0             0 200 i
*> 66.66.67.0/24    173.16.1.2               0             0 300 i

The BGP table looks simple and clean. We have routes from internal and external neighbors in our table correctly installed. We can test the IPV4 data plane with a simple ping. And verify that it is working fine.

ISP2#ping 66.66.67.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 66.66.67.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/40 ms

Now, let us look a the IPV6 BGP table and the IPV6 family neighbors. Cisco introduces a new command to verify the IPV6 neighbor connectivity and the BGP table.


ISP2#sh ip bgp ipv6 unicast summary
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 15, main routing table version 15
14 network entries using 2086 bytes of memory
14 path entries using 1064 bytes of memory
5/4 BGP path/bestpath attribute entries using 620 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3818 total bytes of memory
BGP activity 23/4 prefixes, 23/4 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:1::1       4   200      64      67       15    0    0 00:59:34        4
2002:1::1       4   300      47      51       15    0    0 00:42:28        4
2005:1::        4   100     297     297       15    0    0 04:51:16       3

We can see that we have three IPV6 BGP neighbors, two external and one internal BGP speaking router. The prefixes are exhanged between them. Now , let us see the IPV6 BGP routing table.

ISP2#sh ip bgp ipv6 unicast
BGP table version is 15, local router ID is 2.2.2.2
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
*> 2006:1::/64      2001:1::1                0             0 200 i
*> 2006:2::/64      2001:1::1                0             0 200 i
*> 2006:3::/64      2001:1::1                0             0 200 i
*> 2006:4::/64      2001:1::1                0             0 200 i
*> 2010:1::1/64     ::                       0         32768 i
*> 2010:2::1/64     ::                       0         32768 i
*> 2010:3::1/64     ::                       0         32768 i
*> 2020:1::/64      2002:1::1                0             0 300 i
*> 2020:2::/64      2002:1::1                0             0 300 i
*> 2020:3::/64      2002:1::1                0             0 300 i
*> 2020:4::/64      2002:1::1                0             0 300 i
*>i2030:1::/64      2005:1::                 0    100      0 i
*>i2030:2::/64      2005:1::                 0    100      0 i
*>i2030:3::/64      2005:1::                 0    100      0 i

We can see all the prefixes from the advertised IPV6 loopbacks that are insalled in the global IPV6 routing table. We can do a simple ping to verify connectivity. I can verify that it is working ok.

ISP2#ping ipv6 2020:1::1 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2020:1::1, timeout is 2 seconds:
Packet sent with a source address of 2010:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/28 ms

There is much more to talk about the MP-BGP protocol, and more blogs to come on L3 MPLS VPN, where we will exchange the VPNV4 and VPNV6 routes. On detailed implementation one can always use the Cisco site on MP-BGP for IPV6.

Feel free to comment.

Saturday, August 24, 2013

Resolve routing overhead with ODR

Implement On-Demand routing - cost reducing


Static routes in an enterprise or service provider design setups have a main drawback that they have to manually configured and updated by an network engineer if a topology has changed. The other option are dynamic routing protocols. The RIP, OSPF, IS-IS and EIGRP consume a lot of network bandwith and machine resources. In this blog I will present a small and simple hub-and-spoke Cisco equipment scenario, where typically a network engineer would use dynamic or static routing.
In this scenario I will use a third option that is called On-Demand routing or simply ODR. This technology relies on the Cisco discovery protocol as sending routing updates. CDP is used to carry network and prefix information from the spokes and the hub router. ODR can be used to provide STUB networks with routing information with minimal overhead, thus reducing the costs of equipment. When compared to a dynamic routing protocol resources in packet sending is minimal. We can see later on how can we tune the routing updates using shorter update interval of CDP information.
ODR technology can be used in a hub and spoke enviroment only. In this topology every spoke router is adjacent with the hub router. Behind the stub router can be some LANs that clients are using. The hub router needs to know about every routing prefix from the spoke routers, but the spoke routers need only the default route from the hub router. The hub router send only the default route to the spoke routers that is pointing to himself as the next-hop. 
Now let's get some configuring done. ODR is implemented in global config with a simple command: router odr. First let see the configured interface on the spoke routers.

R2
interface FastEthernet0/0
 ip address 10.1.1.2 255.255.255.252
 duplex auto
 speed auto
interface FastEthernet0/1
 ip address 172.16.1.1 255.255.255.0
 duplex auto
 speed auto
cdp timer 15

R3 
interface FastEthernet0/0
 ip address 10.2.1.2 255.255.255.252
 duplex auto
 speed auto
interface FastEthernet0/1
 ip address 172.17.1.1 255.255.255.0
 duplex auto
 speed auto
cdp timer 15

We can see that no routing is configured on the stub routers.

R3#sh running-config | include route
R3#
R3#sh ip protocols
R3#

And the HUB router has directly connected WAN links towards the spoke with the global config ODR turned on.

R1
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.252
 duplex auto
 speed auto
interface FastEthernet0/1
 ip address 10.2.1.1 255.255.255.252
 duplex auto
 speed auto
router odr
ip classless
cdp timer 15

I have tuned the CDP timers with 15 second update on all of the routers in sending the CDP updates. Now let us look at the routing table on one of the Hub and Spoke routers.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.17.0.0/24 is subnetted, 1 subnets
o       172.17.1.0 [160/1] via 10.2.1.2, 00:00:07, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
o       172.16.1.0 [160/1] via 10.1.1.2, 00:00:00, FastEthernet0/0
     10.0.0.0/30 is subnetted, 2 subnets
C       10.2.1.0 is directly connected, FastEthernet0/1
C       10.1.1.0 is directly connected, FastEthernet0/0
     192.168.1.0/32 is subnetted, 1 subnets
C       192.168.1.1 is directly connected, Loopback0


And the routing table of the spoke router.

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.1.1.1 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/1
     10.0.0.0/30 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
o*   0.0.0.0/0 [160/1] via 10.1.1.1, 00:00:13, FastEthernet0/0

We should not be confused with the o letter in front of the route as the OSPF update. This is and ODR update of the prefix information. As we can see the HUB router knows via ODR the LAN links from the spokes, and the spoke routers have a default static route towards the HUB router. All of this with a one simple command. 
Now we can test this with a simple ping from a R3 router LAN interface toward the R2 router LAN interface to see if we have end to end connectivity.

R3#ping 172.16.1.1 source 172.17.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.17.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/49/80 ms

This works perfectly!
We can tune the ODR route propagation with many features that dynamic protocol are using, similar to distribution lists with ACL combination.

Thanks and feel free to comment.