Category Archives: BGP

%BGP-4-VPNV4NH_MASK: Nexthop

Wha?

Well I found some interesting stuff while trying to run OSPF as a IGP in a MPLS environment while peering BGP by loop back.  Here is the configuration keep in mind this is with INE’s topology.

ip vrf VPN_A
rd 1:1
route-target export 1:1
route-target import 1:1
!
router bgp 1
neighbor 150.1.1.1 remote-as 1
neighbor 150.1.1.1 update-source lo0
neighbor 150.1.2.2 remote-as 1
neighbor 150.1.2.2 update-source lo0
neighbor 150.1.3.3 remote-as 1
neighbor 150.1.3.3 update-source lo0
neighbor 150.1.4.4 remote-as 1
neighbor 150.1.4.4 update-source lo0
neighbor 150.1.5.5 remote-as 1
neighbor 150.1.5.5 update-source lo0
!
address-family vpnv4 unicast
neighbor 150.1.1.1 activate
neighbor 150.1.1.1 send-community both
neighbor 150.1.2.2 activate
neighbor 150.1.2.2 send-community both
neighbor 150.1.3.3 activate
neighbor 150.1.3.3 send-community both
neighbor 150.1.4.4 activate
neighbor 150.1.4.4 send-community both
neighbor 150.1.5.5 activate
neighbor 150.1.5.5 send-community both
!
address-family ipv4 vrf VPN_A
redistribute ospf 3 vrf VPN_A
no synchronization
exit-address-family
!
router ospf 3 vrf VPN_A
redistribute bgp 1 subnets

Then I get this message.. on Each PE router.

*Mar 1 17:10:19.575: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.1.1 may not be reachable from neigbor 150.1.2.2 – not /32 mask
*Mar 1 17:11:26.579: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.3.3 may not be reachable from neigbor 150.1.1.1 – not /32 mask
*Mar 1 17:11:55.683: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.5.5 may not be reachable from neigbor 150.1.1.1 – not /32 mask

On a CE router.

Rack1SW2#sh ip route 155.1.67.7
Routing entry for 155.1.67.0/24
Known via “ospf 1”, distance 110, metric 3, type inter area
Last update from 155.1.58.5 on Vlan58, 00:04:55 ago
Routing Descriptor Blocks:
* 155.1.58.5, from 5.5.5.5, 00:04:55 ago, via Vlan58
Route metric is 3, traffic share count is 1

Traceroute

Rack1SW2#trace 155.1.67.6

Type escape sequence to abort.
Tracing the route to 155.1.67.6

1 155.1.58.5 0 msec 0 msec 9 msec
2 *

Looking over my MPLS forwarding table it appears that since OSPF by default will take my /24 loopback and advertise it by default as a /32 LDP gets confused.  It shows up in the tag switching table as a /24 but a /32 in the routing table.  The fix for this was making each loop back a point-to-point interface under the loopback via OSPF.  Im not sure how this would scale in a large service provider environment… this might even be a IOS bug not sure.

After the change…

Rack1SW2#trace 155.1.67.6

Type escape sequence to abort.
Tracing the route to 155.1.67.6

1 155.1.58.5 8 msec 0 msec 9 msec
2 155.1.146.1 0 msec 8 msec 0 msec
3 155.1.146.6 25 msec * 0 msec

One thing that someone might want to do to make sure that the Loopback is also the router-id as well so there are no problems is by issues the following command under global configuration.

Rack1R1(config)#mpls ldp router-id lo0 force

That way the router-id is always lo0.  By issuing force at the end of the statement it will drop all current ldp connectivity to the loopback.  So if you have MPLS sessions currently using another loopback or interface they will be dropped reinitialize and use lo0.  Otherwise without the force option the mpls neighbor x.x.x.x command will have to be used.

Advertisements

Load balancing a BGP default route from 2 different providers / as-path multipath-relax

ASpathrelax
Generally with BGP you do not hear much about load balancing of routes.  Where I work we have some select remote sites with one router and two circuits going to two different service providers.  Within BGP you will not be able to load balance out a default route.  A better metric will occur and a default will be injected into the RIB where the other circuit does nothing but wait until the primary circuit with the better metric goes down.  So instead of adding more bandwidth to save money I went ahead and applied a nifty little trick.  This could have all been accomplished through static routing but who wants to do that.

Looking at the way it was setup before for a default route it through AS 1803 it is best and will be injected in the routing table only towards AS1803.

testrouter#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
2
13979 64001, (received & used)
1.1.1.1 from 10.102.97.9 (12.123.67.236)
Origin IGP, localpref 100, valid, external
1803 64001, (received & used)
2.2.2.2from 10.102.97.13 (10.247.23.220)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:1803:4603

The routing table only showing one route for 0.0.0.0

testrouter#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via “bgp 6550”, distance 20, metric 0, candidate default path
Tag 1803, type external
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2000 2100 255 1 1500
Last update from 10.102.97.13 3w5d ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 3w5d ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 1803

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1     4      13979  156868  153101        6    0    0 3w5d            1
2.2.2.2     4       1803  156770  153099        6    0    0 3w5d            1
How to fix this?  BGP has two routes through its routing table but the second one is never injected into the routing table.  So we go ahead and work some magic to get it into the RIB.

