Cisco ASA BGP configuration

In this post we will examine the use of BGP in the Cisco ASA to allow failover between 2 ethernet style connections from the same ISP. There is no reason to doubt that this would not work with a PPPoE style connections but, the same ISP must still be sued. This requirement is because we will be announcing IP addresses which are not part of the glue subnets.

The test lab setup is:
Cisco ASA BGP Lab setup

Stage 1 – Set up the routers
Our 2 routers will have mirror configs on them and both of them will advertise a default route to the ASA. This is a config extract…

router bgp 111
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 111
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 11.11.11.2 remote-as 65000
 neighbor 11.11.11.2 default-originate

Pretty basic but it will get us running. Note I used IS-IS to share loopback info between the two routers.

Stage 2 – Onto the ASA
First thing is to choose our prefix for announcement. I’m using 99.99.99.99/32, but note that its not attached to an interface at this point. We can fix that by using Null0

route Null0 99.99.99.99 255.255.255.255

Now we can set up a prefix list to stop us becoming a transit provider!

prefix-list MYIP seq 5 permit 99.99.99.99/32

Lastly the actual BGP config:

router bgp 65000
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 10.10.10.1 remote-as 111
  neighbor 10.10.10.1 activate
  neighbor 10.10.10.1 prefix-list MYIP out
  neighbor 11.11.11.1 remote-as 111
  neighbor 11.11.11.1 activate
  neighbor 11.11.11.1 prefix-list MYIP out
  network 99.99.99.99 mask 255.255.255.255
  no auto-summary
  no synchronization
 exit-address-family

Its a bit odd in the way its configured but it works ok.

Stage 3 – Testing
The first test is the show ip bap summary which in ASA language is:

ciscoasa# show bgp summ
BGP router identifier 192.168.192.1, local AS number 65000
BGP table version is 13, main routing table version 13
2 network entries using 400 bytes of memory
3 path entries using 240 bytes of memory
2/2 BGP path/bestpath attribute entries using 416 bytes of memory
1 BGP AS-PATH entries using 24 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 1080 total bytes of memory
BGP activity 14/12 prefixes, 57/54 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4          111 8       6             13    0    0 00:01:35  1       
11.11.11.1      4          111 8       6             13    0    0 00:01:35  1       

Note we have 1 route received from each peer. This should be the default route, but we can test that:

ciscoasa# sh route bgp 

Codes: L - local, 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, V - VPN
       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, + - replicated route
Gateway of last resort is 11.11.11.1 to network 0.0.0.0

B*       0.0.0.0 0.0.0.0 [20/0] via 11.11.11.1, 00:03:44

and for a bit more info…

ciscoasa# show bgp 0.0.0.0/0
BGP routing table entry for 0.0.0.0/0, version 2
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  111 
    11.11.11.1 from 11.11.11.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, external, best
  111 
    10.10.10.1 from 10.10.10.1 (2.2.2.2)
      Origin IGP, localpref 100, valid, external

And we also should check that we are announcing the 99.99.99.99/32 prefix to our peers

ciscoasa# show bgp neighbors 10.10.10.1 advertised-routes 

BGP table version is 13, local router ID is 192.168.192.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight  Path
*> 99.99.99.99/32   0.0.0.0              0         32768  i

Total number of prefixes 1 

Stage 4 – Tuning
The final part is to tune the setup to use a primary and a backup line. Currently the two links are not controlled and the default route is based on the longest uptime!
The first stage is to ensure we send our traffic out of the primary connection. We will be using local preference, but there are other ways such as weight. This is done with a route-map attached to the bap neighbour.

prefix-list DG seq 5 permit 0.0.0.0/0
route-map OUTMAP permit 10
 match ip address prefix-list DG
 set local-preference 200

router bgp 65000
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 11.11.11.1 remote-as 111
  neighbor 11.11.11.1 activate
  neighbor 11.11.11.1 prefix-list MYIP out
  neighbor 11.11.11.1 route-map OUTMAP in

which we can verify is working with the following output:

