BGP through 6.3(4) vs. 7.0

Answered Question
Jul 24th, 2008

Wondering why 7.0 seems to accept a static route with norandomseq, but bgp session would not work until we apply a policy.

If there is a document that describes what is actually happening, I appreciate you sharing it with me.

I have this problem too.
0 votes
Correct Answer by Farrukh Haroon about 8 years 3 months ago

I guess you can do 'show asp drop' and look for the following violation:

"tcp-bad-option-list"

Newer version of the capture command allow capturing based on the asp drop type.

As per the ASA documentation, by default only the 'standard' TCP options are allowed. I wonder what are those :).

Regards

Farrukh

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
a.alekseev Fri, 07/25/2008 - 01:02

just because new security features was added to IOS code. And the cli was changed significant from 6.3 to 7.0

you mean BGP session with authentication.

for doing this you need permit tcp option 19

and disable randomseq for BGP peers.

sansari Fri, 07/25/2008 - 04:08

Thanks for the information. Where can I read more about this please? I suspect permiting option 19 was part of the configuration for 6.3, while in 7.0 you have to speciffically state it.

I do mean BGP with authentication, thank you for pointing out.

sansari Wed, 08/06/2008 - 03:36

I am working on yet another firewall upgrade from 6.3(4) to 7.0(7), and there is a bunch of networks some as large as class Bs that are statically nated with norandomseq option enabled. None of the more senior staff know why these statements were originally implemented.

I read the 6.3 command reference, and it suggests that you *may* want to do this ie. disabling randomseq when you have firewalls inline. My question is how do I identify any other applications that may break when I move to 7.0(7) please? Last time I put all the static statements in, and BGP did not come up. I now know why. I just want to catch any other possible similar issues I may run into this time.

Ideally I like to do this before the upgrade. But if you know of any troubleshooting methods to catch these issues after the upgrade, I appreciate it.

I am posting this as a follow up to the BGP question, as I am trying to catch other incompatibilities similar to the BGP issue. Is there an online document that may contain more of these possible scenarios? I do not want to wait for customers to report the issue. I have already identified the BGP peers that are on either side of this firewall, and will create a policy for BGP with MD5 for the two peers.

sansari Wed, 08/06/2008 - 05:37

Thanks. The document states:"By default, option 19 is not permitted to pass through a PIX/ASA that runs 7.0 or later.

"

How do I find out if this is the only option or there is other options please?

Once I am done with upgrade, can I setup a capture that shows packets droped due to tcp option?

Correct Answer
Farrukh Haroon Thu, 08/07/2008 - 06:07

I guess you can do 'show asp drop' and look for the following violation:

"tcp-bad-option-list"

Newer version of the capture command allow capturing based on the asp drop type.

As per the ASA documentation, by default only the 'standard' TCP options are allowed. I wonder what are those :).

Regards

Farrukh

Actions

This Discussion