conf t
router bgp 6500
maximum-paths 2
bgp bestpath as-path multipath-relax
end
!
clear ip bgp 2.2.2.2

After

fsp5958route#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via “bgp 6500”, distance 20, metric 0, candidate default path
Tag 1803, type external
Last update from 2.2.2.2 1w6d ago
Routing Descriptor Blocks:
2.2.2.2, from 2.2.2.2, 1w6d ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 1803
* 1.1.1.1, from 1.1.1.1, 1w6d ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 1803

Connectivity from Remote sites back to a Data center via MPLS

I wanted to blog a bit about MPLS connectivity.  I have been studying a ton of this lately for the lab, I blogged a few months ago about VRF’s connectivity through EIGRP and that was fairly straight forward.  The nice thing about MPLS is being able to send routes from each site back to each remote sites or even to a Datacenter.  This quick lab will have 2 remote sites which will send their prefixes through a MPLS VPN back to a data center to provide connectivity.

Here is our logical topology.

Image

Here is what everything Looks like with our MPLS routers and each subnet/prefix of each remote site.

Image

If this looks familiar to anyone this is part of INE’s topology.

The first thing we want to do is establish connectivity through our VRF’s handing out from or
PE to CE routers. For example R6,R1 and R5 are all PE routers. They will each need a interface
in a VRF handed out to its respecitive CE router. That VRF will participate in BGP on both
ends the CE side and PE side.

Every configuration is similar we will do R1 for example.

#create a VRF and set a RD and route target import and export both
ip vrf vpn
rd 1:1
route-target export 1:1
route-target import 1:1
!
#Put the interface which hands off to CE/Remote site 2 into
vrf vpn
interface Serial0/1
ip vrf forwarding vpn
ip address 155.1.13.1 255.255.255.0
#Create our bgp peering within our VRF
Router bgp 1
address-family ipv4 vrf vpn
address-family ipv4 vrf vpn
neighbor 155.1.13.3 remote-as 100
neighbor 155.1.13.3 activate
neighbor 155.1.13.3 default-originate
neighbor 155.1.13.3 as-override

In this example we need to use as-override, for reasons that for
each site we are planning on using the same AS#. Each remote site is within AS100.

On the PE side.

interface Serial1/2
ip address 155.1.13.3 255.255.255.0
serial restart-delay 0
clock rate 64000
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 192.168.4.0 mask 255.255.255.0
neighbor 155.1.13.1 remote-as 1
no auto-summary

Remote site 2 CE router has no idea it is in a VRF. From its point of view it is connecting to
anoter AS#.

Step 2 is going to be enabling MPLS within each interface in our MPLS cloud. Then creating a
BGP connection to each router within the MPLS cloud.

R6

ip cef
mpls ip
!
interface FastEthernet0/0.146
encapsulation dot1Q 146
ip address 155.1.146.6 255.255.255.0
mpls ip
end
!
router eigrp 100
network 150.1.0.0
network 155.1.0.0
no auto-summary
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.1.1 remote-as 1
neighbor 150.1.1.1 update-source Loopback0
neighbor 150.1.4.4 remote-as 1
neighbor 150.1.4.4 update-source Loopback0
neighbor 150.1.5.5 remote-as 1
neighbor 150.1.5.5 update-source Loopback0
!
address-family vpnv4
neighbor 150.1.1.1 activate
neighbor 150.1.1.1 send-community both
neighbor 150.1.4.4 activate
neighbor 150.1.4.4 send-community both
neighbor 150.1.5.5 activate
neighbor 150.1.5.5 send-community extended
exit-address-family

Theres plenty of config here. First CEF has to be turned on. MPLS ip on the global
configuration has to be turned on in order to turn on MPLS.

Each interface we want to send LDP MPLS packets out of MPLS has to be turned on as well.
Since I have a 155.1.146.0/24,155.1.45.0/24 networks and each bgp router needs connectivity to
each others loopback to peer with I had to run a IGP in between them, EIGRP is quick and
simple.

The first section of config is to setup a BGP session for each routers ie

router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 150.1.1.1 remote-as 1
neighbor 150.1.1.1 update-source Loopback0
!
#the next is to setup MP-BGP
!
address-family vpnv4
neighbor 150.1.1.1 activate
neighbor 150.1.1.1 send-community both
neighbor 150.1.4.4 activate

What this does is activates each neighbor for MP-BGP next what it does is sends the VRF RT plus
prefix across to each router within the MPLS Cloud. For example.
Going to R6 another PE router. We can see we are learning a prefix for 192.168.3.0/24 from R1.
We are passing the Extended community string of the RT 1:1 and a MPLS label.