ciscoasa# show bgp 0.0.0.0/0
BGP routing table entry for 0.0.0.0/0, version 17
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  111 
    11.11.11.1 from 11.11.11.1 (1.1.1.1)
      Origin IGP, localpref 200, valid, external, best
  111 
    10.10.10.1 from 10.10.10.1 (2.2.2.2)
      Origin IGP, localpref 100, valid, external

Next we need to ensure the traffic is sent back to us via the same primary route. As we are using the same service provider we could use the MED, however, sometimes the MED is respected, other times its not. The more reliable method is the as prepend feature. this is configured below:

prefix-list MYIP seq 5 permit 99.99.99.99/32
route-map BAKMAP permit 10
 match ip address prefix-list MYIP
 set as-path prepend 65000 65000

router bgp 65000
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 10.10.10.1 remote-as 111
  neighbor 10.10.10.1 activate
  neighbor 10.10.10.1 prefix-list MYIP out
  neighbor 10.10.10.1 route-map BAKMAP out

this can be verified on the upstream router:

R2#sh ip bgp
BGP table version is 43, 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, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
      0.0.0.0          0.0.0.0                                0 i
 *>i  99.99.99.99/32   1.1.1.1                  0    100      0 65000 i
 *                     10.10.10.2               0             0 65000 65000 65000 i
Posted in Cisco | Tagged , , | Comments Off on Cisco ASA BGP configuration

Cisco ASA with PPPOE failover line

As we have documented previously, failover on the ASA is not a difficult configuration, just add a tracking object to the primary route and modify the metric of the secondary route. The snarly bit about getting a pope based failover on the ASA is to increase the metric of the secondary route as it is sent from the pope server and there is no ‘route’ stamens in the config to adjust.
This is a brief post on how to set this up…

Set up the interfaces – note the ‘pppoe client route distance 10’ line!

interface GigabitEthernet1/1
 nameif OUTSIDE
 security-level 0
 ip address 10.10.10.2 255.255.255.0

interface GigabitEthernet1/2
 nameif BACKUP
 security-level 0
 pppoe client vpdn group MY_GROUP
 pppoe client route distance 10
 ip address pppoe setroute 

Now the SLA and tracking object

sla monitor 1
 type echo protocol ipIcmpEcho 11.11.11.11 interface OUTSIDE
 frequency 5
sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

Then just add the primary route in manually

route OUTSIDE 0.0.0.0 0.0.0.0 10.10.10.1 1 track 1

Lets check the routing table with both lines up and running:

ADTEST# show route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 10.10.10.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 10.10.10.1, OUTSIDE
C        10.10.10.0 255.255.255.0 is directly connected, OUTSIDE
L        10.10.10.2 255.255.255.255 is directly connected, OUTSIDE
C        192.168.222.0 255.255.255.0 is directly connected, INSIDE
L        192.168.222.1 255.255.255.255 is directly connected, INSIDE

After we pull the plug on the primary line

ADTEST# sh route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 1.2.3.4 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [10/0] via 1.2.3.4, BACKUP
C        192.168.222.0 255.255.255.0 is directly connected, INSIDE
L        192.168.222.1 255.255.255.255 is directly connected, INSIDE

The default route has changed to the backup line. Its not really 1.2.3.4 of course its the gateway of the ISP LNS.

Notes
If you try to use both routes with the same distance, then the second route will not be added to the table. In our case this willceratinly be the BACKUP route not being added in as the PPPOE process takes time upon boot.

Posted in Cisco | Tagged , , , , | Comments Off on Cisco ASA with PPPOE failover line

Let’s talk about AF-Groups, Session-Groups and Neighbor-Groups

After the spin round the block with IOS-XE ‘scaled configuration’ features, this is the accompanying IOS-XR version. First thing first we need to create the ‘long-hand’ version that we used on XE but for XR. The config on XR changes so I’ll notate where appropriate.