Rack1R6#sh bgp vpnv4 unicast all 192.168.4.0
BGP routing table entry for 1:1:192.168.4.0/24, version 18
Paths: (1 available, best #1, table vpn)
Flag: 0x820
Advertised to update-groups:
1
100
150.1.1.1 (metric 156160) from 150.1.1.1 (150.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/24

This is extremely flexible as we do not have to have the Same VRF on each and every router.
This topology is small. In a cloud full of 10,20 or 30 plus routers not having to span the
same VRF everywhere is huge.

Now going to our data center side we should see a 192.168.4.0/24 network again.
Data Center as it is…

Datacenter#sh ip bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24, version 17
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
1 1, (received & used)
155.1.58.5 from 155.1.58.5 (150.1.5.5)
Origin IGP, localpref 100, valid, external, best

And we see this prefix being advertised from R5 like it was directly peered connecting to it.

Now our final part of this configuration. To hand out a default route out to each site and
have each one of our prefixex handed out to the data center. I would not like each site to see
each sites prefixs only a default route to each others respected PE routers. This
configuration will be applied on the PE side of course.

For example on R1 for simplicity
ip prefix-list defaultonly seq 5 permit 0.0.0.0/0
!
address-family ipv4 vrf vpn
neighbor 155.1.13.3 remote-as 100
neighbor 155.1.13.3 activate
neighbor 155.1.13.3 default-originate
neighbor 155.1.13.3 as-override
neighbor 155.1.13.3 prefix-list defaultonly out
no synchronization

The easiest thing to do here is create a prefix list that only allows a default route. So it will allow 0.0.0.0/0 and nothing else.

From Remote site 2’s view…

Remote2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 155.1.13.1 0 0 1 i
*> 192.168.4.0 0.0.0.0 0 32768 i

BGP wise all I see is my default route and the nextwork which I am advertising. Now the Datacenter side should see everything.

Datacenter#sh ip bgp
BGP table version is 26, local router ID is 150.1.8.8
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
*> 0.0.0.0 155.1.58.5 0 0 1 i
*> 192.168.1.0 155.1.58.5 0 1 1 i
*> 192.168.2.0 155.1.58.5 0 1 1 i
*> 192.168.3.0 155.1.58.5 0 1 1 i
*> 192.168.4.0 155.1.58.5 0 1 1 i

I have all my routes, they are being sent from the mpls cloud from the datacenters PE router. Now the odd part here is the origin of the perfixes. 1 1 i, this is due to the as-overide feature. As remote site 1 and remote site 2 are looked at to becoming from AS1 and not AS100. ANother way to get around this would be to use a different AS# per site or use some sort of local-as trickery.

Configuring BGP with Route Filtering

Well I sat in on Route, I failed by a single digits… yes 3%, I know all the information back and forward but one problem ceased me to fail…..I screwed up with policy base routing and I think I messed up a few simulations.  I cant really go into detail given the NDA, but if you do not use this stuff every day I would suggest to everyone that they will want to know the information forwards and backwards and be able to work with any IGP or BGP issue.

Getting back to the point, here is our topology.

This is not a real Fancy Topology just something to get the job done.  All remote routers connected to R1 have a static route 0.0.0 0.0.0.0 out of their outgoing interfaces, pretty simple.

Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C    192.168.1.0/24 is directly connected, FastEthernet0/0S*   0.0.0.0/0 is directly connected, FastEthernet0/0R2#

What I am trying to accomplish here is to have All telnet Traffic to be forwarded from Router R1 to to Router R3’s F0/0 interface, well actually the IP for that itnerface 192.168.2.2.  In any other case we would normally have other issues but really its easy.  So we have to set up what is called a Route-map, also how would it work properly here?

In other blog posts I have brought up using policy base routing to make routing decisions based off of access lists.  So we will have to make the following steps….

On Router R1

-Make a Extended access list to capture from any source to any destination allow Telnet

-Make a route-map to fish all telnet traffic

-set the IP next Hop command for the Route-map to send out to 192.168.2.2

-Apply the policy to the Interface….This is where I had difficulty.

So how do we do this you ask!?!?!?!?????

On router R2

R1(config)#access-list 101 permit tcp any any eq telnet – > creates a Access list

R1(config)#route-map test 10 – > creates a route-map and the route-map sequence number

R1(config-route-map)#match ip address 101 – Catches Access-list 101

R1(config-route-map)#set ip next-hop 192.168.2.2 – > If the match ip address 101 is satisfied it sets the next hop to 192.168.2.2

Next thing to do is try to telnet from R2 to a address that is unreachable, this way we can check the route-map after to see if it is taking any hits

Over to R2

R2#telnet 192.168.2.27Trying 192.168.2.27 …

% Connection timed out; remote host not responding

Oh noes!!!!!  But thats what we expected anways, lets check the Route-map to see if it is receiving any hits.
R1(config)#do sh route-maproute-map test

, permit, sequence 10

Match clauses:    ip address (access-lists): 101  Set clauses:

ip next-hop 192.168.2.2

Policy routing matches: 11 packets, 666 bytes

Clearly with the Matches we are in business and we are passing traffic!!!