router bgp 1000
 address-family ipv4 unicast      <<< ENABLE IPV4 
  redistribute connected          <<< ADD SOME ROUTES TO FILTER!
 !
 neighbor 1.2.3.5
  remote-as 65111
  password encrypted 1543595F50
  session-open-mode passive-only  <<< XE: transport connection-mode passive
  address-family ipv4 unicast
   route-policy GOOD2GO in        <<< INBOUND POLICY     
   maximum-prefix 10 75
   route-policy DEFAULT_ONLY out  <<< OUTBOUND POLICY
   default-originate

Lets just confirm we are getting what we are supposed to on the client router (which is IOS-XE).

Router#sh ip bgp sum
BGP router identifier 1.2.3.5, local AS number 65111
BGP table version is 8, main routing table version 8
1 network entries using 248 bytes of memory
1 path entries using 136 bytes of memory
1/1 BGP path/bestpath attribute entries using 288 bytes of memory
1 BGP AS-PATH entries using 24 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 696 total bytes of memory
BGP activity 6/5 prefixes, 6/5 paths, scan interval 60 secs
4 networks peaked at 14:05:08 Oct 27 2019 UTC (03:08:50.500 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.2.3.4         4         1000     203     212        8    0    0 03:11:20        1

Exercise 1 - The Neighbor-Group
The neighbor-group is similar to the peer-group in XE, i.e. there is no separation between session data and routing policy. In our example we can pretty much paste the existing config into the neighbor-group as seen below:

router bgp 1000
 address-family ipv4 unicast
  redistribute connected
 !
 neighbor-group TESTNG
  remote-as 65111
  password encrypted 1543595F50
  session-open-mode passive-only
  address-family ipv4 unicast
   route-policy GOOD2GO in
   maximum-prefix 10 75
   route-policy DEFAULT_ONLY out
   default-originate
  !
 !
 neighbor 1.2.3.5
  use neighbor-group TESTNG
  description *** TEST PEER ***

Exercise 2 - The Session-Group
The session-group is similar in function to the peer-session function in XE. It is concerned with the connection between peers at a TCP/IP level. First thing to do is to rip out the neighbor-group and then start building the session-group. one that is done we can inherit the template but using the 'use' keyword.

router bgp 1000
 address-family ipv4 unicast
  redistribute connected
 !
 session-group TESTSG
  remote-as 65111
  password encrypted 1543595F50
  session-open-mode passive-only
 !
 neighbor 1.2.3.5
  use session-group TESTSG
  address-family ipv4 unicast
   route-policy GOOD2GO in
   maximum-prefix 10 75
   route-policy DEFAULT_ONLY out
   default-originate

Exercise 3 - The AF Template
Last job to do is to use the af-template. The AF template is configured in the main BGP section and must be called from inside the neighbor configuration and the from the relevant address family. Similar to the session template, you can add the template and then 'use' it. After that the neighbor specific details can be removed to leave just the templates.

router bgp 1000
 address-family ipv4 unicast
  redistribute connected
 !
 af-group TESTAFG address-family ipv4 unicast
  route-policy GOOD2GO in
  maximum-prefix 10 75
  route-policy DEFAULT_ONLY out
  default-originate
 !
 session-group TESTSG
  remote-as 65111
  password encrypted 1543595F50
  session-open-mode passive-only
 !
 neighbor 1.2.3.5
  use session-group TESTSG
  description *** TEST PEER ***
  address-family ipv4 unicast
   use af-group TESTAFG

And to finalise, here is some verification data from the XR router:

RP/0/0/CPU0:ios#show bgp ipv4 unicast summary                             
Sun Oct 27 17:52:44.716 UTC
BGP router identifier 22.22.22.22, local AS number 1000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 5
BGP main routing table version 5
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               5          5          5          5           5           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
1.2.3.5           0 65111      28      37        5    0    0 00:14:55          0

RP/0/0/CPU0:ios#show bgp ipv4 unicast neighbors 1.2.3.5 advertised-routes 
Sun Oct 27 17:52:08.009 UTC
Network            Next Hop        From            AS Path
0.0.0.0/0          0.0.0.0         Local           i

Processed 1 prefixes, 1 paths
Posted in Cisco | Tagged , , , , | Comments Off on Let’s talk about AF-Groups, Session-Groups and Neighbor-Groups

Let’s talk about Peer-Groups, Session-Templates and Policy-Templates

We have a lot of BGP configuration over a number of devices. In the main these run IOS XE but not all. This post is a walk through of how to convert a ‘long-hand’ BGP config into first peer- groups, then session-templates and policy-templates. We’l move on to IOS XR configurations in another post.

Here is our initial ‘long-hand’ configuration:

neighbor 10.20.80.46 remote-as 65007
neighbor 10.20.80.46 description *** TEST PEER ***
neighbor 10.20.80.46 transport connection-mode passive
neighbor 10.20.80.46 password its_a_secret
neighbor 10.20.80.46 activate
neighbor 10.20.80.46 default-originate
neighbor 10.20.80.46 prefix-list DEFAULT-ROUTE out
neighbor 10.20.80.46 maximum-prefix 10

Exercise 1 – Peer-Groups
Lets put this into a peer-group – its inside a VRF for extra complexity!

neighbor REDTEST peer-group
neighbor REDTEST remote-as 65100
neighbor REDTEST transport connection-mode passive
neighbor REDTEST password its_a_secret
neighbor REDTEST default-originate
neighbor REDTEST prefix-list DEFAULT_ROUTE out

Then we can add the neighbour

neighbor 10.20.80.46 peer-group REDTEST
neighbor 10.20.80.46 description *** TEST PEER ***
neighbor 10.20.80.46 activate

As we are using a af-group for this peer, the peer ‘activate’ is required. AS it happens I have made it a requirement for the ipv4 af as well which would automatically enable on an IOS-XE device. I’ve configured the other side as follows:

router bgp 65100
 bgp log-neighbor-changes
 neighbor 10.20.80.45 remote-as 1000
 neighbor 10.20.80.45 password its_a_secret
 !
 address-family ipv4
  neighbor 10.20.80.45 activate
 exit-address-family

So the completed configuration for the peer-group router is:

router bgp 1000
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv4 vrf RED
  neighbor REDTEST peer-group
  neighbor REDTEST remote-as 65100
  neighbor REDTEST transport connection-mode passive
  neighbor REDTEST password its_a_secret
  neighbor REDTEST default-originate
  neighbor REDTEST prefix-list DEFAULT_ROUTE out
  neighbor 10.20.80.46 peer-group REDTEST
  neighbor 10.20.80.46 description *** TEST PEER ***
  neighbor 10.20.80.46 activate
 exit-address-family

Exercise 2 – Session-Templates
First things first – session-templates and policy-templates do not play well with peer-groups so I’ll need to delete the peer-group setup first. Another point to note is the session/policy templates are set up in the main BGP setup not in the af as the peer-group was. The session template contains information to do with the connection/tcp session. Here is my conversion:

router bgp 1000
 template peer-session TESTSESSION
  remote-as 65100
  transport connection-mode passive
  password its_a_secret
 exit-peer-session

The other data needs to go in the normal place and the neighbour needs to inherit the session template.

 address-family ipv4 vrf RED
  neighbor 10.20.80.46 inherit peer-session TESTSESSION
  neighbor 10.20.80.46 description *** TEST PEER ***
  neighbor 10.20.80.46 activate
  neighbor 10.20.80.46 default-originate
  neighbor 10.20.80.46 prefix-list DEFAULT_ROUTE out
  neighbor 10.20.80.46 maximum-prefix 10
 exit-address-family

This all works well and the partner router is getting the default route sent over.
Exercise 3 – Policy Templates
The last task on this post is to wrap up all the routing policy based stuff into the policy templates. This is done with the template peer-policy statement.

router bgp 1000
 template peer-policy TESTPOLICY
  prefix-list DEFAULT_ROUTE out
  default-originate
  maximum-prefix 10
 exit-peer-policy

then inherit as before:

address-family ipv4 vrf RED
  neighbor 10.20.80.46 inherit peer-session TESTSESSION
  neighbor 10.20.80.46 description *** TEST PEER ***
  neighbor 10.20.80.46 activate
  neighbor 10.20.80.46 inherit peer-policy TESTPOLICY
 exit-address-family

Again this all works fine and the other side is getting the default route.
Exercise 4 – Overrides
This test shows that we can override the settings in the policy or session template by adding into the individual peer stanza.

router bgp 1000
 template peer-policy TESTPOLICY
  prefix-list DEFAULT_ROUTE out
  default-originate
  maximum-prefix 10
 exit-peer-policy
 !
 template peer-session TESTSESSION
  remote-as 65100
  transport connection-mode passive
  password not_a_secret
 exit-peer-session
 !
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv4 vrf RED
  neighbor 10.20.80.46 inherit peer-session TESTSESSION
  neighbor 10.20.80.46 description *** TEST PEER ***
  neighbor 10.20.80.46 password its_a_secret
  neighbor 10.20.80.46 activate
  neighbor 10.20.80.46 inherit peer-policy TESTPOLICY
 exit-address-family
Posted in Cisco | Tagged , , , | Comments Off on Let’s talk about Peer-Groups, Session-Templates and Policy-Templates

Cisco ASA Connect to DSL via Draytek Modem

Some times we need to connect an ASA to a DSL/FTTC line directly vi a modem, either for a backup line (see previous posts) or for a primary internet connection. Lets walk through the process here:

Stage 1- Set up a VPDN group
As the modem takes care of the complicated VCI/VPI type settings, we will use pope with just a username and password. This setup works fine with UK based poppa type connections too.

vpdn group MYGROUP request dialout pppoe
vpdn group MYGROUP localname <dsl_username>
vpdn group MYGROUP ppp authentication chap

Stage 2 – Set up the local user for DSL authentication

vpdn username <dsl_username> password <dsl_password> 

Stage 3 – Attach to the outside interface
Assuming the DSL modem is plugged into the OUTSIDE interface. Note the default route is set at the same time.

interface GigabitEthernet1/1
 nameif OUTSIDE
 security-level 0
 pppoe client vpdn group MYGROUP
 ip address pppoe setroute 

Testing!

ASA# show vpdn pppinterface 

PPP virtual interface id = 1
PPP authentication protocol is CHAP
Server ip address is A.B.C.D
Our ip address is W.X.Y.Z
Transmitted Pkts: 689943, Received Pkts: 1276163, Error Pkts: 0
MPPE key strength is None
  MPPE_Encrypt_Pkts: 0,  MPPE_Encrypt_Bytes: 0
  MPPE_Decrypt_Pkts: 0,  MPPE_Decrypt_Bytes: 0
  Rcvd_Out_Of_Seq_MPPE_Pkts: 0
Posted in Cisco | Tagged , , , | Comments Off on Cisco ASA Connect to DSL via Draytek Modem

Cisco ASA Dual ISP setup

This post describes and tests some configurations to support multiple ISP or WAN connections on an ASA running FOS9. Im using an ASA 5506X for this demo and my software version does not use the bridge-groups out of the box so all the ports are routed by default. Ima Laos using a couple of other Cisco routers in a simple network to test the connections.

To start with lets set up a standard Dual ISP setup which just relies on a floating static route.

Stage 1 – Set up the interfaces

interface GigabitEthernet1/1
 nameif ISP1
 security-level 0
 ip address 10.0.0.2 255.255.255.252 
!             
interface GigabitEthernet1/2
 nameif ISP2
 security-level 0
 ip address 10.1.1.2 255.255.255.252 

Stage 2 – Add the routes
We want ISP1 to be the primary and it to fall back to the secondary if it fails.

route ISP1 0.0.0.0 0.0.0.0 10.0.0.1 1 
route ISP2 0.0.0.0 0.0.0.0 10.1.1.1 200

A quick check of the routing table shows:

ciscoasa# sh route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 10.0.0.1, ISP1
C        10.0.0.0 255.255.255.252 is directly connected, ISP1
L        10.0.0.2 255.255.255.255 is directly connected, ISP1
C        10.1.1.0 255.255.255.252 is directly connected, ISP2
L        10.1.1.2 255.255.255.255 is directly connected, ISP2

When I pull the cable out of the interface Gi1/1 (ISP1) and re-check:

ciscoasa# sh route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 10.1.1.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [200/0] via 10.1.1.1, ISP2
C        10.1.1.0 255.255.255.252 is directly connected, ISP2
L        10.1.1.2 255.255.255.255 is directly connected, ISP2

So that all works…. however the design we need here means that it is VERY unlikely it will ever failover as the line protocol will always remain up as we will either uses. modem or another router as the gateway. A new option is needed here, using a tracking object.

The new topology is a bit different and uses an intermediate switch/router on ISP1 so we can monitor something that is not direly connected.

The first stage is create an SLA object:

sla monitor 1
 type echo protocol ipIcmpEcho 1.1.1.1 interface ISP1
sla monitor schedule 1 life forever start-time now

Im monitoring the loopmback interface on my ISP router – but that’s via an extra L3 hop on the switch. We can test it works with the following:

ciscoasa# show sla monitor configuration 
SA Agent, Infrastructure Engine-II
Entry number: 1
Owner: 
Tag: 
Type of operation to perform: echo
Target address: 1.1.1.1
Interface: ISP1
Number of packets: 1
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Operation frequency (seconds): 60
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Enhanced History:

ciscoasa# show sla monitor operational-state 
Entry number: 1
Modification time: 01:08:31.696 UTC Tue Oct 15 2019
Number of Octets Used by this Entry: 2056
Number of operations attempted: 3228
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 1
Latest operation start time: 06:55:31.697 UTC Thu Oct 17 2019
Latest operation return code: OK
RTT Values:
RTTAvg: 1       RTTMin: 1       RTTMax: 1
NumOfRTT: 1     RTTSum: 1       RTTSum2: 1

One that’s all running we can attach it to a tracking object as follows:

track 1 rtr 1 reachability

which can be verified:

ciscoasa# sh track 
Track 1
  Response Time Reporter 1 reachability
  Reachability is Up
  6 changes, last change 00:37:56
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    STATIC-IP-ROUTING 0

Now we can add the tracking object onto the default route.

route ISP1 0.0.0.0 0.0.0.0 10.0.0.1 1 track 1
route ISP2 0.0.0.0 0.0.0.0 10.1.1.1 200

So now we can check the routing table….

ciscoasa# show route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 10.0.0.1, ISP1
C        10.0.0.0 255.255.255.0 is directly connected, ISP1
L        10.0.0.2 255.255.255.255 is directly connected, ISP1
C        10.1.1.0 255.255.255.252 is directly connected, ISP2
L        10.1.1.2 255.255.255.255 is directly connected, ISP2

I’ve now broken the network north of the directly connected router and south of 1.1.1.1

ciscoasa# show route

Codes: L - local, 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, + - replicated route
Gateway of last resort is 10.1.1.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [200/0] via 10.1.1.1, ISP2
C        10.0.0.0 255.255.255.0 is directly connected, ISP1
L        10.0.0.2 255.255.255.255 is directly connected, ISP1
C        10.1.1.0 255.255.255.252 is directly connected, ISP2
L        10.1.1.2 255.255.255.255 is directly connected, ISP2

ciscoasa# sh track
Track 1
  Response Time Reporter 1 reachability
  Reachability is Down
  7 changes, last change 00:00:17
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

ciscoasa# sh sla monitor operational-state 1
Entry number: 1
Modification time: 01:08:31.701 UTC Tue Oct 15 2019
Number of Octets Used by this Entry: 2056
Number of operations attempted: 3239
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: TRUE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): NoConnection/Busy/Timeout
Latest operation start time: 07:06:31.702 UTC Thu Oct 17 2019
Latest operation return code: Timeout
RTT Values:
RTTAvg: 0       RTTMin: 0       RTTMax: 0
NumOfRTT: 0     RTTSum: 0       RTTSum2: 0

That failed over and now its plugged in and back to normal. Notice the ‘operational frequency of the SLA is 60 seconds so that could do woyj some tuning!

Posted in Cisco | Tagged , , , , | Comments Off on Cisco ASA Dual ISP setup

Juniper EX switches – those error lights!

When we spin up a new EX 2200 switch the Alarm light always comes on. This post shows how to trace the issue and fix the problem. Then hopefully your switch will not have that annoying/alarming red/amber light on it all the time! Im using an EX2200 (JUNOS 12.3R9.4) and have loaded the factory default config.

Lets check for system alarms

root> show system alarms 
1 alarms currently active
Alarm time               Class  Description
2015-02-12 14:38:59 UTC  Major  Management Ethernet Link Down

This is telling us that we are not plugged into the management port – which is not a problem. Lets fix that:

root# set chassis alarm management-ethernet link-down ignore

Now when its committed, the red light is off!

Posted in Juniper | Tagged , , | Comments Off on Juniper EX switches – those error lights!

Cisco Anyconnect – Disconnect and Reconnect at login

We have all had that experience when the Cisco Anyconnect client immediately disconnects after you have logged on and then starts reconnecting again. Its not life threatening, just irritating. The issue appears to be caused by an MTU mismatch, but this can be tweaked on the ASA based on the profile. This post shows how to fix the problem at the ASA CLI.

The config needs to added to the default remote profile under the webvpn stanza, however we don’t like messing around with default policies so we will modify the custom group policy for our remote users.

group-policy REMOTE-POLICY internal
group-policy REMOTE-POLICY attributes
 dns-server value x.x.x.x x.x.x.x
 vpn-tunnel-protocol ssl-client 
 split-tunnel-policy tunnelall
 webvpn
  anyconnect mtu 1300

And that’s it!

Posted in Cisco | Tagged , , , | Comments Off on Cisco Anyconnect – Disconnect and Reconnect at login

Juniper BGP on SRX – Basic EBGP setup

So I have an SRX300 with an external Draytek 130 attached giving DSL connectivity. the next task is to create a BGP session so we can announce the routed subnet back to our MPLS VPN. This will move onto multiple lines with some route selection included. In the first instance we need to establish the peering session, and the internet is full of the instructions on how do this. The next stage is a announcing a prefix which is not so well documented.

Our AS: 65111
Core AS: 65000
Our DSL IP: 192.168.1.244/32
Core DSL gateway: 192.168.250.6
Local LAN: 192.168.20.0/24 – this is to be advertised

Stage 1: Set up the BGP AS

 
root# set routing-options autonomous-system 65111

Stage 2: Set up a group (like a Cisco Peer-Group)

set protocols bgp group UPSTREAM type external
set protocols bgp group UPSTREAM peer-as 65000
set protocols bgp group UPSTREAM neighbor 192.168.250.6

Stage 3: We like authentication on BGP sessions!

set protocols bgp group UPSTREAM authentication-key my_secret_key

At this point we can see the session is set up. This can be verified with:

root> show bgp summary 
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.250.6         65000        144        153       0       2       22:26 1/1/1/0              0/0/0/0  

Notice we a have received 1 route from the other side, which in our case is a default route. This can be checked with:

root> show route protocol bgp 

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

0.0.0.0/0          *[BGP/170] 00:24:19, localpref 100
                      AS path: 65000 I, validation-state: unverified
                    > to 192.168.250.6 via pp0.0

However we are still not announcing our local route back to the upstream router.

Stage 4: Create a routing policy

The policy will be called EXP-POLICY and is set to just export the local 192.168.20.0/24 prefix

root# set policy-options policy-statement EXP-POLICY term 1 from route-filter 192.168.20.0/24 exact
root# set policy-options policy-statement EXP-POLICY term 1 then accept

Stage 5: Attach the policy

root# set protocols bgp group UPSTREAM export EXP-POLICY

Now we can check the announced routes! Note that the route needs to be in the UP state for the announcement to work.

root> show route advertising-protocol bgp 192.168.250.6    

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 192.168.20.0/24         Self                                    I
Posted in Juniper | Tagged , , | Comments Off on Juniper BGP on SRX – Basic EBGP setup

Juniper SRX ADSL setup with Draytek 130 Modem

The next challenge is to add a second DSL account onto the same SRX110 or in the case of the SRX300 just add a DSL connection. The SRX300 has no PIM slots so cannot get a DSL card added. The way Juniper implement this is to use a ‘pp’ interface which equates roughly to a Cisco Dialler interface. So one the pp interface is created and configured, we need to link it to a physical interface and plug in the Draytek modem. I don’t have any other modems to hand but I suspect any ADSL/VDSL modem would do.

Step 1: Assign our physical WAN port
I’m using fe-0/0/0 as its the default WAN port on the SRX110

root# set interfaces fe-0/0/0 unit 0 encapsulation ppp-over-ether

Step 2: Setup and configure the pp0 (Dialer) interface and chap options

root# set interfaces pp0 unit 0 ppp-options chap default-chap-secret your_password
root# set interfaces pp0 unit 0 ppp-options chap local-name your_username
root# set interfaces pp0 unit 0 ppp-options chap passive

Step 3: Set the PPOE options and link the physical interface

root# set interfaces pp0 unit 0 pppoe-options underlying-interface fe-0/0/0.0
root# set interfaces pp0 unit 0 pppoe-options idle-timeout 0
root# set interfaces pp0 unit 0 pppoe-options auto-reconnect 3
root# set interfaces pp0 unit 0 pppoe-options client

Step 4: Set up the layer3 info on the pp0
This is a dynamic IP address account so we just let the SRX negotiate.

root# set interfaces pp0 unit 0 family inet mtu 1492
root# set interfaces pp0 unit 0 family inet negotiate-address

Step 5: Routing
We need to add a default route to get internet traffic

root# set routing-options static route 0.0.0.0/0 next-hop pp0.0

Testing
As we are using an external modem, we can’t get much info about the DSL connection. The main tests are ppp related:

root> show ppp summary 
Interface      Session type  Session phase      Session flags
pp0.0          PPP           Network    

root> show ppp statistics 
Session statistics from PPP process
  Total sessions: 1 
    Sessions in disabled phase    : 0
    Sessions in establish phase   : 0
    Sessions in authenticate phase: 0 
    Sessions in network phase     : 1
    Bundles in pending phase      : 0      

Lets get some pppoe data:

root> show pppoe interfaces 
pp0.0 Index 82
  State: Session up, Session ID: 6, 
  Service name: None, 
  Session AC name: Vigor2000 PPPoE, Configured AC name: None, 
  Remote MAC address: 00:1d:aa:8b:c2:e0, 
  Session uptime: 17:06:31 ago, 
  Auto-reconnect timeout: 3 seconds, Idle timeout: Never, 
  Underlying interface: fe-0/0/0.0 Index 81

A last general and probably best show command is:

root> show interfaces pp0 brief 
Physical interface: pp0, Enabled, Physical link is Up
  Type: PPPoE, Link-level type: PPPoE, MTU: 1532, Speed: Unspecified
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps

  Logical interface pp0.0 
    Flags: Point-To-Point SNMP-Traps 0x0 Encapsulation: PPPoE
    PPPoE:
      State: SessionUp, Session ID: 6,
      Session AC name: Vigor2000 PPPoE, Remote MAC address: 00:1d:aa:8b:c2:e0,
      Configured AC name: None, Service name: None,
      Auto-reconnect timeout: 3 seconds, Idle timeout: Never,
      Underlying interface: fe-0/0/0.0 (Index 81)
    Security: Zone: untrust
    Allowed host-inbound traffic : dhcp tftp
    inet  my_dsl_address      --> my_dsl_next_hop
Posted in Juniper | Tagged , , , , , | Comments Off on Juniper SRX ADSL setup with Draytek 130 Modem